GitOps - ArgoCD

1. What is GitOps?

GitOps is a modern approach to managing and deploying infrastructure and applications using Git as the single source of truth.
Instead of manually applying changes to servers or clusters, you declare the desired system state in Git, and an automated tool keeps your running systems in sync with that state.

Core Principles :

• Declarative configuration: All infrastructure and application configs are stored as code in Git repositories (e.g., Kubernetes manifests, Helm charts, Terraform modules).
• Version-controlled: Every change is done through Git commits, pull requests, and code reviews—giving you full history, auditability, and rollback capability.
• Automated reconciliation: Specialized GitOps controllers (like Argo CD or Flux) continuously watch the Git repo and the live environment. If something drifts, they automatically sync it back to match the Git state. The GitOps operator ArgoCD also makes sure that the entire system is self-healing to reduce the risk of human errors. The operator continuously loops through three steps, observe, diff, and act. In the observe step, it checks the Git repository for any changes in the desired state. In the diff step, it compares the resources received from the previous step the observe step to the actual state of the cluster ( It performs a diff (comparison) between the desired state (Git) and the actual state (cluster), Any mismatch is called “drift” ). And in the Act step, it uses a reconciliation function and tries to match the actual state to the desired state ( If a drift is found, the operator runs its reconciliation logic, It applies the necessary changes to bring the cluster back to match Git, This ensures the system self-heals from manual or accidental changes ).

Desired State: Git , Actual State: Kubernetes Cluster

• Continuous deployment: Merging to the main branch becomes the trigger for deployments, replacing manual kubectl apply or ad-hoc scripts.

Benefits :

• Full audit trail of all infrastructure and app changes.
• Rollback is as simple as reverting a Git commit.
• Strong security (no direct access to production clusters needed - pull the desired state from Git and apply it in one or more environments or clusters)
• Enables collaboration and consistent workflows across teams.

Push vs Pull based Deployments :

1. Push-based Deployment :
How it works :

• The CI/CD system (like Jenkins) builds the code, creates container images, pushes them to a registry, and then directly applies manifests to the Kubernetes cluster using kubectl apply.
• The CI/CD system has Read-Write (RW) access to the cluster.

Key points from the image :

• ✅ Easy to deploy Helm charts.
• ✅ Easy to inject container version updates via the build pipeline.
• ✅ Simpler secret management from inside the pipeline.
• ❌ Cluster config is embedded in the CI system (tightly coupled).
• ❌ CI system holds RW access to the cluster (security risk).
• ❌ Deployment approach is tied to the CD system (less flexible).

2. Pull-based Deployment (GitOps) :
How it works :

• The CI system builds and pushes images to a registry.
• The desired manifests are committed to a Git repository.
• A GitOps operator (like Argo CD) inside the cluster pulls the manifests from Git and syncs them to the cluster, reconciling continuously.

Key points from the image :

• ✅ No external user/client can modify the cluster (only GitOps operator can).
• ✅ Can scan container registries for new versions.
• ✅ Secrets can be managed via Git repo + Vault.
• ✅ Not coupled to the CD pipeline — independent.
• ✅ Supports multi-tenant setups.
• ❌ Managing secrets for Helm deployments is harder.
• ❌ Generic secret management is more complex.

---

2. ArgoCD Basics

What is Argo CD?
Argo CD (Argo Continuous Delivery) is a GitOps tool for Kubernetes that:

• Runs inside your cluster as a controller.
• Continuously monitors a Git repository that stores your Kubernetes manifests (YAML, Helm, Kustomize, etc.).
• Automatically applies and syncs those manifests to the cluster.
• Provides a web UI, CLI, and API to visualize and manage application deployments.

Installation :

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
kubectl create namespace argocd
helm install argocd argo/argo-cd -n argocd

# Optional: Specify custom values
helm show values argo/argo-cd > values.yaml
helm install argocd argo/argo-cd -n argocd -f values.yaml

kubectl port-forward svc/argocd-server --address=0.0.0.0 -n argocd 8080:443
# Get the Initial Admin Password
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d; echo

Why use Argo CD?
Argo CD solves common deployment and operations problems by embracing GitOps principles:

Problem	How Argo CD Helps
Manual kubectl apply steps	Automates syncing from Git
Configuration drift (manual changes)	Detects drift and self-heals by reverting to Git
Hard to audit who changed what	Uses Git history as the single source of truth
CI pipelines need cluster credentials	Removes this risk — cluster pulls from Git
Slow feedback on deployment status	Real-time UI with health, sync status, and diffs

