Up to here you have filled the cluster with commands: kubectl apply in lesson W1.2, helm upgrade in lesson W1.4. That works
as long as a person with access to the cluster sits at the computer. But what if the pipeline is supposed to deliver? Then the pipeline needs
credentials for the cluster, and everyone who may change the pipeline can change anything in the cluster with them. And who will tell you in half
a year why two replicas are running in the cluster although the chart says three? Someone changed it by hand, and nobody knows who any more.
GitOps turns this around. The desired state of the cluster is in Git, and a program runs in the cluster that watches Git and brings the
cluster into line. In this lesson you set that up with Flux on AKS: a configuration repository kladde-config, two kustomizations that
depend on each other, and a HelmRelease for the chart from lesson W1.4. After that you change the cluster only through a pull request and
take the change back with a revert.
The lesson assumes the container basics, the Kladde's pipeline and managed identities; they are in lessons 3.7.5 and 3.3.1. Here the only question is what GitOps does differently on Kubernetes.
The idea: Git is the source, the cluster pulls
With push, the pipeline builds an image and at the end runs kubectl apply or helm upgrade against the cluster. To do that, it has to be able to sign in to the
cluster. With pull, a controller runs in the cluster itself. It reads a Git repository at a fixed interval and
brings the cluster into line with its content. Microsoft describes it like this: The controllers run in the cluster and continuously reconcile its state with the
state that is in the Git repository; Flux allows pull-only delivery, and neither the source repository nor any other cluster
needs access to the cluster.
| Push (the pipeline applies) | Pull (Flux in the cluster) | |
|---|---|---|
| Who has access to the cluster? | the pipeline, with stored credentials or a sign-in | only the controller in the cluster |
| Where is the state? | in the pipeline and in the cluster, never certain to be the same | in Git; the cluster is brought into line |
| Manual work in the cluster | goes unnoticed until someone happens to see it | is overwritten or becomes visible at the next reconciliation |
| A cluster is gone | run the pipeline again, hopefully with the same values | connect a new cluster to the same configuration |
| Taking it back | look for the old pipeline version | git revert and a pull request |
Among the advantages, Microsoft names: seeing the state of the applications continuously, separating teams (whoever writes applications does not have to master Kubernetes delivery themselves), and being able to rebuild a cluster after a crash with the same desired state.
There is a price. The change is no longer there immediately: Flux reconciles at an interval (the default is ten minutes, see below), and a change that fails on a prerequisite fails in the cluster and not in your terminal. You see the error in the state of the objects, not in an exit code. You will learn that in the exercises.