GitOps with Argo CD for Your Tetris App

Deploy a GitOps pipeline with Argo CD to auto-sync your Tetris app from Git.

Introduction

30 Second Summary

Every time you want to update your app on Kubernetes, you run kubectl apply manually. If someone on your team accidentally changes the live cluster, you might not even notice until something breaks.

In this project, you will install Argo CD into your Minikube cluster and connect it to your GitHub repository. Once connected, pushing a YAML change automatically deploys your Tetris app and any manual cluster drift is self-healed within seconds.

What You'll Build

You push a manifest change to GitHub and watch Argo CD automatically detect the difference, sync your cluster to match, and restore any unauthorized drift, all visible in a real-time web dashboard.

By the end of this project, you'll have:

  • A live Argo CD dashboard inside your Minikube cluster where you can see your Tetris app's sync status, health, and resource tree at a glance.
  • A GitOps workflow where your GitHub repository is the single source of truth. Push a manifest change and Argo CD deploys it automatically.
  • Self-healing in action. Manually break the live cluster state and watch Argo CD restore it within seconds, proving the cluster always matches Git.
  • Secret Mission: Enable auto-pruning and test it by creating a resource via Git, then removing it from Git and watching Argo CD automatically delete it from the cluster.

Are there any prerequisites?

This project continues from Project 3 (Deploy a Tetris App to Kubernetes). You need a running Minikube cluster with your tetris-deployment and tetris-service already applied.

You also need Docker Desktop running, Homebrew installed, and a GitHub account with the tetris repository from Project 2.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters. You're adding Argo CD to your existing Minikube cluster so that instead of running kubectl apply manually, you'll push changes to Git and let Argo CD deploy them automatically.

Install Argo CD and the CLI

Your Minikube cluster can run pods, but it has no way to watch a Git repository and automatically deploy changes when those files are updated.

Argo CD fills that gap by continuously comparing your Git manifests to the live cluster state. In this step, you'll install the Argo CD CLI and deploy the Argo CD server into your cluster.

In this step, get ready to:
  • Install the Argo CD CLI via Homebrew.
  • Deploy Argo CD v3.5.0 to your Minikube cluster.
  • Access the Argo CD web UI and log in with admin credentials.
Install the Argo CD CLI and deploy Argo CD to the cluster

The Argo CD CLI lets you interact with the Argo CD server from your terminal. You'll use it to retrieve credentials and manage applications later in this project.

  • Install the Argo CD CLI by running this command:
brew install argocd
  • Verify the installation succeeded by running:
argocd version --client

✔️ I see version information

You're all set. The CLI is installed and ready to use.

ⓧ Command not found

Your terminal cannot find the argocd binary. Try these fixes:

  • Close and reopen your terminal, then run the command again.
  • Run brew link argocd to ensure the binary is linked to your PATH.
  • If you see a permissions error, run brew link --overwrite argocd instead.

Now you'll deploy the Argo CD server components into your Minikube cluster. This creates all the pods, services, and controllers that Argo CD needs to operate.

  • Create the argocd namespace and deploy Argo CD v3.5.0 by running these commands:
kubectl create namespace argocd
kubectl apply -n argocd --server-side --force-conflicts -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.5.0/manifests/install.yaml

What do these commands do?

  • kubectl create namespace argocd creates a dedicated namespace to isolate all Argo CD resources from your application workloads.
  • kubectl apply with the manifest URL downloads and installs all Argo CD components (server, repo server, application controller, Redis, and more) from the official release.
  • The --server-side --force-conflicts flags ensure the installation applies cleanly even if resources already exist.

You'll see a long list of resources being created (roles, services, deployments, configmaps, etc.). This is expected.

  • Wait for all Argo CD pods to reach Running status by running:
kubectl get pods -n argocd -w

The -w flag watches the pods in real time. You'll see pod statuses update from ContainerCreating to Running. Once all pods show Running in the STATUS column, press Ctrl+C to stop watching.

