What Is Argo CD? The GitOps Tool for Kubernetes

gowebing

Argo CD 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 Argo CD helps developers manage infrastructure and applications lifecycle in one platform.

To understand Argo CD 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 Argo CD. Alternatively, if we use Jenkins, the process will be as follows:

  1. 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.Ops
  2. Then, a script will push it to the configured Docker repository.
  3. 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 and Operational Challenge

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 CI/CD 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 Kubernetes 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 the source code management systems like Git are treated as the only source of truth for application and configuration data. 

How is GitOps different from CD in Kubernetes

How Does Argo CD Work?

Argo CD works in a reversed flow mechanism as compared to push-style deployments. The new mechanism enables Argo CD 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, Argo CD prevents sensitive information from being exposed to other tools outside the Kubernetes cluster and environment. 

Argo CD can be set up in two simple steps:

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

When Argo 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. Argo CD 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.

How does Argo CD work?

Best Practices To Follow While Using Argo CD

  1. Separate Git repositories for application source code and app configuration
  2. Separate Git repo for system configurations

Why Separate Repositories?

The main reason for having separate repositories for application source code and app configurations is because app config code is not only present in the deployment file but also in the configmaps, secrets, storage, svc, etc. Kubernetes uses. These files change independently from the source code. 

When a Developer or DevOps wants to change a service.yaml file, which is an application configuration and not a part of the software code, he has to run the whole CI pipeline to sync those changes into production. The CI pipeline will run only when a code change is updated. Clubbing the app configurations and software code together makes the setup complex and inefficient. 

So as soon as DevOps changes the config on the git repository, Argo CD will become aware of the changes and update the destination cluster as it constantly monitors the repo as soon as config files change in the Git repository.

Benefits of Using Argo CD

Easy Rollbacks

If a new code commit is pushed into the Git repository and the changes are applied to the cluster with Argo CD auto sync, the cluster fails. DevOps can revert to the previous working state from the list of the last known best repository versions, just like a Windows restore point. Also, one need not process the laborious process of manually riveting every cluster and doing a clean-up, as Argo CD will do that all by itself.

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 a cluster role and user account on Kubernetes.

Non-human users like CI/CD 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 Kubernetes 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

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 Argo CD to interfaces like a CLI or web GUI or other third-party tools. The APIs are primarily used to carry out functionalities like application deployment and management, executing rollback of any user-defined actions, managing cluster credentials stored in K8s secrets, and enforcing RBAC Git webhooks. 

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 Kubernetes manifests on input data like repository URL, Git revisions (i.e., branch, tags), application path, and template-specific settings; the server generates Kubernetes manifests.

 

 

 

 

Top