Nothing but the Truth

Argo CD Architecture

To leverage the capabilities of Argo CD fully, it's essential to understand its architecture [3]. Argo CD is implemented as a Kubernetes controller. In the Kubernetes ecosystem, a controller is a control loop that watches the shared state of the cluster through the API server and makes changes in an attempt to move the current state toward the desired state.

Argo CD continuously monitors running applications and compares the current, live state against the desired, target state (as specified in the Git repo). A deployed application whose live state deviates from the target state is considered OutOfSync. Argo CD reports and visualizes the differences, while providing facilities to sync the live state automatically or manually back to the desired target state.

Argo CD comprises several components, each serving a specific purpose in the system. The key component is Argo CD API server, which exposes the Argo CD API, allowing users to interact with Argo CD via argocd on the CLI, the Argo CD user interface (UI), or any other program that can communicate with the API server.

The next component is the repository server, a stateless API used by the application controller to retrieve repository and Helm chart details. The Argo CD application controller is a Kubernetes controller that continuously monitors applications and attempts to maintain the desired state. Argo CD Redis is a Redis server used for caching Git repository data. Finally, Argo CD Dex is an OpenID Connect identity hub. Dex can be used to enable a login through a third-party single sign-on (SSO) provider.

Automated Deployments

One of the core features of Argo CD is automated deployment. As previously mentioned, Argo CD continuously monitors your Git repository for changes and automatically applies any updates to your Kubernetes cluster, which ensures that your cluster's state always matches the desired state defined in your Git repository.

For instance, if you update the number of replicas in a Deployment (Listing 4) and push that change to your Git repository, Argo CD automatically updates the deployment in your Kubernetes cluster to match the desired state.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5  # increased from 3 to 5
  ...

Choose Your Way

Argo CD supports a variety of configuration management and templating tools, including Kustomize, Helm, Jsonnet, and plain YAML. Therefore, you can define your applications in the way that best suits your needs and workflows. For example, if you use Helm, you can define a Helm chart in your Git repository and Argo CD will use Helm to deploy your application:

argocd app create my-app --repo https://github.com/my-org/my-repo.git --path </path/to/helm/chart> --dest-namespace default --dest-server https://kubernetes.default.svc --sync-policy automated --helm-set image.tag=v1.0.0

Be sure to replace </path/to/helm/chart> with the path to the Helm chart in your Git repository. The --helm-set argument sets a Helm value that overrides a value in the Helm chart.

Kustomize is a standalone tool to customize Kubernetes objects through the so-called kustomization file. Argo CD supports kustomize and can apply Kustomize overlays as part of a sync operation. To use Argo CD with Kustomize, you need to define a Kustomize overlay in your Git repository. Then, you can create an Argo CD application that references the Kustomize overlay:

argocd app create my-app --repo https://github.com/my-org/my-repo.git --path /path/to/kustomize/overlay --dest-namespace default --dest-server https://kubernetes.default.svc --kustomize-image my-image:v1.0.0

The --path argument points to the location of the Kustomize overlay in the Git repository, and the --kustomize-image argument sets a Kustomize image tag that overrides an image tag in the Kustomize overlay.