FluxCD for continuous delivery in Kubernetes - Deep Dive

Overview - FluxCD for continuous delivery

What is it?

FluxCD is a tool that helps automatically update your applications running on Kubernetes. It watches your code or configuration stored in a Git repository and applies any changes to your Kubernetes cluster. This way, your cluster always matches what is defined in Git, making deployments smooth and reliable.

Why it matters

Without FluxCD, updating applications on Kubernetes can be manual, error-prone, and slow. FluxCD solves this by automating deployments directly from Git, ensuring consistency and reducing human mistakes. This means faster updates, safer rollbacks, and clear tracking of changes, which is crucial for modern software delivery.

Where it fits

Before learning FluxCD, you should understand basic Kubernetes concepts like pods, deployments, and manifests. After FluxCD, you can explore advanced GitOps practices, other continuous delivery tools, and Kubernetes security and scaling strategies.

Mental Model

Core Idea

FluxCD continuously syncs your Kubernetes cluster with the desired state defined in your Git repository, making Git the single source of truth for deployments.

Think of it like...

FluxCD is like a smart gardener who constantly checks a garden plan (Git) and makes sure the garden (Kubernetes cluster) looks exactly like the plan, planting or removing flowers as needed without you lifting a finger.

┌───────────────┐      Watches       ┌───────────────┐
│   Git Repo    │───────────────────▶│   FluxCD      │
│ (Desired State)│                    │ (Controller)  │
└───────────────┘                    └───────────────┘
         ▲                                   │
         │                                   │ Applies changes
         │                                   ▼
┌───────────────┐                    ┌───────────────┐
│ Kubernetes    │◀──────────────────│   FluxCD      │
│ Cluster       │    Reports status │ (Controller)  │
└───────────────┘                    └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding GitOps Basics

Concept: GitOps is a way to manage infrastructure and applications using Git as the source of truth.

GitOps means you store all your Kubernetes configurations in Git. Any change to your cluster comes from changes in Git. This makes deployments predictable and easy to track.

Result

You know that Git holds the exact desired state of your cluster and that any change should start there.

Understanding GitOps is key because FluxCD is a GitOps tool that automates syncing Git changes to Kubernetes.

2

Foundation

Kubernetes Manifests and Clusters

Concept: Kubernetes uses manifest files to describe the desired state of applications and resources.

Manifests are YAML files that tell Kubernetes what to run, like pods or services. The cluster reads these and tries to match the described state.

Result

You can write simple manifests and understand how Kubernetes applies them to run your apps.

Knowing manifests is essential because FluxCD applies these files from Git to your cluster.

3

Intermediate

FluxCD Installation and Components

Concept: FluxCD runs inside your Kubernetes cluster and has components that watch Git and apply changes.

You install FluxCD using commands or manifests. It includes controllers that monitor Git repositories and reconcile the cluster state automatically.

Result

FluxCD is running in your cluster, ready to watch your Git repo and sync changes.

Knowing FluxCD’s components helps you understand how it continuously manages your cluster.

4

Intermediate

Connecting FluxCD to Git Repository

🤔Before reading on: do you think FluxCD can work with any Git repo or only special ones? Commit to your answer.

Concept: FluxCD connects to your Git repository using credentials and watches specific paths for changes.

You configure FluxCD with the Git repo URL and authentication (like SSH keys). It then monitors the repo for updates in manifests.

Result

FluxCD detects changes in Git and prepares to apply them to the cluster.

Understanding this connection is crucial because secure and correct Git access ensures reliable deployments.

5

Intermediate

Automated Sync and Reconciliation

🤔Before reading on: do you think FluxCD applies changes instantly or waits for manual approval? Commit to your answer.

Concept: FluxCD automatically applies changes from Git to the cluster at regular intervals or on events.

FluxCD pulls the latest manifests and compares them with the cluster state. If differences exist, it applies the changes to match Git.

Result

Your cluster state always matches what is in Git without manual intervention.

Knowing this automation reduces manual errors and speeds up delivery cycles.

6

Advanced

Handling Rollbacks and Drift Detection

🤔Before reading on: do you think FluxCD can detect manual changes in the cluster and fix them? Commit to your answer.

Concept: FluxCD detects if the cluster drifts from Git and can roll back unwanted changes.

If someone changes the cluster directly, FluxCD notices the difference and reverts the cluster to the Git state. You can also roll back by reverting Git commits.

Result

Cluster state stays consistent and safe from accidental manual changes.

Understanding drift detection helps maintain cluster integrity and trust in automated deployments.

7

Expert

Multi-Tenancy and Scalability with FluxCD

🤔Before reading on: do you think one FluxCD instance can manage multiple clusters or repos? Commit to your answer.

Concept: FluxCD supports managing multiple clusters and repositories with separate configurations for scalability and security.

You can run multiple FluxCD instances or configure one to watch multiple repos and clusters. This allows teams to work independently and scale deployments.

Result

Large organizations can use FluxCD to manage complex environments efficiently.

Knowing FluxCD’s multi-tenancy capabilities is key for designing scalable, secure delivery pipelines in production.

Under the Hood

