FluxCD for continuous delivery in Kubernetes - Step-by-Step Execution

Process Flow - FluxCD for continuous delivery

Start: Developer pushes code to Git

↓

FluxCD detects Git changes

↓

FluxCD pulls updated manifests

↓

FluxCD applies manifests to Kubernetes cluster

↓

Cluster state updated to match Git

↓

Monitor for drift and repeat

FluxCD watches your Git repository for changes, then updates your Kubernetes cluster to match those changes automatically.

Execution Sample

Kubernetes

flux reconcile source git my-app
flux reconcile kustomization my-app
kubectl get pods

These commands tell FluxCD to sync the Git source and apply the Kubernetes manifests, then check the running pods.

Process Table

Step	Action	Input/Condition	Result/Output
1	Developer pushes code	New manifests committed to Git	Git repository updated
2	FluxCD detects change	Git repo has new commit	Triggers reconciliation
3	FluxCD pulls manifests	Fetch latest manifests from Git	Local cache updated
4	FluxCD applies manifests	Manifests describe deployment	Kubernetes cluster updated
5	Check cluster state	kubectl get pods	Pods reflect new deployment
6	Monitor for drift	Cluster state vs Git state	If drift, repeat sync

💡 FluxCD stops after cluster matches Git state and no drift detected

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	Final
Git Repository	Old manifests	New manifests committed	New manifests fetched	N/A	New manifests
FluxCD Cache	Empty or old	N/A	Updated with new manifests	N/A	Updated
Kubernetes Cluster	Old deployment	Old deployment	Old deployment	Updated deployment applied	Updated deployment
Pods	Old pods running	Old pods running	Old pods running	New pods starting	New pods running

Key Moments - 3 Insights

Why does FluxCD pull manifests from Git instead of pushing changes directly?

FluxCD follows GitOps principles where Git is the single source of truth. It pulls changes to ensure the cluster matches Git exactly, as shown in execution_table step 3.

What happens if the cluster state drifts from Git manifests?

FluxCD detects drift and automatically re-applies manifests to fix it, as described in execution_table step 6.

Why do we check pods after applying manifests?

Checking pods confirms that the new deployment is running correctly, verifying the cluster update in execution_table step 5.

Visual Quiz - 3 Questions

Look at the execution table, at which step does FluxCD update its local cache with new manifests?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Refer to the 'Result/Output' column in step 3 describing 'Local cache updated'

According to the variable tracker, what is the state of the Kubernetes cluster after step 4?

A Old deployment

B New pods running

C Updated deployment applied

D Empty cluster

💡 Hint

Check the 'Kubernetes Cluster' row under 'After Step 4' in variable_tracker

If the developer does not push new code, what will FluxCD do according to the concept flow?

A Detect no changes and do nothing

B Apply old manifests repeatedly

C Delete all resources in cluster

D Crash due to no input

💡 Hint

Look at the concept_flow where FluxCD acts only when it detects Git changes

Concept Snapshot

FluxCD automates continuous delivery by syncing Kubernetes cluster state with Git repository.
It watches Git for changes, pulls updated manifests, and applies them to the cluster.
Git is the single source of truth; cluster state matches Git exactly.
FluxCD monitors for drift and re-applies manifests if needed.
Commands: 'flux reconcile source git' and 'flux reconcile kustomization' trigger sync.
Check cluster state with 'kubectl get pods' after deployment.

Full Transcript

FluxCD is a tool that helps keep your Kubernetes cluster in sync with your Git repository. When a developer pushes new code or configuration files to Git, FluxCD notices the change. It then pulls the updated files and applies them to the Kubernetes cluster. This process ensures the cluster always matches what is defined in Git. After applying changes, you can check the cluster's pods to see the new deployment running. FluxCD also watches for any differences between the cluster and Git, fixing them automatically. This approach is called GitOps, where Git is the single source of truth for your deployments.

Practice

1. What is the primary role of FluxCD in a Kubernetes environment?

easy

A. Automatically sync and deploy application changes from Git to Kubernetes

B. Monitor Kubernetes cluster health and send alerts

C. Manage container image builds and push to registries

D. Provide a user interface for Kubernetes cluster management

Solution

1. Step 1: Understand FluxCD's purpose

   FluxCD is designed to automate continuous delivery by syncing Kubernetes with Git repositories.

2. Step 2: Identify the correct role

   Among the options, only automatic syncing and deploying from Git matches FluxCD's role.

3. Final Answer:

   Automatically sync and deploy application changes from Git to Kubernetes -> Option A

4. Quick Check:

   FluxCD = Git sync and deploy [OK]

Hint: FluxCD syncs Git changes to Kubernetes automatically [OK]

Common Mistakes:

• Confusing FluxCD with monitoring tools
• Thinking FluxCD builds container images
• Assuming FluxCD provides UI for cluster management

2. Which of the following is the correct minimal YAML snippet to define a GitRepository resource for FluxCD?

easy