Pods stuck in Pending or CrashLoopBackOff?

  • Make sure Docker Desktop is running. Minikube needs Docker to pull container images.
  • If you see resource errors, your Minikube cluster may need more memory. Stop it with minikube stop then restart with minikube start --memory=4096.
  • Wait a full minute and check again. Some pods depend on others starting first.

Still stuck? Help me troubleshoot why my Argo CD pods won't start in Minikube.

Access the Argo CD UI and retrieve admin credentials

Argo CD runs inside your cluster, so you need port-forwarding to access its web UI from your browser. This tunnels traffic from a port on your machine into the cluster.

  • Start port-forwarding to the Argo CD server by running:
kubectl port-forward svc/argocd-server -n argocd 8080:443

This command takes over your terminal

The port-forward process runs in the foreground and keeps your terminal busy. You'll see a message confirming that forwarding is active. Leave this terminal open and running for the rest of the project.

  • Open a new terminal window by pressing Cmd+T (macOS) or Ctrl+Shift+T (Windows/Linux).
  • Retrieve the initial admin password by running:
argocd admin initial-password -n argocd

What is this password?

Argo CD auto-generates a random admin password during installation and stores it in a Kubernetes secret called argocd-initial-admin-secret. This command retrieves that password so you can log in for the first time.

  • Copy the password that appears in your terminal output. You'll need it in the next step.

Before you open the browser, what do you think you'll see at https://localhost:8080? Remember the Argo CD server uses a self-signed certificate.

  • Open https://localhost:8080 in your browser.
  • Your browser will show a security warning about the self-signed certificate. In Chrome, click Advanced then Proceed to localhost (unsafe). In Firefox, click Advanced then Accept the Risk and Continue.
  • Enter admin as the username.
  • Paste the password you copied from the terminal as the password.
  • Click SIGN IN.

You should see the Argo CD dashboard with an empty applications list. This confirms Argo CD is installed and running correctly.

Can't reach localhost:8080?

  • Check that the port-forward terminal is still running. If it stopped, re-run kubectl port-forward svc/argocd-server -n argocd 8080:443.
  • Make sure you're using https:// not http:// in the URL. Argo CD serves over HTTPS.
  • If port 8080 is already in use, stop the conflicting process or use a different local port: kubectl port-forward svc/argocd-server -n argocd 9090:443 and then open https://localhost:9090.

Still can't connect? Help me troubleshoot why I cannot access the Argo CD UI at localhost:8080.

Argo CD is installed and you're logged into the dashboard. Next, you'll push your Tetris manifests to GitHub so Argo CD has a repository to watch.

Push Your Tetris Manifests to GitHub

Argo CD is up and running in your cluster with a dashboard you can log into. Now it needs something to watch.

Right now, your Tetris Kubernetes manifests from Project 3 only exist locally on your machine. Without them in a Git repository, Argo CD has nothing to sync from. In this step, you will push your deployment and service manifests to GitHub so Argo CD can use them as the single source of truth.

In this step, get ready to:
  • Create a k8s/ directory in your tetris repo with Kubernetes manifests.
  • Push the manifests to your GitHub repository on the master branch.
Create the k8s directory and manifest files

Your port-forward command from Step 1 is still occupying your terminal. You need a second terminal for Git operations.

  • Open a new terminal tab or window by pressing Cmd+T (macOS) or Ctrl+Shift+T (Windows).
  • Navigate to your local tetris repository by running this command:
cd ~/Desktop/tetris
  • Create the k8s/ directory by running:
mkdir k8s
  • Confirm the directory was created by running:
ls

You should see k8s listed alongside your existing project files.

Don't see the k8s directory?

Make sure you ran mkdir k8s from inside the ~/Desktop/tetris folder. Run pwd to check your current location.

help me find my tetris repo directory

Now you will create the two Kubernetes manifests that define your Tetris app. The Deployment tells Kubernetes how many replicas to run and which container image to use.

  • Create a file called k8s/deployment.yaml and paste the following content:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tetris-deployment
  labels:
    app: tetris
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tetris
  template:
    metadata:
      labels:
        app: tetris
    spec:
      containers:
      - name: tetris
        image: [[DOCKERHUB_USER="your-dockerhub-username"]]/tetris-app:v1.0
        ports:
        - containerPort: 80