ArgoCD Concepts & Terminology :

Term	Description
Application	A group of Kubernetes resources as defined by a manifest. An application is a Custom Resource Definition, which represents a deployed application instance in a cluster. An application in ArgoCD is defined by two key pieces of information, the source Git repo where is the desired state of a kubernetes manifest and the destination for your Kubernetes resources where the resources should be deployed in a kubernetes.
Application source type	The tool used to build the application. E.g., Helm, Kustomize, or Ksonnet.
Project	Provides a logical grouping of applications, useful when Argo CD is used by multiple teams.
Target state	The desired state of an application, as represented by files in a Git repository.
Live state	The live state of that application. What pods, configmaps, secrets, etc. are created/deployed in a Kubernetes cluster.
Sync status	Whether or not the live state matches the target state. Is the deployed application the same as Git says it should be?
Sync	The process of making an application move to its target state (e.g., by applying changes to a Kubernetes cluster).
Sync operation status	Whether or not a sync succeeded.
Refresh	Compare the latest code in Git with the live state to figure out what is different.
Health	The health of the application — is it running correctly? Can it serve requests?

What is an Argo CD Application?
An Application is the core deployment unit in Argo CD.
It represents a set of Kubernetes resources defined in a Git repository and tells Argo CD:

• Where to get the manifests (Git repo + path + branch)
• Where to deploy them (cluster + namespace)
• How to manage them (sync policies like auto-sync, self-heal)

Creating an Application :
1.Using CLI

argocd app create color-app \
  --repo https://github.com/sid/app-1.git \
  --path team-a/color-app \
  --dest-namespace color \
  --dest-server https://kubernetes.default.svc

Explanation:
--repo: Git repository URL containing the manifests.
--path: Path inside the repo where the manifests are stored.
--dest-namespace: Target namespace in the cluster.
--dest-server: Target Kubernetes API server (usually the same cluster).

2.Using a YAML manifest (color-app.yaml)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: color-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/sid/app-1.git
    targetRevision: HEAD
    path: team-a/color
  destination:
    server: https://kubernetes.default.svc
    namespace: color
  syncPolicy:
    automated:
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Key fields:

• metadata.name: Application name shown in Argo CD UI.
• spec.source: Where manifests come from (repo, branch, path).
• spec.destination: Which cluster and namespace to deploy to.
• syncPolicy.automated: Enables auto-sync and self-healing.
• syncOptions.CreateNamespace=true: Automatically create the namespace if it doesn’t exist.

3.using UI

• Click “+ NEW APP”
• Application Name: A unique name (e.g. color-app)
• Project: Select default (unless you created custom projects)

• Sync Policy:

  • Choose Manual or Automatic
  • Enable Self Heal and Prune if you want Argo CD to auto-fix drift and delete removed resources

• Specify the Source (Git Repo)

  • Repository URL or Added it using settings => Repositories => Connect Repo => Via HTTP/HTTPS => Type: git => Name: Any Name => Project: default => Repository URL then check the Connection Status
  • Revision: HEAD (or branch/tag name like main)
  • Path: The path in the repo (./solar-system)

• Specify the Destination (Cluster + Namespace)

  • Cluster URL:
    • Use https://kubernetes.default.svc for the same cluster Argo CD is running in
  • Namespace: solar-system
    • Check “Create Namespace” if it does not exist

• Review and Create

  • Click “Create”

• Sync the Application

  • After creation, go to the app page
  • Click “Sync” (if using manual sync)
  • Argo CD will pull the manifests and deploy them to your cluster

ArgoCD Architecture :
Argo CD is deployed as a set of Kubernetes controllers and services inside your cluster.
It continuously pulls manifests from Git and applies them to the cluster, keeping everything in sync.

Component	Role
API Server	Provides the UI, CLI (argocd), and REST API. Handles RBAC and authentication.
Repository Server (Repo Server)	Clones Git repositories and renders manifests (Helm, Kustomize, etc.).
Application Controller	Core GitOps reconciliation engine: compares desired vs live state and performs sync actions.
Dex (Optional)	Identity provider for SSO authentication (OIDC, GitHub, LDAP, etc.).
Redis (Optional)	Used as a cache to speed up repository and application state operations.