Flux’s Source Controller provides a unified interface for fetching artifacts from external sources—such as Git repositories, OCI registries, object storage buckets, and Helm chart repositories—and making them available within your cluster for other controllers to consume.Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.
Supported Source Types
| Source Type | Use Case | Flux Resource |
|---|---|---|
| Git | Kubernetes manifests and Helm charts | GitRepository |
| OCI registry | OCI artifacts (images, charts) | OCIRepository |
| Object storage | Artifacts in S3/Azure/GCS buckets | Bucket |
| Helm chart repo | Helm charts | HelmRepository |
GitRepository in the flux-system namespace to store Flux’s own configuration in a GitOps style. To list all configured Git sources:
1. Creating a GitRepository Source
Assume you have a GitHub repositorysidd-harth/app1 containing two manifest files at commit 1b31558. To have Flux fetch these manifests every 10 seconds, run:
If your repository is private, create a Kubernetes
Secret with authentication credentials and reference it in the spec.secretRef field of the GitRepository.2. Verifying the Source
After a short interval, Flux will clone the repo and store its contents as an artifact. Check status with:- REVISION: Git reference and commit hash
- READY: Indicates whether the artifact is successfully stored
3. Inspecting Fetched Artifacts
Flux stores fetched artifacts under the Source Controller’s data directory. Exec into the Source Controller pod:latest.tar.gz file containing your manifests at the most recent revision.
To list its contents:
deployment.yml and service.yml are available for other controllers—such as the Kustomize Controller—to consume.
This workflow enables seamless GitOps-driven deployments by decoupling artifact fetching (Source Controller) from rendering and applying manifests (e.g., Kustomize, Helm Controllers).