> ## 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. # Demo Kustomize Controller Plain YAML Manifests in Different Repo > Guide to using Flux GitRepository and Kustomization to deploy plain YAML manifests from a separate Git repository into a Kubernetes namespace. In this lesson you'll create a GitRepository source and a Kustomization resource so Flux pulls plain YAML manifests from a separate repository and deploys them into a target namespace. What you'll do * Checkout the demo branch containing the application manifests. * Create a GitRepository source (prefer declarative and commit it to your Flux cluster repo). * Create a Kustomization that points to the manifests path in the source repository. * Verify the resources reconcile and the application is running. Store Flux sources and Kustomizations declaratively in Git. Imperative creation (directly creating resources in the cluster) makes recovery and auditing harder after a disaster. Use `--export` to generate YAML and commit it to your Git repository so Flux can reconcile from Git. *** ## Prerequisites * Flux CLI installed and bootstrapped into your cluster. * Local clone of the application source repository (example: `~/bb-app-source`). * Local clone of your Flux cluster repository (example: `~/block-buster/flux-clusters/dev-cluster`). If you need Flux docs: [FluxCD Documentation](https://fluxcd.io/docs/). *** ## 1) Switch to the demo branch Checkout the branch that contains the manifests to deploy (in this demo: `2-demo`). ```bash theme={null} # from ~/bb-app-source git checkout 2-demo # example output: # Branch '2-demo' set up to track remote branch '2-demo' from 'origin'. # Switched to branch '2-demo' ``` The manifests in this branch reference the updated image and application version. Example excerpt: ```yaml theme={null} env: dev version: 7.2.0 spec: containers: - name: app image: siddharth67/block-buster-dev:7.2.0 imagePullPolicy: Always resources: requests: memory: "10Mi" cpu: "10m" limits: memory: "64Mi" cpu: "20m" ``` *** ## 2) Create a GitRepository source (imperative vs declarative) You can create a `GitRepository` source imperatively using the Flux CLI. This will create the resource in the cluster and fetch an artifact immediately: ```bash theme={null} flux create source git 2-demo-source-git-bb-app \ --url https://github.com/sidd-harth-2/bb-app-source \ --branch 2-demo \ --timeout 10s ``` Example CLI output (shortened): ```text theme={null} +generating GitRepository source ▸ applying GitRepository source ✔ GitRepository source created ◎ waiting for GitRepository source reconciliation ✔ GitRepository source reconciliation completed ✔ fetched revision: 2-demo@sha1:7dfa8105ebcd... ``` Validate the created source is stored as an artifact: ```bash theme={null} flux get sources git # NAME REVISION SUSPENDED READY MESSAGE # 2-demo-source-git-bb-app 2-demo@sha1:7dfa8105... False True stored artifact for revision '2-demo@sha1:7dfa8105' # flux-system main@sha1:cf1664a0 False True stored artifact for revision 'main@sha1:cf1664a0' ``` Creating Flux resources imperatively is useful for quick tests, but it's not recommended for long-term management. If the resource only exists in-cluster (and not in your Git repo), you lose the ability to recreate or audit desired state from Git after a disaster. *** ## 3) Store the source declaratively (export YAML and commit) Switch to your Flux cluster repository and export the `GitRepository` manifest to YAML. Committing this file to Git ensures Flux controllers can reconcile it from your repository. ```bash theme={null} cd ~/block-buster/flux-clusters/dev-cluster flux create source git 2-demo-source-git-bb-app \ --url https://github.com/sidd-harth-2/bb-app-source \ --branch 2-demo \ --timeout 10s \ --export > 2-demo-source-git-bb-app.yml ``` Example exported YAML: ```yaml theme={null} --- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: GitRepository metadata: name: 2-demo-source-git-bb-app namespace: flux-system spec: interval: 1m0s ref: branch: 2-demo url: https://github.com/sidd-harth-2/bb-app-source ``` Commit the file (e.g., under `flux-clusters/dev-cluster`) so Flux can pick it up from Git. *** ## 4) Create a Kustomization that points to the source and manifests path Export a `Kustomization` resource that references the `GitRepository` source and points to the folder inside that repo containing the manifests (in this demo: `./manifests`). Save the exported YAML and commit it to your Flux cluster repo. ```bash theme={null} flux create kustomization 2-demo-kustomize-git-bb-app \ --source GitRepository/2-demo-source-git-bb-app \ --path ./manifests \ --prune true \ --interval 10s \ --target-namespace 2-demo \ --export > 2-demo-kustomize-git-bb-app.yml ``` Example exported `Kustomization` YAML: ```yaml theme={null} --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: 2-demo-kustomize-git-bb-app namespace: flux-system spec: interval: 10s path: ./manifests prune: true sourceRef: kind: GitRepository name: 2-demo-source-git-bb-app targetNamespace: 2-demo ``` Key spec fields at a glance: | Field | Purpose | Example / Notes | | - | - | - | | `sourceRef` | Links the Kustomization to the `GitRepository` resource | `kind: GitRepository`, `name: 2-demo-source-git-bb-app` | | `path` | Folder inside the source repo containing manifests | `./manifests` | | `targetNamespace` | Namespace where resources will be applied | `2-demo` | | `prune` | Ensures resources removed in source are pruned from cluster | `true` | Commit both `2-demo-source-git-bb-app.yml` and `2-demo-kustomize-git-bb-app.yml` to your Flux repo (for example, under `flux-clusters/dev-cluster`). *** ## 5) Verify reconciliation and application deployment After committing, Flux controllers will automatically reconcile the new manifests from Git. Check the stored source artifact: ```bash theme={null} flux get sources git # NAME REVISION SUSPENDED READY MESSAGE # 2-demo-source-git-bb-app 2-demo@sha1:7dfa8105 False True stored artifact for revision '2-demo@sha1:7dfa8105' # flux-system main@sha1:f1305af7 False True stored artifact for revision 'main@sha1:f1305af7' ``` Check Kustomization status: ```bash theme={null} flux get kustomizations # NAME REVISION SUSPENDED READY MESSAGE # 2-demo-kustomize-git-bb-app 2-demo@sha1:7dfa8105 False True Applied revision: 2-demo@sha1:7dfa8105 # flux-system main@sha1:f1305af7 False True Applied revision: main@sha1:f1305af7 ``` Confirm the target namespace and the resources were created: ```bash theme={null} kubectl get ns # NAME STATUS AGE # 1-demo Active 27m # 2-demo Active 39s # default Active 77m # flux-system Active 71m # kube-node-lease Active 77m # kube-public Active 77m # kube-system Active 77m ``` List resources in the deployed namespace: ```bash theme={null} kubectl -n 2-demo get all # NAME READY STATUS RESTARTS AGE # pod/block-buster-75f7754b9-cjjxm 1/1 Running 0 51s # # NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE # service/block-buster-service NodePort 10.98.139.12 80:30002/TCP 51s # # NAME READY UP-TO-DATE AVAILABLE AGE # deployment.apps/block-buster 1/1 1 1 51s # # NAME DESIRED CURRENT READY AGE # replicaset.apps/block-buster-75f7754b9 1 1 1 51s ``` Open the NodePort service in your browser (use a cluster node IP and the NodePort shown) to verify the running application. In this demo the application image is version v7.2.0, which updates the gameplay visuals slightly compared to the previous version: ![A screenshot of a browser-based Breakout-style game titled "BLOCK BUSTER," showing rows of colored bricks, a paddle at the bottom and a yellow ball in play. Above the game area is a status panel with pod name, pod IP, namespace and app version details.](https://mintcdn.com/kodekloud-c4ac6d9a/AyhVWHpoMIYCWiei/images/GitOps-with-FluxCD/Source-and-Kustomize-Controller/Demo-Kustomize-Controller-Plain-YAML-Manifests-in-Different-Repo/block-buster-breakout-game-pod-status.jpg?fit=max\&auto=format\&n=AyhVWHpoMIYCWiei\&q=85\&s=747b40a2d8a8cecd43838fa5f09f59de) *** ## Summary You have: * Created a `GitRepository` source pointing to an external repository containing plain YAML manifests. * Created a `Kustomization` that deploys those manifests into a cluster namespace. * Followed the recommended declarative workflow: export -> commit -> Flux reconciles from Git. Further reading * FluxCD docs: [https://fluxcd.io/docs/](https://fluxcd.io/docs/) * Kustomize toolkit controllers: [https://fluxcd.io/docs/components/kustomize/](https://fluxcd.io/docs/components/kustomize/) * Kubernetes concepts: [https://kubernetes.io/docs/concepts/](https://kubernetes.io/docs/concepts/) > **[Watch Video](https://learn.kodekloud.com/user/courses/gitops-with-fluxcd/module/857e34cf-a086-433b-bf3b-88a5a5096a6f/lesson/0a35e61b-97b5-4843-a2a0-4ca83525a2f7)** This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.