Continuous Delivery using GitOps Principles with FluxCD

Wed, 24/04/2024 | 6 minutes

Satish Annavar

Angita Shah

Continuous Delivery using GitOps Principles with FluxCD | Platform Engineers

Continuous Delivery (CD) automates the software release process, allowing teams to deliver features quickly and reliably. By combining CD practices with GitOps principles, developers can keep version control tools to manage their infrastructure and applications, ensuring consistent and predictable outcomes through automated pipelines.

Prerequisites

Before proceeding, ensure the following requirements are met:

A running Kubernetes cluster accessible to you. Refer to the Kubernetes Docs for setup guidance.
Access to the Starter Kit repository. (Refer this instructions on how to run this repository)
Familiarity with Kubernetes interactions, including connecting to clusters using kubectl.

Reconciling Cluster State with Git Repository

FluxCD synchronizes the state of your infrastructure using Git as the source of truth, following GitOps principles. This process, called reconciliation, ensures applications match a desired state declaratively defined somewhere, such as a Git repository, Helm repository, or S3 bucket. FluxCD provides several ways to achieve reconciliation:

Helm Controller defined in a Git repository or S3 bucket.
Controllers containing necessary logic to fetch artifacts containing declarative state manifests and apply required changes to your cluster.

Source CRD (Custom Resource Definition)

FluxCD treats sources as a way of fetching artifacts containing state configuration. For example, it can pull data from Git repositories, Helm repositories, S3 buckets, etc.

Implementing CD with FluxCD

The Starter Kit uses the Git repository source type and HelmReleases for maintaining application state. Each chapter of the Starter Kit uses Helm to perform application deployment, making HelmReleases a natural choice for managing application lifecycle via the standard package manager for Kubernetes.

Managing Helm Charts with FluxCD

FluxCD handles Helm charts through dedicated custom resource definitions (CRDs), specifically the HelmRepository and HelmRelease CRDs. These resources allow FluxCD to manage Helm repositories and fetch charts from remote locations, similar to running helm repo add <name> < url > and helm repo update.

Typical Structure of a HelmRepository Manifest

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: polymorphic-helm-source
  namespace: flux-system
spec:
  interval: 10m0s
  url: https://improwised.github.io/charts/

Typical Structure of a HelmRelease Manifest

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx-app
  namespace: flux-system
spec:
  chart:
    spec:
      chart: polymorphic-app
      reconcileStrategy: ChartVersion
      version: 1.3.0
      sourceRef:
        kind: HelmRepository
        name: polymorphic-helm-source
        namespace: flux-system
  interval: 10m

Each Flux CD HelmRelease can override values via a values file or individually using key-value pairs.

Overriding Values with FluxCD

FluxCD lets you override Helm values via two spec types:

< spec.values > : Allows overriding values inline as seen in a standard values.yaml file.
< spec.valuesFrom > : Allows overriding values individually by using each key's fully qualified path from the values file.

Typical usage of spec.values

...
spec:
  values:
    fullnameOverride: "nginx"
    # service template
    serviceTemplate:
      autoscaling: false
      minReplicaCount: 1
      maxReplicaCount: 1
      env: []
      envFrom: []
    services:
      - name: nginx-app
        image:
          repository: nginx
          tag: 1.25.4-alpine
        minReplicaCount: 1
        ports:
          - name: http
            containerPort: 80
            protocol: TCP

...

Deploying FluxCD to Your Kubernetes Cluster

Deploying FluxCD involves using its CLI tool to execute commands on your Kubernetes cluster. To begin, you must first authenticate yourself to your cluster and obtain a personal access token. You can verify that everything is working correctly by performing some sanity checks:

flux check

The output of the flux check command will indicate whether or not the configuration files are correctly deployed on your cluster. If there are no differences, you should see a message similar to the following:

Checking sync status...
Waiting for API server to become ready...
Syncing now...
Successfully synced 0 resources

If there are differences, the command will provide details about which resources need to be updated to match the desired state. In such cases, you may need to manually update the configuration files in the Git repository to reflect the changes you want to make.

flux get all

NAME                                          	REVISION       	SUSPENDED	READY	MESSAGE                                     
helmrepository/actions-runner-controller      	sha256:6469d242	False    	True 	stored artifact: revision 'sha256:6469d242'	
helmrepository/bitnami                        	sha256:293ea2e0	False    	True 	stored artifact: revision 'sha256:293ea2e0'	
helmrepository/polymorphic-helm-source                        	              	False    	True 	Helm repository is Ready

NAME                                                         	REVISION	SUSPENDED	READY	MESSAGE                                                              
helmchart/actions-runner-controller-actions-runner-controller	0.21.0  	False    	True 	pulled 'actions-runner-controller' chart with version '0.21.0'      	
helmchart/nginx-app                            	1.3.0   	False    	True 	pulled 'polymorphic-app' chart with version '1.3.0'

This command displays information about the various components managed by FluxCD, allowing you to confirm that everything is configured correctly.

Configuring FluxCD to Deploy Applications

To configure FluxCD to deploy applications, you need to create a HelmReleases resource that references the HelmRelease CRD. This HelmReleases resource will be responsible for deploying the application to your cluster.

