What is Argo CD? A GitOps Tool for Kubernetes

A Decisive Victory for Progressive Policies

Share this article:

Introduction

ArgoCD is a Continuous Delivery (CD) tool that has gained popularity in DevOps for performing application delivery onto Kubernetes. It relies on a deployment method known as GitOps. GitOps is a mechanism that can pull the latest code and application configuration from the last known Git commit version and deploy it directly into Kubernetes resources. The wide adoption and popularity are because ArgoCD helps developers manage infrastructure and application lifecycle in one platform.

To understand ArgoCD in-depth, we must first understand how Continuous Delivery works for most application teams and how it differs from GitOps.

What is Continuous Delivery?

Continuous Delivery (CD) is a software delivery process/ framework that enables developers to continuously push their code changes into the production servers without accessing the infrastructure through a push-based pipeline. This process reduces the time a code takes to reach its end users and improves release velocity. It is a repeatable process that enables scaling your application to address the growing demands of end users.

How does Continuous delivery work?

Continuous delivery is a part of the application delivery lifecycle that deploys the application post-build into a resource. In this context, our infrastructure will be Kubernetes without the use of ArgoCD. Alternatively, if we use Jenkins, the process will be as follows.

To release a feature upgrade or a bug fix to the end users, a pre-configured Continuous Integration (CI) pipeline will build a docker image as per the docker file.
Then, a script will push it to the configured docker repository.
To move this image into Kubernetes, the “deployment.YAML” file will be updated with the new image tag and name for fetching the latest image from the Docker registry.

Challenges with CD into Kubernetes?

Before the rise of Kubernetes, CD most applications teams enabled CD with tools like Jenkins and Spinnaker. The architecture of Kubernetes is complex, and these tools could not efficiently deploy into Kubernetes and deploy without errors due to the complexity of Kubernetes architecture. These issues made using tools like Jenkins challenging to work with Kubernetes.

Challenges with traditional CD while deploying into Kubernetes:

Tools installation and management: One needs to install tools like “Kubectl” and “Helm.” These add to the operational activities.
Accessing Kubernetes Clusters: One must configure access management in the CD tool to enable authorization to Kubernetes clusters and execute changes. If Kubernetes clusters run on a cloud provider, those credentials must be configured and shared outside the cluster.
Security & Operational Challenges: The configurations will rise in proportion with the increase in clusters which increases operational overhead. While increased operational overheads may not be challenging, it risks the system’s security when cluster credentials get shared with external services and tools.
Issues while scaling infrastructure: ‍Each team needs its own set of Kubernetes cluster credentials so that the users can access that specific application resources in a cluster. While operating Kubernetes at scale with a CD tool like Jenkins deploying into multiple clusters needs reconfiguration again for each new cluster.
Lack of Visibility: ‍When a CD tool deploys an application into Kubernetes without GitOps or a Kubernetes-native CICD pipeline, the tool loses visibility into the deployment post applying the configuration to the deployment.YAML files. Once the kubectl command has been executed team must wait until someone reports an incident. Also, the status of execution remains unclear.

The continuous delivery into Kubenbrtes can be made efficient with Argo CD, which works on the principle of GitOps. Before understanding GitOps, let us understand Push vs. Pull based CI/CD in the upcoming section on GitOps.

What is GitOps and how is it different from traditional CD?

Traditional CD and GitOps differ on the core principles of push and pull-based deployments. Most CI/CD processes work on a push mechanism, which means things move to their respective destination at the trigger of an event. For example, when a developer has finished writing his code, he must execute a set of commands to move his code into the server for deployment. In a Kubernetes environment, the developer has to configure the clusters using tools like Kubectl and Helm in the pipeline to apply changes.

Argo is a CD tool that uses a pull-based mechanism. A pull-based CD mechanism means the destination triggers an event to pull the data from the source(git) to deploy at the destination. Argo CD, which resided inside the cluster for reasons explained later on the blog, pulls the most recent verified version of code into the cluster for deployment. There are a lot of benefits to this model, like improved security and ease of use.

This pull-based mechanism is called GitOps, where source code management systems like Git are treated as the only source of truth for application and configuration data.

How does Argo CD work?

Argo CD works in a reversed flow mechanism as compared to push-style deployments. The new mechanism enables ArgoCD to run from inside a Kubernetes cluster. Kubernetes faces challenges with the traditional CD mechanism because CI/CD tools, like Jenkins, sit outside the cluster, whereas Argo CD sits inside the cluster. While inside the cluster, Argo CD pulls changes from git and applies them to the residing cluster. Instead of pushing changes like older generation tools by being inside the cluster, ArgoCD prevents sensitive information from being exposed to other tools outside the Kubernetes cluster and environment. ArgoCD can be combined with a CI tool such as Jenkins.

Argo CD can be set up in two simple steps.

Deploy the ArgoCD agent to the cluster.
Configure Argo CD to track a Git repository for changes.

