Kratix Ep 6: FluxCD GitOps Integration

1. The Flux Architecture (WHAT)

#

In Episode 5, we learned that Kratix writes our generated E-Commerce Redis YAML to a State Store (which is just a standard GitHub repository named kratix-state).

To synchronize this repository with a Kubernetes cluster using Flux, we do not use a single Application object like ArgoCD. Instead, Flux uses a more modular approach, requiring two distinct Custom Resources on the Worker Cluster:

1. GitRepository: This resource tells Flux how to authenticate with GitHub, which branch to look at, and how to fetch the code into memory.
2. Kustomization: This resource tells Flux which specific directory within that repository to watch, and how often to apply the YAML found inside it to the cluster.

2. Installing Flux on the Worker Cluster (WHERE)

#

Ensure you switch your kubectl context to your Worker Cluster (e.g., prod-us-east). We do not install Flux on the Platform Cluster for workload delivery.

The easiest and most reliable way to install Flux is using its official CLI. (If you don’t have the CLI installed on your machine, download it from the Flux installation documentation).

Execute the bootstrap command to install the core Flux controllers:

flux install

Verify that the Helm, Kustomize, Source, and Notification controllers are running successfully:

kubectl get pods -n flux-system

3. Configuring the GitRepository (HOW)

#

We must instruct the Flux Source Controller to clone the kratix-state repository and keep a cached copy of it updated.

Create a file named flux-kratix-repo.yaml:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: kratix-state-repo
  namespace: flux-system
spec:
  # Polling interval: How often Flux checks GitHub for new Kratix commits
  interval: 1m
  url: https://github.com/acmecorp/kratix-state.git
  ref:
    branch: main
  # If the repo is private (which it should be), reference a Kubernetes Secret 
  # containing your GitHub Deploy Key or Personal Access Token (PAT).
  secretRef:
    name: github-deploy-key

Apply the repository configuration to the cluster:

kubectl apply -f flux-kratix-repo.yaml

The Flux Source Controller will now continuously pull the main branch of that repository into memory every 1 minute. You can verify this by running flux get sources git.

4. Configuring the Kustomization (HOW)

#

Now that Flux has the code cached in memory, we must tell the Flux Kustomize Controller which specific directory belongs to this Worker Cluster, and to apply those manifests to the Kubernetes API.

Create a file named flux-kratix-kustomization.yaml:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: kratix-workloads
  namespace: flux-system
spec:
  # How often Flux attempts to apply the YAML
  interval: 1m
  
  # Link to the GitRepository source we just created in the previous step
  sourceRef:
    kind: GitRepository
    name: kratix-state-repo
  
  # Crucial: Only apply YAML from this specific cluster's directory!
  # If you omit this, Flux will try to install workloads meant for ALL clusters.
  path: ./clusters/prod-us-east/
  
  # Prune ensures that if Kratix deletes a file in Git (because a developer 
  # deleted their claim), Flux will delete the corresponding resource in Kubernetes.
  prune: true
  
  # Wait for all resources to become ready before considering the sync successful
  wait: true

Apply the kustomization configuration:

kubectl apply -f flux-kratix-kustomization.yaml

5. Validating the Sync (WHEN)

#

Because Flux does not have a Web UI by default, you must monitor the synchronization using the CLI. This is the primary difference in operational experience between Flux and ArgoCD.

To check if Flux successfully pulled the Kratix workloads, run:

flux get kustomizations

Expected Terminal Output:

NAME                REVISION            SUSPENDED   READY   MESSAGE
kratix-workloads    main/a1b2c3d4       False       True    Applied revision: main/a1b2c3d4

Whenever the E-Commerce developer requests a new Redis environment in the Kratix Platform Cluster, Kratix will commit the new YAML to Git, the revision hash in GitHub will change, the Flux Source Controller will detect it within 1 minute, and the Flux Kustomize Controller will automatically reconcile the new YAML into the Worker cluster.

Conclusion & Next Steps

#

Whether you choose to use ArgoCD or Flux, the Kratix architecture remains completely identical from the perspective of the Platform Engineer. Kratix owns the orchestration, the logic, and the YAML generation, while the GitOps agent (Argo or Flux) strictly owns the physical delivery and synchronization.

However, we have so far ignored a massive elephant in the room: Passwords, API Keys, and Secrets.

If our Kratix pipeline generates a secure Redis database, it must also generate a secure password for the E-Commerce team to use to authenticate with it. It absolutely cannot commit that plaintext password to the kratix-state GitHub repository! That is a critical security violation that breaks compliance standards like SOC2 or PCI-DSS. Git is for code, not credentials.

In Episode 7: Secrets Management with ESO and Vault, we will learn how Kratix handles sensitive data by pushing it securely through a side-channel to HashiCorp Vault, and using the External Secrets Operator (ESO) on the Worker Cluster to retrieve it safely.