What does this manifest do?

  • replicas: 2 tells Kubernetes to run two copies of your Tetris container for availability.
  • image: .../tetris-app:v1.0 points to the Docker Hub image you built in a previous project.
  • selector and labels connect the Deployment to the pods it manages using the app: tetris label.
  • containerPort: 80 exposes port 80 on each pod so traffic can reach the Tetris web server.
  • Save k8s/deployment.yaml.
  • Confirm the file exists by running:
ls k8s/

You should see deployment.yaml listed.

File not showing up?

Double-check that you saved the file inside the k8s/ subdirectory, not in the repo root. The path should be ~/Desktop/tetris/k8s/deployment.yaml.

help me create deployment.yaml in the right location

Next, the Service manifest exposes your Deployment's pods to network traffic using a NodePort.

  • Create a file called k8s/service.yaml and paste the following content:
apiVersion: v1
kind: Service
metadata:
  name: tetris-service
  labels:
    app: tetris
spec:
  type: NodePort
  selector:
    app: tetris
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

What does this manifest do?

  • type: NodePort makes the Service reachable from outside the cluster on a high-numbered port.
  • selector: app: tetris routes traffic to any pod carrying the app: tetris label.
  • port: 80 and targetPort: 80 forward incoming traffic on port 80 to the container's port 80.
  • Save k8s/service.yaml.
  • Confirm both manifest files are present by running:
ls k8s/

You should see both deployment.yaml and service.yaml listed.

Only seeing one file?

Make sure both files are saved inside the k8s/ directory. Check the file names match exactly: deployment.yaml and service.yaml (no typos, no extra extensions like .yml).

help me check my k8s directory files

✔️ Awesome, I've got everything!

Great. Make sure both files are saved before moving on to push them to GitHub.

ⓧ I'd like to double check the full code

Here is k8s/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tetris-deployment
  labels:
    app: tetris
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tetris
  template:
    metadata:
      labels:
        app: tetris
    spec:
      containers:
      - name: tetris
        image: [[DOCKERHUB_USER="your-dockerhub-username"]]/tetris-app:v1.0
        ports:
        - containerPort: 80

Here is k8s/service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: tetris-service
  labels:
    app: tetris
spec:
  type: NodePort
  selector:
    app: tetris
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
Push to GitHub

Your manifests are ready locally. Now push them to your GitHub repository so Argo CD has a remote source to watch.

  • Stage, commit, and push your new k8s/ directory by running these commands:
git add k8s/
git commit -m "Add Kubernetes manifests for Argo CD"
git push origin master

What do these commands do?

  • git add k8s/ stages both YAML files for commit.
  • git commit saves a snapshot with a descriptive message.
  • git push origin master uploads the commit to your GitHub repository's master branch.

Push rejected or authentication error?

If you see an authentication error, your GitHub credentials may have expired. Try running git push origin master again and re-enter your credentials or personal access token when prompted.

If the push is rejected because the remote has changes you do not have locally, run git pull origin master first, then try pushing again.

help me push my k8s manifests to GitHub

Before you check GitHub, what do you expect to see in your repository?

  • Open your GitHub tetris repository in a browser.
  • Confirm the k8s/ directory is visible and contains both deployment.yaml and service.yaml.

You should see the k8s/ folder on your repository's main page with both files inside it. This is what Argo CD will watch for changes in the next step.

Your manifests are now live on GitHub. Next up, you will create an Argo CD Application that points at this repository and watches it for changes.

Create an Argo CD Application and Sync Manually

Your Tetris manifests are on GitHub, but Argo CD has no idea your app exists. It needs an Application resource that tells it which Git repo to watch, which path holds the manifests, and where to deploy them.

You will start with manual sync so you can see the OutOfSync state first. This proves Argo CD detects drift between Git and the cluster before you give it permission to auto-fix.

In this step, get ready to:
  • Create an Application manifest that points Argo CD to your GitHub repository.
  • Apply the manifest and trigger a manual sync to deploy your Tetris app through Argo CD.
Create the Application manifest