When Agro CD monitors change, it automatically applies them to the Kubernetes cluster. When developers commit the new code updates to the Git repository, automated CI pipelines will auto-start the build process and build the container image. Then as per the configurations, the CI pipeline will push and update the Kubernetes manifest files. The pipelines will update the new image version name and details on the `deployment.yaml` file. Argo CD can track this new update, pull the image, and deploy it onto the target cluster.

When the Kubernetes cluster is ready, Argo CD sends a report about the status of the application and that the synchronization is complete and correct. ArgoCD also works in the other direction, monitoring changes in the Kubernetes cluster and discarding them if they don’t match the current configuration in Git.

Best Practices to follow while using Argo CD

Separate git repositories for application source code and apps configuration
Separate git repo for system configurations.

Why separate repositories?

- K8s configurations can be defined as code in the git repository
- Config files are not applied for individual laptops of developers / DevOps
- Updates are traceable as tags, branches, or pinned specific manifest versions at Git commits.
- Same and only interface for updating the cluster.
- Git as the single source of truth
- Avoid untrackable kubectl command applications
- Version-controlled changes with audit trail
- Single sign-on (SSO) with providers such as GitLab, GitHub, Microsoft, OAuth2, OIDC, LinkedIn, LDAP, and SAML 2.0
- Support for webhooks triggering actions in GitLab, GitHub, and BitBucket.

Easy rollbacks

- K8s configurations can be defined as code in the git repository
- Config files are not applied for individual laptops of developers / DevOps
- Updates are traceable as tags, branches, or pinned specific manifest versions at Git commits.
- Same and only interface for updating the cluster.
- Git as the single source of truth
- Avoid untrackable kubectl command applications
- Version-controlled changes with audit trail
- Single sign-on (SSO) with providers such as GitLab, GitHub, Microsoft, OAuth2, OIDC, LinkedIn, LDAP, and SAML 2.0
- Support for webhooks triggering actions in GitLab, GitHub, and BitBucket.

Avoid snowflake clusters with Argo CD

Argo CD is watching the git repository and changes in the cluster. Anytime a change happens in the git repository or the cluster, Argo CD will compare the two states to check for any misconfigurations or differences. If they don’t match the desired state defined in the git repo with the actual state of the cluster, Argo CD will become active and quickly sync the cluster as described in the cluster. So, in that case, if someone goes and makes manual changes in the cluster, Argo CD will detect it and sync to the desired state. It overrides the manual changes.

The automatic override helps the system stay stable and guarantees that the git repository is the only source of truth at any point in time. It also provides full transparency of the cluster and lets it become a snowflake cluster.

Recreate clusters from scratch

When a cluster completely crashes, and one has to build it from scratch, Argo CD can be pointed to the git repository, where the complete cluster configuration is defined. It will recreate the same state as the previous one. This is a fully autonomous process where developers and DevOps do not have to worry about disaster recovery post-clean-up processes. This is possible because Argo CD accepts the cluster configuration as code in a declarative way.

What does Argo CD provide over standard GitOps benefits?

Better team collaboration with easy access control

Production clusters must have limited access, and only some of your team members should be allowed access. To configure different access rules to these clusters, Argo CD can enable approvals for pull requests for authorized developers and engineers. This helps in managing the cluster permissions. No need to create cluster role and user account on Kubernetes.

Better team collaboration with easy access control

Non-human users like CICD tools or other peripheral tools in the DevOps ecosystem outside the cluster can be configured in Argo CD, which resides inside the cluster. This architecture of Argo CD ensures that those credentials remain inside the cluster making the system robust and secure.

Argo CD architecture overview

Argo CD is a Kubernetes native CD tool that supports and reads various Kubenrtes manifest files such as YAML, Ksonnet, Jsonnet, Helm charts, and Kustomize. It can follow updates to branches, tags, or pinned to a specific version of manifests at a Git commit.

Argo CD control plane consists of three main components:

Application Controller
API Server
Repository Service

Repository Service

Accessing the Git repository is always time-consuming for Argo CD; accessing the git Repo every time will constitute a pull request. Hence, this internal Repository Service makes a local cache of the application manifest and Git repositories on the Kubernetes cluster a replica of the git repository. It is responsible for generating and returning Kubenrtees manifests on input data like repository URL, Git revisions( branch, tags), application path, and template-specific settings; the server generates Kubernetes manifests.

Application Controller

Argo CD can detect changes in Git and sync with the repo due to the Application Controller component. This feature enables syncing out-of-date or modified destination configurations to the last approved git version. The application controller syncs between the local cache created by the Repo service and the git repository because it is a less resource-intensive process. The application controller can also be configured to accept direct changes in code and configuration at the destination without reverting back to the last known configuration on Git. This authority must be granted only to a selected team resource. When this direct change is made it notifies the DevOps and developers about the difference in the configuration to update the Git repositories.

API Server

The API server, like a Kubernetes API server, is a service to expose the components of Kubernetes and ArgoCD to interfaces like a CLI or web GUI or other third-party tools. The APIs are primarily used to carry out functionalities like: