GitOps is "a way of implementing Continuous Deployment for cloud native applications".
Instead of manually applying Kubernetes manifests or running
helm (install|upgrade), the state of the cluster (its
manifests) is stored in a Git repository. An agent running inside the cluster ensures (or at least attempts to) that
the state of the objects inside the Kubernetes cluster match those stored in Git.
Netsoc's GitOps live repository is located at github.com/netsoc/gitops and makes use of the Flux family of GitOps components. The Flux documentation is the best way to learn about the GitOps toolkit and how it works, but this diagram displays the key components (including a number of Kubernetes Custom Resources that Flux uses):
- Source resources (such as
GitRepository) manage the retrieval of Kubernetes manifests, making them available as archives within the cluster
Kustomizationresources define the configuration of a
Kustomizationthat should be applied to the cluster (which Source it should be read from, subdirectory, any methods for decrypting secrets etc.). Kustomize is used to provide flexibility in generating manifests, but without understanding how it works, essentially it's just a tree of Kubernetes YAMLs. The Kustomize Controller will retrieve sources from the Source controller and attempt to "reconcile" the cluster according to the
HelmReleaseresources essentially translate the parameters to a
helm upgradecommand into a CRD, except installation and upgrades happen automatically based on the state of the resource.
This repository is divided into a number of subdirectories based around 4 separate
flux: Contains core Flux-related resources, such as the Flux CRDs and actual
flux/flux-systemis generated by the
flux bootstrapcommand and is the only place where manifests are ever required to be manually applied to the cluster.
flux-system) is defined here at
flux/flux-system/gotk-sync.yaml. The other
Kustomizationsare defined in this directory too, along with any Helm repositories and image update automations.
Kustomizationcontains only CRDs to be installed into the cluster. Specific CRDs are separated into their own
Kustomizationso that reconciliation of other
Kustomizations(which will have an enforced dependency on
crds) will succeed, since they contain CRD-based manifests.
infrastructure: Key deployments (such as Ingress provider and authoritative DNS)
apps: All other applications