FluxCD for continuous delivery in Kubernetes - Mini Project: Build & Apply

FluxCD for continuous delivery

📖 Scenario: You are working as a DevOps engineer for a small company. Your team wants to automate the deployment of applications to Kubernetes clusters using GitOps principles. You will use FluxCD, a tool that watches your Git repository and applies changes automatically to your cluster.

🎯 Goal: Set up a basic FluxCD configuration to deploy a simple Kubernetes application from a Git repository. You will create the initial Kubernetes manifest, configure FluxCD to watch the repository, apply the main deployment logic, and finally verify the deployment.

📋 What You'll Learn

Create a Kubernetes manifest file for a simple Nginx deployment

Add a FluxCD GitRepository resource to point to the Git repo

Create a FluxCD Kustomization resource to apply the deployment

Verify the deployment by checking the FluxCD sync status

💡 Why This Matters

🌍 Real World

FluxCD is widely used in real companies to automate Kubernetes deployments by syncing cluster state with Git repositories. This reduces manual errors and speeds up delivery.

💼 Career

Understanding FluxCD and GitOps is valuable for DevOps roles, Kubernetes administrators, and cloud engineers who manage continuous delivery pipelines.

1

Create the initial Kubernetes manifest

Create a file named nginx-deployment.yaml with a Kubernetes Deployment manifest for Nginx. Use apiVersion: apps/v1, kind: Deployment, and set metadata.name to nginx-deployment. The deployment should have 1 replica and use the image nginx:latest. Include a container port 80.

Kubernetes

# Create nginx-deployment.yaml with the required Deployment manifest
# Your code here

Hint

Remember to set metadata.name exactly to nginx-deployment and use nginx:latest as the container image.

2

Add FluxCD GitRepository resource

Create a file named flux-gitrepository.yaml with a FluxCD GitRepository resource. Set apiVersion to source.toolkit.fluxcd.io/v1beta2 and kind to GitRepository. Name the resource nginx-repo. Set the spec.url to https://github.com/example/nginx-config.git and spec.interval to 1m.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

# Create flux-gitrepository.yaml with GitRepository resource
# Your code here

Hint

Make sure the GitRepository resource has the exact name nginx-repo and the URL matches exactly.

3

Create FluxCD Kustomization resource

Create a file named flux-kustomization.yaml with a FluxCD Kustomization resource. Use apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 and kind: Kustomization. Name it nginx-kustomization. Set spec.interval to 1m, spec.path to ./, and spec.sourceRef.name to nginx-repo with kind GitRepository. This will apply the manifests from the Git repository.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
  name: nginx-repo
spec:
  interval: 1m
  url: https://github.com/example/nginx-config.git

# Create flux-kustomization.yaml with Kustomization resource
# Your code here

Hint

Ensure the Kustomization resource references the nginx-repo GitRepository by name and kind.

4

Verify FluxCD deployment sync status

Run the command flux get kustomizations in your terminal to check the sync status of the nginx-kustomization. This command shows if FluxCD has applied the manifests successfully.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
  name: nginx-repo
spec:
  interval: 1m
  url: https://github.com/example/nginx-config.git
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: nginx-kustomization
spec:
  interval: 1m
  path: ./
  sourceRef:
    kind: GitRepository
    name: nginx-repo

# Run the command below to check FluxCD sync status
# Your code here

Hint

Use the exact command flux get kustomizations to see the status. Look for nginx-kustomization in the output.

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