A. apiVersion: apps/v1
kind: Deployment
metadata:
name: my-repo
spec:
replicas: 1

B. apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRelease
metadata:
name: my-repo
spec:
chart:
repository: https://charts.example.com

C. apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
name: my-repo
spec:
url: https://github.com/example/repo.git

D. apiVersion: v1
kind: Pod
metadata:
name: my-repo
spec:
containers:
- name: app

Solution

1. Step 1: Identify the correct apiVersion and kind for GitRepository

   The GitRepository resource uses apiVersion source.toolkit.fluxcd.io/v1beta2 and kind GitRepository.

2. Step 2: Check the YAML structure

   apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: GitRepository metadata: name: my-repo spec: url: https://github.com/example/repo.git correctly defines metadata and spec with the repository URL, matching FluxCD's GitRepository spec.

3. Final Answer:

   YAML with apiVersion source.toolkit.fluxcd.io/v1beta2 and kind GitRepository -> Option C

4. Quick Check:

   GitRepository YAML = apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: GitRepository metadata: name: my-repo spec: url: https://github.com/example/repo.git [OK]

Hint: GitRepository uses source.toolkit.fluxcd.io/v1beta2 and kind GitRepository [OK]

Common Mistakes:

• Using wrong apiVersion or kind
• Confusing GitRepository with Deployment or Pod
• Missing required spec.url field

3. Given this Kustomization YAML snippet, what will FluxCD do when it applies this resource?

apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: example-app
spec:
  interval: 5m
  path: ./deploy
  prune: true
  sourceRef:
    kind: GitRepository
    name: example-repo
  validation: client

medium

A. FluxCD will build a container image every 5 minutes from './deploy' path

B. FluxCD will sync manifests from the Git repo path './deploy' every 5 minutes and prune removed resources

C. FluxCD will only validate manifests but not apply them

D. FluxCD will deploy manifests once and then stop

Solution

1. Step 1: Analyze the Kustomization spec fields

   The interval field sets sync every 5 minutes; path points to manifests; prune true means remove deleted resources; sourceRef points to GitRepository.

2. Step 2: Understand FluxCD behavior

   FluxCD will fetch manifests from Git, apply them, and prune removed resources every 5 minutes.

3. Final Answer:

   FluxCD will sync manifests from the Git repo path './deploy' every 5 minutes and prune removed resources -> Option B

4. Quick Check:

   Kustomization sync + prune = FluxCD will sync manifests from the Git repo path './deploy' every 5 minutes and prune removed resources [OK]

Hint: Kustomization interval controls sync frequency; prune removes deleted resources [OK]

Common Mistakes:

• Thinking FluxCD builds container images
• Assuming validation means no apply
• Believing sync happens only once

4. You applied a Kustomization resource but FluxCD never deploys your changes. Which of these is the most likely cause?

medium

A. The FluxCD controller pod is running with high CPU usage

B. The Kubernetes cluster is out of disk space

C. The container image tag is not updated in the deployment manifest

D. The GitRepository resource referenced by sourceRef is missing or has wrong name

Solution

1. Step 1: Check Kustomization sourceRef

   If the GitRepository resource named in sourceRef does not exist or is misnamed, FluxCD cannot fetch manifests to deploy.

2. Step 2: Evaluate other options

   Disk space or CPU issues may cause problems but won't prevent FluxCD from attempting deploy; image tag issues affect app behavior but not deployment trigger.

3. Final Answer:

   The GitRepository resource referenced by sourceRef is missing or has wrong name -> Option D

4. Quick Check:

   Missing GitRepository = no deploy [OK]

Hint: Check sourceRef GitRepository exists and matches name exactly [OK]

Common Mistakes:

• Ignoring sourceRef misconfiguration
• Blaming cluster resources without checking FluxCD logs
• Assuming image tag changes trigger deploy automatically

5. You want FluxCD to deploy only when a specific branch 'release' is updated in your Git repository. Which field should you add or modify in the GitRepository resource to achieve this?

hard

A. Add 'ref: branch: release' under spec in GitRepository

B. Set 'interval: 1h' in Kustomization spec

C. Add 'prune: false' in Kustomization spec

D. Set 'validation: none' in Kustomization spec

Solution

1. Step 1: Understand GitRepository branch filtering

   To track a specific branch, the GitRepository spec must include a ref field specifying the branch name.

2. Step 2: Identify correct syntax

   The correct syntax is spec.ref.branch: release, which tells FluxCD to sync only that branch.

3. Step 3: Evaluate other options

   Interval controls sync frequency, prune controls resource removal, validation controls manifest checking; none filter branches.

4. Final Answer:

   Add 'ref: branch: release' under spec in GitRepository -> Option A

5. Quick Check:

   Branch filter = spec.ref.branch [OK]

Hint: Use spec.ref.branch to specify Git branch in GitRepository [OK]

Common Mistakes:

• Changing Kustomization interval instead of GitRepository branch
• Disabling prune or validation to filter branches
• Assuming branch filtering is done in Kustomization