Demo Kustomize Controller Plain YAML Manifests in Different Repo

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.

1) Switch to the demo branch

Checkout the branch that contains the manifests to deploy (in this demo: 2-demo).

# 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:

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:

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):

+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:

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.

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:

---
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.

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:

---
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:

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:

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:

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:

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   <none>        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.

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.

GitOps Overview

Flux Overview

Source and Kustomize Controller

Helm Controller and OCI Registry

Image Automation Controller

Secret Management & Sign Verification

Notification Controller

Monitoring & User Interface

Demo Kustomize Controller Plain YAML Manifests in Different Repo

Prerequisites

1) Switch to the demo branch

2) Create a GitRepository source (imperative vs declarative)

3) Store the source declaratively (export YAML and commit)

4) Create a Kustomization that points to the source and manifests path

5) Verify reconciliation and application deployment

Summary

Watch Video

​Prerequisites

​1) Switch to the demo branch

​2) Create a GitRepository source (imperative vs declarative)

​3) Store the source declaratively (export YAML and commit)

​4) Create a Kustomization that points to the source and manifests path

​5) Verify reconciliation and application deployment

​Summary

Watch Video

Prerequisites

1) Switch to the demo branch

2) Create a GitRepository source (imperative vs declarative)

3) Store the source declaratively (export YAML and commit)

4) Create a Kustomization that points to the source and manifests path

5) Verify reconciliation and application deployment

Summary