Bird
Raised Fist0
Kubernetesdevops~5 mins

FluxCD for continuous delivery in Kubernetes - Cheat Sheet & Quick Revision

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Recall & Review
beginner
What is FluxCD in the context of Kubernetes?
FluxCD is a tool that automates the deployment of container images and configuration changes to Kubernetes clusters, enabling continuous delivery by syncing Git repositories with the cluster state.
Click to reveal answer
beginner
How does FluxCD use Git in continuous delivery?
FluxCD treats Git as the single source of truth. It continuously monitors Git repositories for changes and applies those changes automatically to the Kubernetes cluster, ensuring the cluster matches the desired state defined in Git.
Click to reveal answer
intermediate
What is a GitRepository resource in FluxCD?
A GitRepository resource in FluxCD defines the location and credentials of a Git repository that FluxCD will watch for changes to deploy to the Kubernetes cluster.
Click to reveal answer
intermediate
Explain the role of the Kustomization resource in FluxCD.
The Kustomization resource tells FluxCD which manifests to apply from the Git repository, how often to sync, and how to handle dependencies, enabling customization of Kubernetes resources during deployment.
Click to reveal answer
beginner
What happens if the Kubernetes cluster drifts from the desired state in Git when using FluxCD?
FluxCD detects the drift and automatically reconciles the cluster back to the desired state defined in Git, ensuring consistency and reliability in deployments.
Click to reveal answer
What is the main purpose of FluxCD?
AMonitor Kubernetes cluster health
BBuild container images from source code
CAutomate continuous delivery by syncing Git with Kubernetes
DManage Kubernetes user access
Which resource in FluxCD defines the Git repository to watch?
AKustomization
BGitRepository
CHelmRelease
DPod
How does FluxCD handle changes made directly in the Kubernetes cluster that differ from Git?
AReconciles cluster back to Git state
BOverrides Git with cluster changes
CIgnores them
DSends an alert but does nothing
What does the Kustomization resource in FluxCD do?
ASpecifies which manifests to apply and sync frequency
BDefines how to build container images
CManages user permissions
DMonitors cluster resource usage
FluxCD is an example of which deployment approach?
AManual deployment
BBlue-green deployment
CCanary deployment
DGitOps
Describe how FluxCD enables continuous delivery in Kubernetes using Git repositories.
Think about how FluxCD watches Git and applies changes to the cluster.
You got /4 concepts.
    Explain the role of the Kustomization resource and how it helps manage deployments in FluxCD.
    Consider how FluxCD knows what and when to deploy from Git.
    You got /4 concepts.

      Practice

      (1/5)
      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