Introduction to Argo CD
As described in an earlier blog post (What is GitOps) GitOps is the concept of utilizing git and its built in features to maintain everything from virtual machines and network configurations to monitoring dashboards and documentation. This way we can store the state of our infrastructure declaratively in git.
One key requirement of GitOps is that the state stored in git is the truth, it is an exact representation of the desired cluster state. To be able to fulfil this requirement we need to sync the state between the source, git, and the target, our clusters.
Traditionally this has generally been done using CI/CD pipeline tools, like Jenkins or Terraform, to push changes to target clusters whenever something changes in the source. Even though this can be done following a declarative approach, the changes will only sync whenever the pipeline is triggered. An issue is that there is no easy way to know if the cluster state changes and diverges from the source state in git.
This is where ArgoCD comes in, it is a GitOps implementation, with the main purpose to sync state between git and Kubernetes in real time. It solves both problems mentioned above by being an running application inside the cluster. It keeps track of the state in both git and Kubernetes continuously and makes sure that they are in sync at all times.
Operator Pattern
ArgoCD is built following the Kubernetes Operator Pattern, which was built around the motivator to avoid repetitive human tasks that are both time consuming and prone to human errors. The main concept is that an operator is an application, or a client, that acts on changes of custom resources. A custom resource is defined by the controller and can describe more or less anything that needs to be controlled.
Application Resource
The main custom resource in ArgoCD is the Application resource, it defines an application or some other type of resource that should be installed in a Kubernetes cluster. After an Application resource is created, ArgoCD will make sure that the defined source is deployed properly.
Below is an example describing the main parts of an application resource:
- Metadata of the Application resource.
- Definition of the destination cluster and namespace. In this case it is the same cluster that ArgoCD is deployed in, but it could be any cluster that ArgoCD has network access too.
- Definition of the source where resources are fetched from. In this case it is a git repository containing a helm chart, but ArgoCD supports several different ways in which Kubernetes resources can be defined.
Apps of apps
An interesting bonus feature of ArgoCD being a Kubernetes operator is the Apps of apps. By abusing the fact that we can create Application that in itself creates several other applications, we can bootstrap groups of applications or even entire clusters by just deploying with source application.
This is a nice feature if we want to easily spin up a mirror cluster for testing or some other purpose in a reliable way.
Author:
Andreas Lundsten
Solution Architect
