ArgoCD: A Practical Guide to GitOps on Kubernetes

Key-Takeaways

ArgoCD (the DeFacto CD tool for Kubernetes) makes deployment releases smooth by using GIT as a single source of truth. You can define your app’s state in Git, and ArgoCD will keep the cluster in the desired state.
Unlike the traditional push-based approach, ArgoCD runs inside the cluster and pulls changes from the GIt, which ensures that API keys and secrets are not exposed, making it a safer and more reliable choice for big enterprises.
Big Enterprises like LoveHolidays and CVTE adopted ArgoCD to handle massive-scale deployments. LoviHoliday, for example, handles trillions of requests and 1500+ deployments in a month, all thanks to ArgoCD.
ArgoCD addresses core Continuous Delivery challenges such as configuration drift, automated deployment workflows, and multi-cluster application consistency. It ensures consistency across environments and lets you roll back to the previous version with just ONE Click, reducing error and stress.
This blog includes a hands-on demo that shows how easy it is to set up ArgoCD on a minikube cluster and watch it sync changes in real-time.

Introduction

Kubernetes has been around for over a decade, and its application has been rising ever since. Started in 2014 by Google, Kubernetes (K8s) is an open-source container-orchestration system that automates software deployment, scaling, and management.

Initially developed by Google, it was transferred to the Cloud-Native Computing Foundation (CNCF), which maintains and develops it with a community of over 80K+ contributors. It provides us with seamless deployments, but to ensure consistent and automated delivery of new code versions, from development to production, without manual intervention, we need Continuous Delivery (CD) in Kubernetes.

There are many CD tools for Kubernetes in the market, but the popular ones include ArgoCD, FluxCD, JenkinsX, and GitHub Actions. Among them, ArgoCD became a popular choice for big enterprises for its declarative and version control system. According to the official Docs:

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes.

Application definitions, configurations, and environments are declarative, and application deployment and lifecycle management are automated and easy to understand, which makes using ArgoCD the ideal choice for many companies.

How does ArgoCD work?

ArgoCD follows the GitOps pattern. It uses the Git repositories as the source of truth for defining the desired application state. It provides us with various options to describe our Kubernetes manifest:

Kustomize Applications
Helm Charts
Jsonnet Files
Plain, direct YAML/JSON manifest
Any Custom config management tool configured as a config management plugin

It automates an application’s desired state in the specified target environments. You can track your applications’ deployments with branches and tags, or be pinned to a specific version of manifests at a Git Commit.

ArgoCD is implemented as a Kubernetes Controller that continuously monitors running applications and compares the current state with the desired state (as specified in the Git Repository). The configuration in the Git repo is the single source of truth.

When the desired state differs from the current state, the application is OutOfSync. To this, ArgoCD reports & visualizes the differences while providing facilities to automatically or manually sync the live state back to the desired target state. Any modifications in the Git repo will change the desired state of the application.

Push V/S Pull Based CI/CD

Earlier CI/CD implementations relied on push-driven behaviour, which connects your cluster to your CI/CD platform and uses tools like Kubectl and HELM within your pipeline to apply Kubernetes changes.

ArgoCD is a pull-based CI/CD system. It runs inside your Kubernetes cluster and pulls sources from your repositories. Argo then applies the changes for you without a manually configured pipeline.

This model is more secure than push-based workflows. You don’t have to expose your cluster’s API server or store Kubernetes credentials in your CI/CD platform. Compromising a source repository only gives an attacker access to your code instead of the code and a route to your live deployments.

Architecture

Source: ArgoCD Official Docs

Components:

ArgoCD has three components: API Server, Repository Server, and Application Controller. Every one plays a crucial role; if any one fails, the application will fail. Let’s understand them in depth:

API Server: The API server is a gRPC/REST server that exposes the API consumed by the Web UI, CLI, and CI/CD system. It has the following duties:

Application Management and status reporting
Involving application operations (eg, sync, rollbacks)
Repo and Cluster management
Auth and its external identity provider
RBAC enforcement
Listener to Webhooks of git

Repository Server: An internal server maintains a local cache of the git repo holding the application manifest. Primary responsibilities include generating and returning Kubernetes manifests when provided the following inputs:

Repo URL
Revision (commit, tag, branch)
Application path
Template-specific settings: parameters, helm values.yaml

Application Controller: A Kubernetes Controller continuously monitors running applications and compares the current state with the desired state (as specified in the git repo). It detects the OutOfSync application state and optionally takes corrective measures. It is primarily responsible for invoking user-defined hooks for lifecycle events, including Pre-Sync, Sync, and Post-Sync.

Challenges with Continuous Delivery

Argo CD combats several Continuous Delivery Challenges by implementing a GitOps Approach for Deployments. It automates deployment by managing continuous drifts, simplifying operations, and ensuring more consistent and reliable releases. The following are some Key challenges solved by Argo CD:

Configuration Drift: Argo CD ensures that deployments reflect the desired state of the application defined in Git (the single source of truth) and prevent misconfiguration within the cluster.
Automation and Reliability: It automates deployments by eliminating manual steps and reducing errors.
Consistency and Reliability: Using Git as the Source Code It ensures consistent deployment across environments, improving reliability.
Multi-Cluster Management: It supports multi-cluster management by streamlining deployment across many Kubernetes clusters in distributed environments.
Simplified Operations: It simplifies operations by providing a user-friendly interface and automates tasks like rollbacks with just ONE Click.

ArgoCD Features