An Argo CD Application is a Custom Resource Definition (CRD) that connects a Git source to a cluster destination. It tells Argo CD exactly where your manifests live and where to deploy them.

  • Create a file called application.yaml in the root of your tetris folder (~/Desktop/tetris) by pasting the following:
# Defines the Argo CD Application that watches your Git repo
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tetris-app
  namespace: argocd
spec:
  project: default
  source:
    # Points to your GitHub repository
    repoURL: [[YOUR_REPO_URL="https://github.com/YOUR_USERNAME/tetris.git"]]
    targetRevision: master
    path: k8s
  destination:
    # Deploys to the same cluster Argo CD runs in
    server: https://kubernetes.default.svc
    namespace: default

What does this manifest do?

  • metadata.namespace: argocd places the Application in the namespace where Argo CD lives. All Application resources must go here.
  • source.repoURL tells Argo CD which Git repo to pull manifests from.
  • source.path: k8s narrows it down to the k8s/ directory inside that repo.
  • destination.server: https://kubernetes.default.svc means deploy to the same cluster Argo CD is running in. No external cluster registration needed.
  • There is no syncPolicy field. This means Argo CD will detect changes but will NOT apply them automatically.
  • Save application.yaml.
  • Confirm the file exists by running:
ls ~/Desktop/tetris/application.yaml

You should see the file path printed back to you.

Don't see the file?

Make sure you saved the file in the tetris repo root (~/Desktop/tetris/), not inside the k8s/ subdirectory.

help me find where my application.yaml was saved

Apply the Application and trigger a manual sync

With the manifest saved, you can now tell your cluster about this new Application resource. Argo CD will immediately start comparing what is in Git to what is in the cluster.

  • Make sure you are in your tetris directory by running:
cd ~/Desktop/tetris
  • Apply the Application manifest to your cluster by running:
kubectl apply -f application.yaml

You should see:

application.argoproj.io/tetris-app created

Before you check the Argo CD UI, what status do you think the app will show? Remember, there is no syncPolicy defined.

  • Switch to your browser and open the Argo CD UI at https://localhost:8080.
  • Look at the tetris-app tile that now appears on the dashboard.

The tile shows OutOfSync with a yellow indicator and a health status of Missing. This is expected. Argo CD sees that your Git repo has manifests, but those resources do not exist in the cluster under its management yet.

Why OutOfSync and not an error?

OutOfSync is not an error. It means Git and the cluster differ. Because you have no syncPolicy, Argo CD is reporting the drift but waiting for your permission to fix it.

This is the whole point of starting with manual sync. You get to see the gap before choosing to close it.

  • Trigger a manual sync by running this command in your terminal:
argocd app sync tetris-app --port-forward-namespace argocd

What does this command do?

argocd app sync tells Argo CD to apply the manifests from Git to the cluster right now. The --port-forward-namespace argocd flag lets the CLI talk to the Argo CD server through the same port-forward you set up earlier.

The command outputs a sync summary table showing each resource and its status. You should see tetris-deployment and tetris-service both marked as Synced.

  • Return to the Argo CD UI in your browser.
  • Click the tetris-app tile to open the application detail view.

The status now shows Synced and Healthy. The resource tree displays your Deployment, ReplicaSet, Pods, and Service.

  • Confirm your Tetris pods are running by checking in the terminal:
kubectl get pods -n default

You should see 2 pods with names starting with tetris-deployment- in Running status.

Still seeing OutOfSync or pods not running?

  • Check that your repoURL in application.yaml matches your actual GitHub repository URL exactly (including .git at the end).
  • Verify your repo is public. Argo CD cannot pull from private repos without credentials configured.
  • Run argocd app get tetris-app --port-forward-namespace argocd to see detailed sync status and any error messages.

help me debug why my Argo CD application is not syncing

✔️ Awesome, I've got everything!

Great. Double check you have saved application.yaml and that your Argo CD UI shows Synced and Healthy.

ⓧ I'd like to double check the full code

Here is what your application.yaml should look like (replace the repoURL with your own GitHub repo):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tetris-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/shafiswapnil/tetris.git
    targetRevision: master
    path: k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: default

