GitOps - Part 1

GitOps provides a way to declare the state of the cluster as code and make it so. This ensures that there is no drift between the current and desired state of cluster. There are many tools emerging in this area and one of the tool that’s interesting is the Flux v2 also called GitOps ToolKit from the founders who coined the term GitOps . The details of the tool can be found here.To understand more about Gitops visit this link.

There are many components of GitOps ToolKit. In this article, we will look at three of them. These are different controllers which behave the same way as kubernetes controller which reconcile different sources with kubernetes much like kubernetes does the reconciliation of pods, replica sets and deployments. The controllers are as below.

1. Source Controller - This will reconcile different sources like GitHub,GitLab and S3 buket with the kubernetes cluster
2. Kustomize Controller - This will reconcile the plain kubernetes YAML and also the kustomize objects with the kubernetes cluster
3. Helm Controller - This will reconcile the Helm charts with the kubernetes cluster.

We can install the flux CLI as described in this article. This provides a way to bootstrap all the flux components(described above) to a git repo at the specificed branch and path as mentioned below. 

flux bootstrap github \
  --owner=$GITHUB_USER \
  --repository=gitopsflux \
  --branch=master \
  --path=./clusters/my-cluster \
  --personal

Verify the flux components installation by running the command as shown.

kubectl get pod -n flux-system

Once the flux components are installed , We will look at installing the helm chart using the helm controller. I am installing a secret store csi provider helm chart for azure key vault to store the secrets. This is done by first adding the helm repo as shown below.

flux create source helm csi-secrets-store-provider-azure \
  --url=https://raw.githubusercontent.com/Azure/secrets-store-csi-driver-provider-azure/master/charts \
  --interval=5m \
  --export > ./clusters/my-cluster/helmrepo-csi-secrets-store-provider-azure-source.yaml

The yaml generated from the above command will be as shown below.

---
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: csi-secrets-store-provider-azure
  namespace: flux-system
spec:
  interval: 5m0s
  url: https://raw.githubusercontent.com/Azure/secrets-store-csi-driver-provider-azure/master/charts

We can verify the successful execution once these changes are pushed to the git repo by running the below command

flux get sources helm

Next, we will install the helm chart using the below command

flux create hr csi-secrets-store-provider-azure  \
  --interval=5m \
  --source=HelmRepository/csi-secrets-store-provider-azure \
  --chart=csi-secrets-store-provider-azure \
  --chart-version="0.0.16" \
  --export > ./clusters/my-cluster/helmrelease-csi-secrets-store-provider-azure-source.yaml

This command uses the helm repo defined earlier as the source and we can also specify the version of the helm chart and the yaml generated will be as shown below.

---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: csi-secrets-store-provider-azure
  namespace: flux-system
spec:
  chart:
    spec:
      chart: csi-secrets-store-provider-azure
      sourceRef:
        kind: HelmRepository
        name: csi-secrets-store-provider-azure
      version: 0.0.16
  interval: 5m0s

We can verify the successful execution once these changes are pushed to the git reop by running the below command

flux get helmreleases

We will next look at using the kustomize controller which in my case using it for installing the SQL backend components as well as the application components.

First we need to specify the git source where the kustomization are defined as shown below. The source controller will reconcile the git repository to the kubernetes cluster.

flux create source git gitopsflux \
  --url=https://github.com/girishgouda/gitopsflux \
  --branch=master \
  --interval=30s
  --export > ./clusters/my-cluster/git-source.yaml

The yaml generated from the above command will be as shown below.

---
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
  name: gitopsflux
  namespace: flux-system
spec:
  interval: 30s
  ref:
    branch: master
  url: https://github.com/girishgouda/gitopsflux

We can verify the successful execution once these changes are pushed to the git repo by running the below command

flux get sources git

Next, we can define the path from where the kustomization files can be applied using the git source as shown below.

flux create kustomization sqlbackend \
  --source=gitopsflux \
  --path="./kustomize/sql/overlay/local/" \
  --prune=true \
  --validation=client \
  --interval=5m
  --export > ./clusters/my-cluster/sqlbackend-kustomization.yaml

The yaml generated from the above command will be as shown below.

---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
  name: sqlbackend
  namespace: flux-system
spec:
  interval: 5m0s
  path: ./kustomize/sql/overlay/local
  prune: true
  sourceRef:
    kind: GitRepository
    name: gitopsflux
  validation: client

We can verify the successful execution once these changes are pushed to the git repo by running the below command.

flux get kustomizations

In most of the application deployment, we need to specify the order in which the kustomization files are to be applied. Ex The application or the frontend container are deployed after the backend or the API container. This can be done using the dependsOn property as shown below.

---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
  name: poiapp
  namespace: flux-system
spec:
  interval: 5m0s
  path: ./kustomize/apps/poi/overlay/local
  prune: true
  sourceRef:
    kind: GitRepository
    name: gitopsflux
  validation: client
  dependsOn: 
  - name : sqlbackend

These are some of the fundamentals on which Flux v2 is built upon. In the future articles, we will look at some more interesting features.