Argo CD: Continuous Deployment for Kubernetes

Every deployment in this course so far ended the same way: log in to the EKS home server, run kubectl apply -f .... In a team, that does not work for long. A developer pushes a change to GitHub, and then somebody has to remember to apply it. Somebody else edits a live object with kubectl edit and nobody knows. After a few weeks, nobody can say exactly what is running in the cluster or why.

Argo CD fixes this with an idea called GitOps:

• The Kubernetes YAML for your application lives in a Git repository. Git is the single source of truth.
• Argo CD runs inside the cluster and keeps watching that repository.
• When the YAML in Git changes, Argo CD applies the change to the cluster. When the cluster drifts away from Git, Argo CD shows it, and can put it back.

The "CD" means continuous deployment (or delivery). You commit, Argo CD deploys. Nobody runs kubectl apply by hand.

Step 1: Install Argo CD with Helm

We installed Helm in the previous lesson. On Artifact Hub search for argo-cd, sort by stars, and open the chart from the argo repository (published by the Argo project). Its install tab gives the repository command:

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

NAME: argocd
NAMESPACE: argocd
STATUS: deployed
REVISION: 1
NOTES:
In order to access the server UI you have the following options:

1. kubectl port-forward service/argocd-server -n argocd 8080:443
    and then open the browser on http://localhost:8080 and accept the certificate
...
After reaching the UI the first time you can login with username: admin and the random password generated during the installation. You can find the password by running:

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

The NOTES are written by the chart author for exactly this moment. Always read them. helm status argocd -n argocd prints them again later.

See how much Helm created for us:

kubectl get all -n argocd

You see Deployments for argocd-server, argocd-repo-server, argocd-applicationset-controller, argocd-dex-server, argocd-notifications-controller and argocd-redis, a StatefulSet for argocd-application-controller, their ReplicaSets and pods, and a set of Services. Imagine writing all of that by hand.

Step 2: Get the admin password and open the UI

Every Service is ClusterIP, so nothing is reachable from outside yet. First, the password. The username is admin:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d; echo

-o jsonpath picks one field from the Secret, and base64 -d decodes it, exactly like in the Secrets lesson. The trailing echo adds a newline, so the password does not run into your shell prompt as it did in the lecture.

The lecture exposes the UI by turning the argocd-server Service into a LoadBalancer:

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

Wait a minute or two for the EXTERNAL-IP hostname, then open https://<that-hostname> in the browser. Argo CD uses a self-signed certificate, so the browser warns you: choose Advanced and Proceed. Log in as admin with the password.

kubectl port-forward svc/argocd-server -n argocd 8080:443 --address 0.0.0.0

Step 3: Put your application in Git

Create a GitHub repository of your own (for example k8s-argocd) with one file, argocd.yml, holding a Deployment and a Service. This is the same shape you have written many times:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: product-deployment
  labels:
    app: telusko
spec:
  replicas: 4
  selector:
    matchLabels:
      app: telusko
  template:
    metadata:
      labels:
        app: telusko
    spec:
      containers:
        - name: cont1
          image: <your-dockerhub-username>/springboot-app:latest
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: teluskoappsvc
spec:
  type: LoadBalancer
  selector:
    app: telusko
  ports:
    - port: 80
      targetPort: 8080

A public repository is easiest for practice. For a private one, add credentials under Settings, Repositories in Argo CD first.

Step 4: Create the Application

In the UI click + New App and fill in:

Click Create. The app shows Synced and then Healthy. Click it to see the tree that Argo CD builds from live objects: the Application, the Service and the Deployment, its ReplicaSet, and four pods.

The Application tree right after the replica count in Git was changed to 8: new pods appear next to the existing ones.

The tree also has a network view (how traffic flows from the load balancer through the Service to each pod) and a list view. Click any pod for its events, logs and manifest.

The same Application as YAML, which is how teams usually store it (in Git, of course):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: telusko-learning
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/<you>/k8s-argocd.git
    targetRevision: HEAD
    path: .
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Step 5: Deploy by committing

Edit argocd.yml in GitHub (or in VS Code and push) and change replicas: 4 to replicas: 8. Commit.

Back in Argo CD, click Refresh (or wait). The app goes OutOfSync for a moment, syncs, and eight pods are running. You did not touch kubectl. Change it back to 4 and commit again: Argo CD scales the Deployment back down.

Why the wait? By default Argo CD checks the repository about every 3 minutes (a 120-second interval plus up to 60 seconds of jitter). Refresh checks immediately, and a GitHub webhook pointed at Argo CD makes it react within seconds.

Sync options worth understanding

Try self-heal: with it enabled, run kubectl scale deploy product-deployment --replicas=1 and watch Argo CD restore 4 pods.

Why teams use Argo CD

• Automated deployments: commit and it is deployed
• Git as the single source of truth: every change is a commit with an author, a message and a review
• Easy rollback: go back to any earlier commit
• Visibility: the UI shows what is deployed, whether it matches Git, and whether it is healthy
• Less manual work and fewer mistakes: no one needs cluster admin rights just to deploy
• Drift detection: manual changes are visible, and can be reverted automatically

In a full pipeline, Jenkins or GitHub Actions builds and pushes the image (CI), then updates the image tag in the Git repository, and Argo CD deploys it (CD).

Clean up

# in the UI: open the app, Delete, confirm (this also deletes its Deployment and Service)
# or:
kubectl delete application telusko-learning -n argocd
kubectl get svc -A | grep LoadBalancer        # make sure teluskoappsvc is gone

kubectl patch svc argocd-server -n argocd -p '{"spec":{"type":"ClusterIP"}}'   # removes the Argo CD load balancer
helm uninstall argocd -n argocd                                                # when you are done with Argo CD
kubectl delete namespace argocd

Check EC2, Load Balancers afterwards: both the app's and Argo CD's load balancers must be gone. Deleting an Application from the UI deletes its resources only if the cascade option is chosen (it is by default); deleting with kubectl cascades only when the Application has the resources-finalizer.argocd.argoproj.io finalizer, so check that the app's Service is really gone.

Try It Yourself

1. Install Argo CD with Helm and log in using port-forward instead of a LoadBalancer.
2. Create the telusko-learning Application from the YAML file above instead of the UI, with kubectl apply -f telusko-learning-app.yml.
3. With selfHeal: true, scale the Deployment by hand and time how long Argo CD takes to undo it. Then set selfHeal: false and repeat.
4. Add a ConfigMap to argocd.yml, commit, then remove it and commit again. With prune: true and with prune: false, what happens to the ConfigMap in the cluster?
5. Change the image to a tag that does not exist and commit. What do Sync Status and App Health show? Fix it with git revert.

Official references

• Argo CD: Getting Started
• Argo CD: Automated Sync Policy
• Argo CD: Declarative Setup
• Argo Helm charts (argo-cd chart)

Written By: Shramik Masti