Your Tetris app is now deployed and managed by Argo CD. But you still had to click a button to sync. Next up, you will enable automated sync with self-healing so the cluster always matches Git without any manual intervention.

Enable Automated Sync and Test Self-Healing

Your Argo CD Application is synced and healthy, but there's a problem. Every time you want to deploy a change, you still have to click the Sync button manually. That defeats the purpose of GitOps.

The whole point of a GitOps workflow is that the cluster automatically converges to whatever is in Git. In this step, you will enable automated sync with self-healing so Argo CD becomes a true GitOps engine that detects drift and corrects it without human intervention.

In this step, get ready to:
  • Enable automated sync so Argo CD deploys Git changes without manual clicks.
  • Test self-healing by intentionally breaking the live cluster state.
  • Watch Argo CD automatically restore the cluster to match Git within seconds.
Update the Application to enable automated sync

Right now your application.yaml has no syncPolicy section. That means Argo CD waits for you to click Sync every time Git changes. Adding a syncPolicy with automated and selfHeal: true tells Argo CD to sync automatically and revert any manual changes made directly to the cluster.

  • Open application.yaml in your text editor and replace its entire contents with the following:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tetris-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/shafiswapnil/tetris.git
    targetRevision: master
    path: k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  # NEW: Enable automated sync with self-healing
  syncPolicy:
    automated:
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

What does the new syncPolicy section do?

  • automated tells Argo CD to sync whenever it detects a difference between Git and the cluster, no button click required.
  • selfHeal: true means if someone (or something) modifies the live cluster directly, Argo CD reverts it to match Git within 5 seconds.
  • CreateNamespace=true lets Argo CD create the destination namespace if it does not already exist.
  • Save application.yaml.
  • Apply the updated manifest to your cluster by running:
kubectl apply -f application.yaml

You should see application.argoproj.io/tetris-app configured in the output.

  • Switch to the Argo CD UI at https://localhost:8080.
  • Click on the tetris-app tile. You should see Auto-Sync now displayed in the sync policy section.

Don't see Auto-Sync in the UI?

  • Make sure you saved application.yaml before running kubectl apply.
  • Check that syncPolicy is indented under spec: (two spaces in from spec). YAML is whitespace-sensitive.
  • Refresh the Argo CD UI page if it hasn't updated.

Why isn't my syncPolicy showing up in the Argo CD UI?

✔️ Awesome, I've got everything!

Great. Double check you saved your file and the output confirmed configured.

ⓧ I'd like to double check the full code

Here is the complete application.yaml at this point:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tetris-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/shafiswapnil/tetris.git
    targetRevision: master
    path: k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
Test self-healing by breaking the live state

Argo CD claims it will self-heal drift. Time to put that to the test. You will manually scale down the Tetris deployment and watch Argo CD detect the difference and restore it.

Before you run the next command, think about what you expect to happen. If Git says 2 replicas but you manually set 1, what do you think Argo CD will do?

  • Intentionally break the live state by scaling down to 1 replica:
kubectl scale deployment tetris-deployment --replicas=1 -n default
  • Immediately watch the pods to see what happens next:
kubectl get pods -l app=tetris -n default -w

Within seconds, you will see Argo CD detect the drift and spin up a second pod automatically. The output will show a new pod transition from Pending to Running, restoring the deployment to 2 replicas.

What just happened?

You told Kubernetes to scale to 1 replica, creating a difference between the live state (1 pod) and Git (2 replicas in k8s/deployment.yaml). Argo CD detected this drift within 5 seconds and automatically reverted the change to match Git.

No one clicked Sync. No one re-applied any manifest. Argo CD did it all on its own.

  • Press Ctrl+C to stop the watch.
  • Confirm the final state by running:
kubectl get pods -l app=tetris -n default

You should see 2 pods with status Running.

  • Switch to the Argo CD UI. The tetris-app tile may have briefly shown OutOfSync, but it should now be back to Synced and Healthy.

