Understanding Argo CD: The Introductory Guide

Argo CD is a GitOps-based continuous deployment tool for Kubernetes that ensures your cluster stays in sync with the desired state defined in Git. It follows a pull-based model, automatically detecting and applying changes from your Git repo to the cluster. As a CNCF graduate project, Argo CD is trusted for enabling consistent, automated deployments.

Devtron is an Application Lifecycle Management platform built on Argo CD, with integrated CI/CD, security, environment management, and much more.

Why Argo CD

Before we explore why we need Argo CD, let’s examine the challenges associated with traditional CI/CD tools like Jenkins and Spinnaker. These traditional tools rely on a push-driven methodology, which requires you to connect your cluster to a CI/CD tool, such as Jenkins, and then use utilities like Helm and Kubectl to apply Kubernetes changes manually or automate through a CD script. 

Some of the key challenges with traditional tools are:

1. Direct Cluster Access Required

This is a security risk because traditional tools need credentials to access Kubernetes, making them vulnerable to security breaches. If Jenkins is compromised, then any attacker could gain full control over Kubernetes deployments.

2. Lack of Visibility & Auditability

Once a deployment is pushed, there’s no continuous monitoring of the actual cluster state. If someone manually changes resources, traditional tools won’t detect or correct them. Tracking who changed what requires external logging and auditing tools.

3. Complex Rollbacks

If a deployment fails, rolling back is not automated. You often need to revert the changes manually, leading to long recovery times.

4. Push-Based Deployments Are Not Scalable

Push-based deployments don’t scale well in multi-cluster environments. Managing 100s of applications across multiple clusters requires multiple Jenkins agents or complex automation.

5. No Built-In Multi-Cluster Support

If deploying to multiple Kubernetes clusters, each cluster must be configured manually. There is no centralized way to manage multiple clusters with different configurations. Maintaining separate pipelines for each cluster adds operational overhead.

Argo CD adopts the GitOps approach to overcome these challenges by treating Git as the single source of truth for Kubernetes deployments. Instead of relying on traditional CD tools like Jenkins to push updates to the cluster, Argo CD continuously pulls changes from the Git repository and ensures the cluster state always matches the desired configuration. This pull-based model enhances security, consistency, and automation, reducing manual intervention and deployment risks.

How Argo CD Works

Argo CD has several components working together to automate Kubernetes application deployments. It ensures that the desired state of the applications, defined in the git repository, is always in sync with the actual state of the application deployed in the Kubernetes cluster. 

Let’s discuss how the different components of Argo CD work together to deploy the applications to the Kubernetes cluster.

Here’s an overview of Argo CD’s external and core components:

External Components

These are the components that interact with Argo CD externally:

1. Git Repository

• Stores the desired state of applications as Kubernetes manifests (YAML, Helm, Kustomize, etc.).
• Argo CD pulls configurations from here to ensure the cluster is in sync.

2. Argo CD UI

• A web interface for users to monitor and manage applications.
• Provides visibility into sync status, application health, and logs.

3. Argo CD CLI

• A command-line interface (argocd) to interact with Argo CD.
• Allows users to sync applications, manage clusters, and configure Argo CD through the CLI.

Core Components

These components reside inside the Kubernetes cluster and control deployment management:

1. Repo Server

• Pulls application configurations from the Git repository.
• Supports Helm, Kustomize, and raw Kubernetes manifests.
• Sends the fetched manifests to the Application Controller.

2. API Server

• Provides an API that allows users to interact with Argo CD via UI, CLI, or automation tools.
• Processes requests and forwards them to the Application Controller.

3. Application Controller

• The brain of Argo CD that ensures Kubernetes stays in sync with Git.
• Compares the desired state (Git) with the actual state (Kubernetes cluster).
• If there’s a drift, it applies changes to restore the desired state.

For more information, you can check out our documentation on what is Argo CD.

Argo CD Installation 

Argo CD offers multiple installation methods to suit different deployment needs. It can be installed using Kubernetes manifests, Helm Installation, Kustomize, or a multi-tenant setup, allowing flexibility based on your infrastructure and organizational requirements.

Kubernetes Manifests