Typical Structure of a HelmRepository Manifest

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
  name: my-app
  namespace: flux-system
spec:
  resources:
  - helmreleases/my-app.yaml

Deploying Applications with FluxCD

Once you have created the HelmReleases resource, you can deploy your application by applying the HelmReleases manifest to your cluster:

kubectl apply -f my-app.yaml

This command deploys the application to your cluster, and FluxCD will automatically reconcile the application state with the desired state defined in the HelmRelease CRD.

Monitoring and Troubleshooting FluxCD

FluxCD provides several tools for monitoring and troubleshooting your cluster. You can use the flux logs command to view logs for all FluxCD components:

flux logs

To demonstrate the usage of Flux logs command, let's assume we have Flux installed in our cluster with custom resources named monitoring-configs in the namespace flux-system. We want to see the logs for this specific custom resource for the last minute. Here's how we can use the flux logs command to achieve this:

flux logs --kind=Helmrelease --name=nginx-app --namespace=flux-system
2024-04-08T11:55:58.971Z info HelmRelease/nginx-app.flux-system - reconcilation finished in 110.570109ms, next run in 10m0s 
2024-04-08T12:05:59.167Z info HelmRelease/nginx-app.flux-system - reconcilation finished in 195.47602ms, next run in 10m0s 
2024-04-08T12:15:59.340Z info HelmRelease/nginx-app.flux-system - reconcilation finished in 170.867232ms, next run in 10m0s 
2024-04-08T12:25:59.451Z info HelmRelease/nginx-app.flux-system - reconcilation finished in 99.786584ms, next run in 10m0s

flux logs --kind=Helmrepository --name=polymorphic-helm-source --namespace=flux-system
2024-03-29T10:55:35.203Z info HelmRepository/polymorphic-helm-source.flux-system - Discarding event, no alerts found for the involved object 
2024-03-29T12:55:35.985Z info HelmRepository/polymorphic-helm-source.flux-system - Discarding event, no alerts found for the involved object 
2024-04-04T10:56:11.562Z info HelmRepository/polymorphic-helm-source.flux-system - Discarding event, no alerts found for the involved object 
2024-04-08T04:56:35.119Z info HelmRepository/polymorphic-helm-source.flux-system - artifact up-to-date with remote revision: 'sha256:61d24125f529fff38a042f443e87ddd5ae2775a2af674e29926e0ca6e75e525b' 
2024-04-08T05:56:35.450Z info HelmRepository/polymorphic-helm-source.flux-system - artifact up-to-date with remote revision: 'sha256:61d24125f529fff38a042f443e87ddd5ae2775a2af674e29926e0ca6e75e525b'

This output shows us the logs related to our monitoring-configs custom resource in the flux-system namespace for the last minute (since 1m ago). It includes information about the status of the reconciliation process, such as when all dependencies were ready, when server-side apply was completed, and when the reconciliation finished. By analyzing these logs, we can gain insights into how our Flux components are operating and troubleshoot any issues that might arise.

flux get all

NAME                                          	REVISION       	SUSPENDED	READY	MESSAGE                                     
helmrepository/actions-runner-controller      	sha256:6469d242	False    	True 	stored artifact: revision 'sha256:6469d242'	
helmrepository/bitnami                        	sha256:293ea2e0	False    	True 	stored artifact: revision 'sha256:293ea2e0'	
helmrepository/polymorphic-helm-source                        	              	False    	True 	Helm repository is Ready

NAME                                                         	REVISION	SUSPENDED	READY	MESSAGE                                                              
helmchart/actions-runner-controller-actions-runner-controller	0.21.0  	False    	True 	pulled 'actions-runner-controller' chart with version '0.21.0'      	
helmchart/nginx-app                            	1.3.0   	False    	True 	pulled 'polymorphic-app' chart with version '1.3.0'

This command displays information about the various components managed by FluxCD, allowing you to confirm that everything is configured correctly.

Conclusion

By following the steps outlined in this guide, you have successfully implemented Continuous Delivery using GitOps principles with FluxCD. You have learned how to manage Helm repositories and charts, reconcile your kubernetes cluster state with a Git repository, and use FluxCD to automate your infrastructure management and application deployment processes. With FluxCD installed and configured, you can now focus on delivering high-quality software while ensuring consistent and predictable outcomes through automated pipelines.

Webhooks allow for immediate deployment of new versions when certain events occur. They work by sending an HTTP POST request to a specified URL whenever a specific event happens, triggering the deployment process.

The FluxCD Notification Controller is responsible for handling both incoming and outgoing events within the GitOps toolkit ecosystem. It serves two primary functions:

Handling incoming events: The controller receives events from external systems such as GitHub, GitLab, Bitbucket, Harbor, Jenkins, and others. These events are related to source changes that need to be notified to the GitOps Toolkit controllers.
Dispatching outgoing events: The Notification Controller also handles events emitted by the GitOps Toolkit controllers (source, kustomize, helm) and dispatches them to external systems like Slack, Microsoft Teams, Discord, and others based on event severity and involved objects. This ensures that the appropriate teams are notified about the status of their GitOps pipelines.

Here is an example of notification controller:

Slack notification of release successful:

Helm Controller Notification

Slack notification of error:

Fluxcd Error