Automated deployment of applications to specified target environments
Support for multiple config management/templating tools (Kustomize, Helm, Jsonnet, plain-YAML)
Ability to manage and deploy to various clusters
Multi-tenancy and RBAC policies for authorization
Rollback/Roll-anywhere to any application configuration committed in the Git repository
Automated or manual syncing of applications to their desired state
Web UI that provides a real-time view of application activity
CLI for automation and CI integration, Webhook integration (GitHub, BitBucket, GitLab)
Access tokens for automation
Audit trails for application events and API calls
Prometheus metrics Parameter overrides for overriding helm parameters in Git

Case Studies: How do big enterprises like LoveHolidays, CVTE, and BabyLon leverage ArgoCD to enhance productivity?

ArgoCD was accepted to CNCF on March 26, 2020, at the Incubating maturity level and then moved to the Graduated maturity level on December 6, 2022. It has helped many companies, such as Love Holidays and CVTE, run workflows, manage clusters, and do GitOps correctly.

LoveHolidays is one of the fastest-growing online travel agencies in the UK and Ireland. It expanded to the German Market in 2023 to offer their customers unlimited choices with unmatched ease and unmissable value, providing the perfect holiday experience. Since their user base increased, they find improving overall observability and incident detection difficult.

To solve this, LoveHolidays adopted LinkerD as their Kubernetes service mesh along with ARGOCD for GitOps and Argo Rollouts for powering canary Deployments. By numbers, LoveHolidays handles Trillions of hotel and flight combinations per day, deploys over 1500+ production deployments per month, and runs around 5000 pods in production with around 300 Deployments / StatefulSets.

Recently, they migrated from Flux to Argo CD, and with Gitops-powered deployments, they deployed over 1500 times to production in a month.

CVTE, based in China, is an electronic company that embraced cloud native tech and has been running services on Kubernetes for years. Most of their applications run on bare metal and edge clusters in a private environment, making accessing these applications outside the cluster challenging.

To solve this, they used OpenELB, which exposed the load balancer services on bare metal using Layer 2 mode. They use ArgoCD to build automated pipelines and Nginx Ingress to deal with Layer 7 requests. In their domain, when they visit their ArogCD server, the system forwards the request to the router that broadcasts their request.

By using ARGOCD and openELB, the company has reduced the complexity of its infrastructure, enhanced its self-healing capabilities, and improved its monitoring capabilities.

BabyLon, a UK startup launched in 2013, has helped to revolutionize medical services and reduce the waiting time for doctors’ appointments from weeks or two to mere minutes or hours. Their products leverage machine learning and artificial intelligence, and there was insufficient power in-house to run the services.

To solve that issue, they migrated their user-facing application to a Kubernetes platform in 2018 using Kubeflow, and the change has been incredible! Teams can get access instantaneously instead of waiting hours or days to compute. Clinical Validation, which used to take 10 hours, is now done in under 20 minutes. Using ArgoCD for GitOps, the team can scale the process massively.

Best Practices for Using Argo CD

Here are some of the best practices to keep in mind when working with Argo CD:

Use ApplicationSets for Dynamic app Management—Leverage ApplicationSets to automate the deployment of similar apps (e.g., per tenant or cluster) from templates, reducing boilerplate and manual interventions.
Pin Argo CD versions and CRDs—Avoid auto-upgrading Argo CD or its Custom resource definitions; pin versions explicitly to avoid breaking changes or unexpected behaviour in the app.
Apply resource exclusions and ignore differences – Configure resource exclusions or diff settings (e.g., ignore status fields) to prevent false-positive drift detections.
Tag and label applications for automation and auditing—Use consistent metadata on your ArgoCD apps to enable automated filtering, reporting, or lifecycle management.
Run ArgoCD in a dedicated namespace or cluster – Isolate Argo CD to a specific namespace or cluster to simplify access control, avoid conflicts, and improve operational clarity.

A Practical Demonstration

After learning about Argo CD and its applications, let’s have a hands-on demo and see how it works. We will install an Argo CD in a minikube cluster and see the magic. Follow the steps:

If you don’t have minikube installed, install it from its official website and run the following command:

minikube start

Install ArgoCD using the following command:

kubectl create namespace argocd

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

Get the initial password using the following command:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}’ | base64 -d

Copy the Output and save it for the next step.

Expose the ArgoCD API server using port forwarding:

kubectl port-forward svc/argocd-server -n argocd 8081:443

Now go to your localhost:8081, you will be provided with a warning, accept the risk, and continue.

In the username, enter ‘admin’; the password is the saved output from the previous step.

After providing the credentials, you will be presented with the ArgoCD dashboard. Click on Create Application and provide the following configuration:

Application Name: argo-cd-demo
Project Name: default
Sync Policy: Automatic

Under source, provide the following configuration

The repository URL is https://github.com/sitepoint-editors/argocd-demo.
Revision: Head
Path: manifests

Under Destination, provide the following configuration

Cluster URL: https://kubernetes.default.svc
Namespace: default

And hit Create. Wait for 2-3 minutes so that the pods run healthily.

Now in the terminal, run the following command to change the number of replicas of nginx-deployment:

kubectl scale --replicas=2 deployment/nginx-deployment

You will notice that the number of pods will increase to 2, and the application’s status will be OutOfSync. However, once you click Sync, it will automatically revert to the previous version, as in our git repo, where we specified three replicas. You can enable self-healing to do this task automatically.

Since our Sync Policy is set to Automatic, let’s make some changes in the git repo and see if they reflect changes in the application. In the deploy.yml, make the replicas eight instead of 3 and commit the change. After a few seconds, you will see that ArgoCD will pull and reflect the changes in our application.