The following kubectl commands will create the namespace and deploy the manifest to install Argo CD:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Change the argocd-server service type to LoadBalancer or NodePort to expose it externally:

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

Now, you can access the Argo CD dashboard through the external IP assigned to the service.

Creating & Deploying Apps with Argo CD

Now that we have installed Argo CD, let's create and deploy a sample application through the Argo CD UI to demonstrate its functionality. 

Step 1: Create App

After logging in to the Argo CD UI, click +NEW APP as shown below:

Step 2: Fill the App Details

Name your application guestbook, assign it to the default project, and set the sync policy to Automatic. 

Step 3: Add the source repository 

Connect the https://github.com/argoproj/argocd-example-apps.git repo to Argo CD by setting the:

• Repository URL to the github repo url
• Leave Revision as HEAD
• Set the Path to helm-guestbook:

Step 4: Set the Cluster URL

Set the cluster URL to https://kubernetes.default.svc (or in-cluster for cluster name) and namespace to default:

Step 5: Create the App

After filling out the information above, click Create at the top of the UI to create the guestbook application:

Once the application is successfully deployed, you can view and manage it from the Applications page in the Argo CD dashboard.

You can see more details by clicking on the guestbook application:

Key Features Of Argo CD

The key features of Argo CD that make it a go-to tool for continuous deployment are:

1. Automatic Deployment: Argo CD automatically deploys applications to the cluster by watching the changes in the git repository.
2. Multi-cluster Deployment: Argo CD can manage and deploy applications in multiple clusters. 
3. RBAC and SSO: It provides robust security features, including Role-Based Access Control (RBAC) for fine-grained permission management and Single Sign-On (SSO) for seamless and secure authentication.
4. Deployment Strategies: For advanced deployment strategies like Canary and Blue-Green, you can integrate Argo CD with tools such as Argo Rollouts or Spinnaker.
5. Webhook Integration: Facilitates integration with Git providers (e.g., GitHub, GitLab) to automate deployment workflows, synchronize application states, and enhance pipeline orchestration.

Challenges with Argo CD

Throughout this blog, we discussed what Argo CD is, how to deploy applications through Argo CD, and its key features. Now, let's dive into some of the critical challenges encountered when deploying and managing applications with Argo CD.

1. Complexity in Multi-cluster Management

While deploying and managing applications in multiple clusters through Argo CD is a key feature, it can also turn out to be one of its complexities since each Kubernetes cluster needs its own Argo CD instance, which results in increased operational overhead, consistency issues across deployments, and difficulties in maintaining visibility and control.

For more information, read Top Challenges with ArgoCD

2. Lack of Automated Rollbacks

Automated rollbacks or SLO-based rollbacks allow us to quickly revert to the previous stable versions when any deployments break. Argo CD doesn’t have any native support for these SLO-based rollbacks. We need to configure it manually through written scripts or use some external tools from the ecosystem.

3. Application Promotions Across Environments

Application promotion is the part of the Software Delivery lifecycle where an application goes through the stages of development, testing, and production phases before deployment. Argo CD again lacks built-in application promotion functionality between various environments. Without this functionality, teams need to manually promote the application across each environment.  

Check out Operational Challenges with ArgoCD to learn more about this.

4. Increased Overhead due to Tool Sprawl

Argo CD is generally a tool that syncs Git repositories to Kubernetes but doesn’t handle security, monitoring, or logging. For full DevOps best practices, additional tools are needed, leading to increased complexity and tool sprawl.

Read High Operational Overhead Due to Tooling Fragmentation

Conclusion

The Key Takeaways are:

• Argo CD simplifies deployments with a GitOps-driven approach.
• It ensures apps stay in sync with their desired state.
• It lacks built-in CI, environment promotion, and security scanning.
• Advanced RBAC and full DevOps workflows need extra tools.
• Devtron builds on Argo CD to offer a complete deployment solution.

FAQ

Ayaan Bordoloi

Ayaan is a DevOps Evangelist at Devtron, specializing in Kubernetes, Docker, CI/CD, and cloud-native tech. He shares insights through blogs, making complex concepts accessible to all.