Lab — set up ArgoCD on EKS and deploy app via GitOps repo — CI/CD, GitOps, DevSecOps & Observability

What You'll Build

In this lab you will install ArgoCD on a live EKS cluster using Helm, structure a GitOps repository with a base Kustomize configuration and a production overlay, create an ArgoCD Application manifest that connects the repository to the cluster, and verify the full GitOps workflow. You will demonstrate self-healing by manually scaling a Deployment and observing ArgoCD revert it to the Git-declared value. You will then perform a real GitOps deployment by updating the image tag in Git and watching ArgoCD propagate the change to the cluster.

By the end of the lab, the cluster will be fully managed by the Git repository: any change to the manifests is automatically applied to the cluster within minutes, any manual kubectl change is automatically reverted, and every change is traceable to a Git commit. You will also verify that git revert is a complete rollback mechanism requiring no kubectl knowledge.

Analogy🏏Cricket

Think of it like cricket: Picture setting up a remote ground management system for a cricket ground in a new city. First, the infrastructure must be installed: the pitch sensors, the scoreboard network, and the broadcast uplink—equivalent to installing ArgoCD on the EKS cluster. Then, the venue configuration must be committed to the central venue management database: the pitch dimensions, the lighting schedule, the boundary positions—equivalent to committing the Kubernetes manifests to the GitOps repository. Then, the venue must be registered with the central management system, which then automatically enforces the declared configuration at the ground—equivalent to creating the ArgoCD Application that connects the repository to the cluster. When a ground manager moves a boundary rope by hand, the sensors detect the drift and alert the management system to restore the declared position—equivalent to ArgoCD detecting and reverting the manual replica scale. This reveals why the lab sequence matters: you cannot verify GitOps until all three components—operator, repository, and Application—are connected and working together.

Prerequisites

An EKS cluster running in AWS with at least three nodes (t3.medium or larger) and kubectl configured with cluster-admin permissions via aws eks update-kubeconfig.
Helm 3.x and the ArgoCD CLI installed locally: brew install argocd on macOS or the Linux binary from the GitHub releases page.
A GitHub repository named india-squad-gitops where you have write access, since ArgoCD will pull from this repository.
AWS CLI configured with credentials that have EKS describe and IAM read permissions for the aws eks update-kubeconfig command.
Basic kubectl familiarity for inspecting Pods, Deployments, and Services during the verification steps.

Setup — Install ArgoCD on EKS

Install ArgoCD into the argocd namespace using the official Helm chart, which manages the full ArgoCD deployment including the application controller, repository server, API server, and Redis. The `--wait` flag blocks until all ArgoCD pods are healthy, ensuring the installation is complete before proceeding. Retrieve the auto-generated admin password from the initial admin Secret.

Analogy🏏Cricket

🏏 Think of it like cricket: Commissioning a new stadium's operations centre, you install the whole control room at once — scoreboard operators, broadcast desk, ground comms and the backup radio — and you don't open the gates until every station reports ready. That is exactly helm install for ArgoCD: it deploys the application controller, repository server, API server and Redis together, and the --wait flag blocks until all pods are healthy before you proceed. Just as the head of operations collects the master keys from the sealed envelope before the first match, you retrieve the auto-generated admin password from the initial admin Secret. Just as the control room must be fully staffed and verified before play, --wait guarantees the installation is complete before the next step runs. The payoff: a single, atomic, health-gated install brings the entire GitOps control plane online cleanly, ready to manage deployments.

bash

# Prerequisites: EKS cluster running, kubectl configured, Helm 3 installed.
# Replace CLUSTER_NAME and AWS_REGION with your values.

CLUSTER_NAME=india-squad-eks
AWS_REGION=ap-south-1

# 1. Verify kubectl context points to the EKS cluster
aws eks update-kubeconfig --name $CLUSTER_NAME --region $AWS_REGION
kubectl cluster-info

# 2. Install ArgoCD using the official Helm chart
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

helm upgrade --install argocd argo/argo-cd \
  --namespace argocd --create-namespace \
  --set server.service.type=LoadBalancer \
  --set configs.params.server\.insecure=true \
  --wait

# 3. Retrieve the initial admin password (stored in a Secret)
ARGOCD_PASSWORD=$(kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath='{.data.password}' | base64 -d)
echo "ArgoCD admin password: $ARGOCD_PASSWORD"

# 4. Get the LoadBalancer hostname for the ArgoCD UI
ARGOCD_HOST=$(kubectl -n argocd get svc argocd-server \
  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
echo "ArgoCD UI: https://$ARGOCD_HOST"

# 5. Log in with the CLI
argocd login $ARGOCD_HOST --username admin --password $ARGOCD_PASSWORD --insecure

Step 1 — GitOps Repository Structure

Create a GitOps repository with a Kustomize base directory containing the Namespace, Deployment, and Service manifests, and a production overlay that patches the replica count. The base uses a placeholder nginx image to focus the lab on the GitOps workflow rather than building a custom image. The Kustomize overlay's JSON patch operation replaces the base replica count of two with the production value of five.

Analogy🏏Cricket

Think of it like cricket: The base directory is the standard match-day operations template: the procedures that apply to any match at any venue. The production overlay is the venue-specific addendum that adjusts the standard template for this specific ground: 'replicas: 5 because this venue hosts 50,000 spectators and needs five service counters, not the standard two.' Just as the addendum references the standard template and modifies only what differs, the Kustomize overlay references the base and patches only the replica count. Just as the base template does not need to be rewritten when a new venue addendum is added, the base manifests do not need to change when a new environment overlay is added.

bash

# Step 1: Create the GitOps repository structure and push to GitHub.

mkdir india-squad-gitops && cd india-squad-gitops
git init

# Base Kubernetes manifests (shared across environments)
mkdir -p base
cat > base/namespace.yaml << 'EOF'
apiVersion: v1
kind: Namespace
metadata:
  name: squad-prod
  labels:
    managed-by: argocd
EOF

cat > base/deployment.yaml << 'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: india-squad-api
  namespace: squad-prod
spec:
  replicas: 2
  selector:
    matchLabels: { app: india-squad-api }
  template:
    metadata:
      labels: { app: india-squad-api }
    spec:
      containers:
        - name: api
          image: nginx:1.27     # placeholder; will be replaced by image automation
          ports: [{containerPort: 80}]
EOF

cat > base/service.yaml << 'EOF'
apiVersion: v1
kind: Service
metadata:
  name: india-squad-api
  namespace: squad-prod
spec:
  selector: { app: india-squad-api }
  ports: [{port: 80, targetPort: 80}]
EOF

cat > base/kustomization.yaml << 'EOF'
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - namespace.yaml
  - deployment.yaml
  - service.yaml
EOF

# Production overlay — patches replica count and sets the image tag
mkdir -p overlays/production
cat > overlays/production/kustomization.yaml << 'EOF'
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
patches:
  - target: { kind: Deployment, name: india-squad-api }
    patch: |
      - op: replace
        path: /spec/replicas
        value: 5
EOF

git add . && git commit -m 'feat: initial GitOps repository structure'
# Push to your GitHub repository
git remote add origin https://github.com/MY_ORG/india-squad-gitops.git
git push -u origin main