Pods didn't scale back up?

  • Make sure your application.yaml was applied with selfHeal: true in the previous substep.
  • Verify the port-forward to the Argo CD server is still running. If the terminal closed, restart it with kubectl port-forward svc/argocd-server -n argocd 8080:443.
  • Wait up to 10 seconds. Self-healing triggers within 5 seconds by default, but pod startup adds a few more.

My Argo CD self-heal is not restoring my pods after I scaled down. Help me debug.

Understand why self-healing matters

Why is self-healing important?

What you just proved is that Git is the single source of truth. No manual kubectl change can persist, because Argo CD continuously reconciles the live state against the desired state in your repository.

In production, this prevents configuration drift, accidental deletions, and unauthorized changes. If someone scales down a deployment by mistake or a rogue process mutates a resource, Argo CD catches it and fixes it automatically.

You have proven that Argo CD automatically heals any manual drift. Next, you will prove the full GitOps loop: push a change to Git and watch it deploy without any intervention at all.

Push a Change to Git and Watch Auto-Deploy

In the last step, you proved that Argo CD can self-heal drift by reverting manual kubectl changes. That proves the cluster-to-Git direction works.

But the real GitOps promise is the other direction: push a change to Git and watch it automatically appear in the cluster without clicking a single button. In this step, you will update the Tetris image tag in your manifest, push it to GitHub, and watch Argo CD deploy the rolling update on its own.

In this step, get ready to:
  • Update the image tag in your deployment manifest and push the change to GitHub.
  • Watch Argo CD automatically detect the new commit and deploy the rolling update without manual intervention.
Update the image tag in Git

Your k8s/deployment.yaml currently references v1.0 of the Tetris image. You built a v2.0 image back in an earlier project. Updating the tag in Git is all it should take to trigger a full rolling update.

  • If you still have the port-forward running in your current terminal, open a new terminal tab or window first.
  • Navigate to your local tetris repository by running:
cd ~/Desktop/tetris
  • Open k8s/deployment.yaml in your text editor.
  • Find this line in the containers section:
        image: shafiswapnil/tetris-app:v1.0
  • Change v1.0 to v2.0, so the line now looks like this:
        image: shafiswapnil/tetris-app:v2.0
  • Save the file.
  • Stage, commit, and push the change by running these commands:
git add k8s/deployment.yaml
git commit -m "Update Tetris to v2.0"
git push origin master

What do these commands do?

  • git add stages the changed file for commit.
  • git commit saves the change with a descriptive message.
  • git push origin master sends the new commit to your GitHub repository's master branch, where Argo CD is watching.
  • Confirm the push succeeded by checking the terminal output. You should see a line like master -> master confirming the branch was updated.

Push rejected or authentication failed?

  • If you see rejected, someone else may have pushed to the repo. Run git pull origin master first, then push again.
  • If authentication fails, make sure your GitHub credentials or SSH key are configured correctly for this repository.
  • Help me troubleshoot my git push
Watch Argo CD auto-deploy

Argo CD polls your GitHub repository every 3 minutes by default (its reconciliation interval). Within that window, it will detect the new commit and automatically sync the cluster to match.

  • Switch back to the Argo CD UI at https://localhost:8080.
  • Click the tetris-app tile to open the application detail view.
  • Watch the status. Within 3 minutes, the app briefly shows OutOfSync as it detects the new commit, then transitions to Synced once the rolling update completes.

Speed up the sync

If you do not want to wait, click Refresh in the Argo CD UI to force an immediate poll of your repository.

Before you run the next command, what image tag do you expect to see on the deployment? Think about what Git now says versus what the cluster had before.

  • Verify the rolling update completed by running:
kubectl describe deployment tetris-deployment -n default | grep Image

You should see shafiswapnil/tetris-app:v2.0 in the output. This confirms Argo CD detected the Git change and updated the cluster automatically.

  • Confirm the pods are running the new image by checking their age:
kubectl get pods -l app=tetris -n default

Both pods should show a recent AGE value (seconds or minutes old), proving they were recreated during the rolling update.

What just happened?

You changed one line in a YAML file, pushed it to GitHub, and did nothing else. Argo CD detected the new commit, compared the desired state in Git to the live cluster state, and performed a rolling update to bring the cluster in line.