FluxCD runs controllers inside Kubernetes that continuously poll the configured Git repository. It fetches manifests, parses them, and compares them with the live cluster state. Using Kubernetes APIs, it applies changes to reconcile differences. It also monitors cluster events to detect drift and reports status back to Git or monitoring tools.

Why designed this way?

FluxCD was designed to leverage Git as the single source of truth, simplifying deployment workflows and improving auditability. Using Kubernetes controllers allows it to run natively inside the cluster, providing real-time reconciliation and scalability. Alternatives like manual kubectl apply or CI pipelines were less reliable and harder to track.

┌───────────────┐
│   Git Repo    │
│ (Manifests)   │
└──────┬────────┘
       │ Polls
       ▼
┌───────────────┐       Compares       ┌───────────────┐
│  FluxCD       │────────────────────▶│ Kubernetes    │
│ Controllers   │                      │ Cluster State │
└──────┬────────┘                      └───────────────┘
       │ Applies changes
       ▼
┌───────────────┐
│ Cluster APIs  │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does FluxCD automatically deploy any change pushed to Git without configuration? Commit yes or no.

Common Belief: FluxCD deploys every change in Git immediately without any setup.

Reality: FluxCD requires configuration to specify which branches, paths, and manifests to watch and deploy. Not all Git changes trigger deployments.

Why it matters: Assuming automatic deployment can cause confusion and failed deployments if FluxCD is not properly configured.

Quick: Can FluxCD manage non-Kubernetes applications directly? Commit yes or no.

Common Belief: FluxCD can deploy any application, not just Kubernetes workloads.

Reality: FluxCD is designed specifically for Kubernetes and manages Kubernetes manifests. It does not deploy non-Kubernetes apps directly.

Why it matters: Trying to use FluxCD outside Kubernetes leads to wasted effort and misunderstanding of its scope.

Quick: If someone manually changes the cluster, does FluxCD ignore those changes? Commit yes or no.

Common Belief: Manual changes to the cluster are permanent and FluxCD won’t fix them.

Reality: FluxCD detects drift from Git and automatically reverts manual changes to keep the cluster consistent.

Why it matters: Knowing this prevents confusion when manual fixes disappear and encourages managing changes via Git only.

Quick: Does FluxCD require a central server outside Kubernetes to run? Commit yes or no.

Common Belief: FluxCD needs an external server or service to operate.

Reality: FluxCD runs entirely inside the Kubernetes cluster as native controllers, no external server needed.

Why it matters: This affects deployment architecture and simplifies operations by reducing external dependencies.

Expert Zone

1

FluxCD supports 'Kustomize' and 'Helm' integrations, allowing flexible templating and parameterization of manifests, which many users overlook initially.

2

FluxCD’s reconciliation loop is eventually consistent, meaning changes may take a few seconds to apply, which can affect timing-sensitive deployments.

3

FluxCD can emit detailed status and health metrics that integrate with monitoring tools, enabling advanced alerting and observability.

When NOT to use

FluxCD is not suitable if you need to deploy non-Kubernetes workloads or require complex multi-step pipelines with heavy scripting. In such cases, consider tools like ArgoCD for more UI-driven GitOps or Jenkins for general CI/CD pipelines.

Production Patterns

In production, teams use FluxCD with branch-based environments (e.g., staging, production branches), automated image update controllers to keep container images fresh, and integrate FluxCD with policy engines like OPA Gatekeeper for security compliance.

Connections

Continuous Integration (CI)

Builds-on

FluxCD complements CI by handling deployment after CI builds and tests code, forming a complete automated delivery pipeline.

Infrastructure as Code (IaC)

Shares principles

Both FluxCD and IaC treat infrastructure and apps as code, enabling version control, repeatability, and auditability.

Supply Chain Management (Logistics)

Similar process flow

FluxCD’s syncing from Git to cluster mirrors how supply chains ensure goods move from source to destination reliably and traceably.

Common Pitfalls

#1 Not configuring FluxCD with correct Git credentials causes sync failures.

Wrong approach:

flux bootstrap github --owner=myorg --repository=myrepo --branch=main

Correct approach:

flux bootstrap github --owner=myorg --repository=myrepo --branch=main --personal

Root cause:

Missing authentication flags or keys leads FluxCD to fail accessing private repos.

#2 Applying manifests manually while FluxCD is managing the cluster causes conflicts.

Wrong approach:

kubectl apply -f deployment.yaml

Correct approach:

Make changes in Git and let FluxCD apply them automatically.

Root cause:

Not trusting Git as the single source of truth breaks GitOps principles and causes drift.

#3 Ignoring FluxCD sync status leads to unnoticed deployment failures.

Wrong approach:

Not checking FluxCD logs or status after pushing changes.

Correct approach:

Use 'flux get kustomizations' and 'flux logs' to monitor deployment health.

Root cause:

Assuming deployments always succeed without verification causes delayed issue detection.

Key Takeaways

FluxCD automates Kubernetes deployments by syncing cluster state with Git, making Git the single source of truth.

It runs inside Kubernetes as controllers that continuously watch Git and apply changes automatically.

FluxCD detects and corrects manual changes in the cluster to maintain consistency and reliability.

Proper configuration of Git access and understanding FluxCD’s reconciliation process are essential for success.

In production, FluxCD supports advanced patterns like multi-tenancy, automated image updates, and policy enforcement.

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