No kubectl apply needed. No CI pipeline trigger. Git is the single source of truth, and Argo CD is the engine that enforces it.

Still showing v1.0 after 3 minutes?

  • Make sure your git push actually succeeded. Run git log --oneline -1 and confirm the latest commit message is Update Tetris to v2.0.
  • Check that your port-forward is still active. If it dropped, restart it with kubectl port-forward svc/argocd-server -n argocd 8080:443.
  • Verify the app sync status by running argocd app get tetris-app --port-forward-namespace argocd and check if there is a sync error.
  • Help me troubleshoot why Argo CD is not auto-syncing

✔️ Awesome, I've got everything!

Great. Double check you saved k8s/deployment.yaml with the v2.0 image tag and that your kubectl describe output confirms the new image.

ⓧ I'd like to double check the full code

Here is the full k8s/deployment.yaml as it should look now:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tetris-deployment
  labels:
    app: tetris
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tetris
  template:
    metadata:
      labels:
        app: tetris
    spec:
      containers:
      - name: tetris
        image: shafiswapnil/tetris-app:v2.0
        ports:
        - containerPort: 80

You just proved the complete GitOps loop. A single line change in Git triggered an automatic deployment to your cluster. Next up, you will take on the Secret Mission and push Argo CD even further with auto-pruning.

Secret mission

Enable Auto-Pruning

Self-healing ensures the cluster matches Git when resources are modified. But what happens when you delete a manifest from Git entirely? By default, Argo CD leaves the orphaned resource running in the cluster. In this mission, you'll enable auto-pruning so that removing a file from Git automatically removes the resource from Kubernetes.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally on Minikube, so there are no ongoing cloud costs.

Resources you used:

  • Argo CD running in the argocd namespace inside Minikube (local, free, uses Docker Desktop CPU and memory).
  • Minikube cluster running locally (local, free).
  • GitHub repository with k8s/ manifests (free for public repos).
  • Docker Hub images (free for public repos).

Keep everything running

No action needed. Choose this if you plan to continue with the next project in this series. Argo CD continues watching your repo for changes.

  • The port-forward will stop when you close the terminal. Restart it anytime with:
  • Your Tetris app remains deployed and auto-synced from Git.
  • The Argo CD CLI remains installed on your machine via Homebrew.
kubectl port-forward svc/argocd-server -n argocd 8080:443

Pause - I'll come back to this later

Stop the Minikube cluster to free up CPU and memory. Your cluster state is preserved on disk.

  • Stop Minikube by running:
minikube stop
  • When you are ready to resume, start it again:
minikube start

Argo CD and your Tetris app will restart automatically when the cluster comes back up.

Delete - I don't want to use this again

Remove all project resources and start fresh. Run these commands in your terminal.

  • Delete the Argo CD namespace (removes Argo CD and all its resources):
kubectl delete namespace argocd
  • Delete the Tetris resources from the default namespace:
kubectl delete -f k8s/ -n default
  • Remove the application.yaml file from your local repo:
rm application.yaml
  • Delete the Minikube cluster entirely:
minikube delete
  • Your GitHub repository and Docker Hub images are free and do not incur any cost. If you want to delete the GitHub repository, go to your repository page, click Settings, scroll to the Danger Zone section, and click Delete this repository.

Nice Work!

Nice Work!

Nice work! You just implemented a full GitOps pipeline using Argo CD that automatically deploys, syncs, and self-heals your Tetris application from Git.

You've learned how to:

  • Deploy Argo CD into your Minikube cluster and connect it to a GitHub repository as the single source of truth for your Kubernetes manifests.
  • Enable automated sync with self-healing so the cluster always matches Git, and prove it by manually breaking the live state and watching Argo CD restore it within seconds.
  • Complete the full GitOps loop by pushing an image tag change from v1.0 to v2.0 in Git and watching Argo CD auto-deploy the rolling update without any manual intervention.
  • Secret Mission: Enabled auto-pruning so Argo CD automatically removes cluster resources when their manifests are deleted from Git.

Ready to quiz yourself?