Phase 05 · Production & GitOpsChapter 32 of 33

Phase 05Read time ~17 minDifficulty intermediate

GitOps + Argo CD 🔄

Warrior, this is one of the most important chapters in the entire Kubernetes course.

In this chapter (74 sections)

You've already learned:

Git → CI → Docker → Registry → Kubernetes

Now we're going to change how Kubernetes deployments are controlled.

Instead of CI directly telling Kubernetes:

kubectl apply ...

we'll use:

Git
 ↓
Argo CD
 ↓
Kubernetes

This is called GitOps.

1. What is GitOps?#

The simplest definition:

GitOps means using Git as the source of truth for the desired state of your infrastructure and applications, with an automated system continuously reconciling Kubernetes to that state.

Remember Chapter 1?

Kubernetes works using:

Desired State
      ↓
Controller
      ↓
Actual State

GitOps takes that idea and makes Git the source of the desired state.

2. Traditional deployment#

Previously we learned:

Developer
    ↓
Git
    ↓
GitHub Actions
    ↓
Docker build
    ↓
Container Registry
    ↓
kubectl apply
    ↓
Kubernetes

For example:

kubectl apply -f deployment.yaml

The CI server directly changes the cluster.

3. GitOps deployment#

With GitOps:

Developer
    ↓
Git
    ↓
CI
    ↓
Docker Image
    ↓
Registry
 
Git
    ↓
Kubernetes manifests
    ↓
Argo CD
    ↓
Kubernetes

Notice something important:

CI doesn't necessarily need to directly deploy to Kubernetes.

Argo CD does.

4. Why is this useful?#

Imagine someone manually changes production:

kubectl scale deployment node-api --replicas=10

But Git says:

replicas: 3

Now:

Git = 3
Kubernetes = 10

The cluster has drifted from the desired configuration.

A GitOps controller can detect this difference.

Desired
3 replicas
 
Actual
10 replicas
 
        ↓
 
Drift detected

Depending on your Argo CD configuration, it can synchronize the cluster back to the Git-defined state.

5. The GitOps mental model#

This is extremely important:

                 Git
                  │
          Desired State
                  │
                  ↓
               Argo CD
                  │
          Reconciliation
                  │
                  ↓
             Kubernetes
                  │
            Actual State
                  │
                  ↓
             Pods/Services

Argo CD continuously compares:

Desired state
      VS
Actual state

6. What is Argo CD?#

Argo CD is a GitOps continuous delivery tool for Kubernetes.

Its primary job is:

Git repository
      ↓
Read Kubernetes configuration
      ↓
Compare with cluster
      ↓
Synchronize
      ↓
Kubernetes

It supports configurations such as:

plain Kubernetes YAML
Kustomize
Helm
Jsonnet
other supported configuration sources

7. Argo CD is not CI#

This distinction is critical.

CI#

Usually handles:

Build
Test
Lint
Security
Docker image

Argo CD#

Handles:

Deployment
Synchronization
Drift detection
Reconciliation

So:

CI
 ↓
Build artifact
 
Argo CD
 ↓
Deploy artifact/configuration

8. Complete GitOps architecture#

A modern pipeline can look like:

                    Developer
                        │
                        ↓
                       Git
                        │
             ┌──────────┴──────────┐
             ↓                     ↓
        Application repo       Deployment repo
             │                     │
             ↓                     ↓
            CI                  Argo CD
             │                     │
             ↓                     ↓
       Docker Image           Kubernetes
             │                     │
             ↓                     ↓
          Registry              Pods

There are different repository structures, but the separation is useful to understand.

9. Two Git repositories#

A common pattern:

Repository 1 — Application#

node-api/
├── src/
├── package.json
├── Dockerfile
└── tests/

Repository 2 — Deployment#

k8s-config/
├── base/
└── overlays/
    ├── dev/
    ├── staging/
    └── production/

Then:

Application repo
       ↓
CI
       ↓
Docker image
       ↓
Registry
 
Deployment repo
       ↓
Argo CD
       ↓
Kubernetes

10. Why separate repositories?#

Because application code and infrastructure configuration have different purposes.

Application repo:

"How does my application work?"

Deployment repo:

"How should this application run?"

For example:

replicas: 5

is deployment configuration.

While:

app.get("/users")

is application code.

11. But you don't have to use two repositories#

GitOps can also use a single repository.

For example:

my-project/
│
├── src/
├── Dockerfile
│
└── k8s/
    ├── base/
    └── overlays/

Argo CD watches:

/k8s

This is perfectly valid.

The right structure depends on team size, release model, ownership, and organizational needs.

12. Git becomes the source of truth#

Suppose Git contains:

replicas: 3

Argo CD sees:

Git = 3
Cluster = 3

Everything is synchronized.

Now someone changes the cluster manually:

kubectl scale deployment node-api --replicas=7

Now:

Git = 3
Cluster = 7

Argo CD sees:

DRIFT

If automated sync/self-healing is configured, Argo CD can reconcile the cluster back toward Git's desired state.

13. Desired vs actual state#

This is the heart of GitOps.

              Git
               │
               ↓
        Desired State
          replicas=3
               │
               ↓
            Argo CD
               │
               ↓
       Kubernetes Cluster
               │
               ↓
         Actual State
          replicas=3

When they differ:

Desired = 3
Actual  = 7
 
      ↓
 
     DRIFT

Argo CD can synchronize.

14. Argo CD Application#

Argo CD introduces an important object:

Application

An Argo CD Application tells Argo:

"This Git repository/path represents the desired state for this Kubernetes application."

Conceptually:

Argo CD Application
 
Repository:
github.com/company/platform
 
Path:
k8s/overlays/production
 
Destination:
production-cluster

15. Example Argo CD Application#

A simplified Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
 
metadata:
  name: node-api
 
spec:
  project: default
 
  source:
    repoURL: https://github.com/example/k8s-config.git
    targetRevision: main
    path: overlays/production
 
  destination:
    server: https://kubernetes.default.svc
    namespace: production
 
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Let's understand this piece by piece.

16. `source`#

source:
  repoURL: https://github.com/example/k8s-config.git
  targetRevision: main
  path: overlays/production

This says:

Git repository
     ↓
main branch
     ↓
overlays/production

That's where Argo CD gets the desired Kubernetes configuration.

17. `destination`#

destination:
  server: https://kubernetes.default.svc
  namespace: production

This specifies where the application should be deployed.

In a multi-cluster environment, the destination can identify a particular Kubernetes cluster.

18. `syncPolicy`#

This controls synchronization behavior.

For example:

syncPolicy:
  automated:
    prune: true
    selfHeal: true

This enables automated reconciliation behavior.

19. What is `selfHeal`?#

Imagine Git says:

replicas: 3

Someone manually changes:

replicas = 10

Argo CD detects:

Git      = 3
Cluster  = 10

With self-healing enabled, Argo CD can restore the Git-defined state.

Conceptually:

Manual change
     ↓
Drift
     ↓
Argo CD detects
     ↓
Reconcile
     ↓
Back toward desired state

20. What is `prune`?#

Suppose Git originally contains:

deployment.yaml
service.yaml
configmap.yaml

Then someone removes:

configmap.yaml

from Git.

Without appropriate pruning behavior, the old ConfigMap may remain in the cluster.

With pruning enabled:

Git
 ↓
ConfigMap removed
 ↓
Argo CD detects resource no longer desired
 ↓
Prune
 ↓
ConfigMap removed from cluster

Be careful with pruning in production.

You want Git to be authoritative, but accidental Git changes can have real consequences.

21. Sync#

Argo CD uses the concept of sync.

If:

Git desired state
        ≠
Cluster actual state

the application is out of sync.

Sync means:

Bring cluster toward Git-defined desired state.

22. Argo CD UI#

Argo CD provides a web UI where you can see:

Applications
Clusters
Resources
Sync status
Health
History
Events

You might see:

node-api
 
SYNC: Synced
HEALTH: Healthy

Or:

SYNC: OutOfSync
HEALTH: Degraded

This is extremely useful operationally.

23. Sync status vs health#

These are different.

Sync status#

Answers:

Does the cluster match the Git configuration?

Possible conceptual state:

Synced
OutOfSync

Health#

Answers:

Is the application/resource functioning according to Argo CD's health assessment?

Conceptually:

Healthy
Progressing
Degraded
Missing
Unknown

You can have:

Synced + Degraded

For example:

Git configuration = correctly applied
but
Pods = crashing

24. Very important distinction#

Synced

does not necessarily mean:

Application is healthy.

It means the cluster matches the desired configuration.

Example:

Deployment says:
 
image: broken-image:v5

Argo CD successfully applies it.

So:

SYNC = Synced
HEALTH = Degraded

because the Pods may fail to start.

25. GitOps deployment flow#

Let's say you release:

node-api v2

Developer changes:

image:
  tag: "v2"

Then:

git commit
      ↓
git push
      ↓
Argo CD detects change
      ↓
OutOfSync
      ↓
Sync
      ↓
Kubernetes Deployment
      ↓
Rolling Update
      ↓
New Pods
      ↓
Readiness
      ↓
Healthy

26. Where does CI fit?#

CI still builds the image.

For example:

Developer
   ↓
Git
   ↓
GitHub Actions
   ↓
Tests
   ↓
Docker Build
   ↓
Registry

Then CI needs to update the deployment configuration.

For example:

image:
  tag: "a8f72c1"

A commit is pushed to the deployment repository.

Then:

Deployment Git
     ↓
Argo CD
     ↓
Kubernetes

This creates a clean separation.

27. Image update automation#

Imagine CI builds:

node-api:a8f72c1

Then it updates:

images:
  - name: node-api
    newTag: a8f72c1

and commits that change.

Now:

Git
 ↓
new image reference
 ↓
Argo CD
 ↓
Kubernetes

The deployment itself becomes Git-driven.

28. Kustomize + Argo CD#

This is particularly relevant because Chapter 26 covered Kustomize.

Repository:

k8s/
│
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
│
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    │
    ├── staging/
    │   └── kustomization.yaml
    │
    └── production/
        └── kustomization.yaml

Argo CD can point to:

overlays/production

Argo understands the Kustomize configuration and generates the desired manifests.

29. Helm + Argo CD#

Argo CD can also deploy Helm charts.

Repository:

helm/
└── node-api/
    ├── Chart.yaml
    ├── values.yaml
    └── templates/

Argo CD points to:

helm/node-api

and can supply appropriate Helm values.

So:

Helm
   ↓
Kubernetes manifests
   ↓
Argo CD
   ↓
Kubernetes

30. Kustomize vs Helm with Argo#

Both work.

Helm#

Chart
 +
Values
 ↓
Rendered resources
 ↓
Argo CD

Kustomize#

Base
 +
Overlay
 ↓
Rendered resources
 ↓
Argo CD

Argo CD becomes the GitOps controller responsible for synchronizing the resulting desired state.

31. Multi-environment GitOps#

Suppose:

Development
Staging
Production

Repository:

k8s/
│
├── base/
│
└── overlays/
    ├── dev/
    ├── staging/
    └── production/

Then create Argo Applications:

node-api-dev
node-api-staging
node-api-production

Each points to:

different path

For example:

node-api-dev
    ↓
overlays/dev
 
node-api-staging
    ↓
overlays/staging
 
node-api-production
    ↓
overlays/production

32. ApplicationSet#

Imagine you have:

20 applications
3 environments

Creating every Argo Application manually can become repetitive.

Argo CD provides ApplicationSet for generating Applications from templates.

Conceptually:

ApplicationSet
      │
      ├── app1-dev
      ├── app1-prod
      ├── app2-dev
      ├── app2-prod
      ├── app3-dev
      └── app3-prod

This becomes extremely useful at platform scale.

33. Argo CD Projects#

Argo CD also has:

AppProject

Projects help define boundaries such as:

Which repositories can be used?
Which clusters?
Which namespaces?
Which resource types?

For example:

team-a project
   ↓
team-a Git repositories
   ↓
team-a namespaces

This provides an additional governance layer.

34. RBAC in Argo CD#

You now have another authorization layer.

Remember:

AWS IAM
Kubernetes RBAC
Argo CD RBAC

These are different systems.

Argo CD RBAC can control:

Who can view applications?
Who can sync?
Who can modify applications?
Who can access projects?

35. GitOps and Kubernetes reconciliation#

This is one of the deepest concepts in the course.

Kubernetes already does:

Desired State
      ↓
Controllers
      ↓
Actual State

GitOps adds:

Git
 ↓
Desired State
 ↓
Argo CD
 ↓
Kubernetes API
 ↓
Controllers
 ↓
Actual State

So:

GitOps

is very naturally aligned with Kubernetes' controller-based architecture.

36. Drift example#

Suppose Git:

replicas: 3

Cluster:

Everything is fine.

Someone executes:

kubectl scale deployment node-api --replicas=8

Now:

Git      = 3
Cluster  = 8

Argo:

OutOfSync

If self-healing is enabled:

8
 ↓
Argo reconciliation
 ↓
3

This is GitOps in action.

37. What if someone changes Git?#

Suppose:

Git
replicas: 3

Developer changes:

replicas: 5

and creates a pull request.

After approval:

Git
replicas: 5

Argo sees:

Desired = 5
Actual = 3

Then syncs:

3 → 5

This is a much more auditable deployment model.

38. Git history becomes deployment history#

Suppose:

Commit A
replicas: 3
 
Commit B
replicas: 5
 
Commit C
image: v2

You can trace:

Git commit
    ↓
Configuration change
    ↓
Argo synchronization
    ↓
Kubernetes deployment

This improves:

auditing
traceability
review
rollback
collaboration

39. Rollback with GitOps#

Suppose production is running:

v2

and it is broken.

Git history:

Commit A → v1
Commit B → v2

You can revert the deployment configuration:

Commit B
    ↓
revert
    ↓
Commit A state
    ↓
Argo CD
    ↓
Kubernetes
    ↓
v1

This makes Git itself part of the rollback mechanism.

40. GitOps rollback vs Kubernetes rollback#

You now have two mechanisms.

Kubernetes rollback#

kubectl rollout undo deployment/node-api

GitOps rollback#

Revert Git commit
        ↓
Argo CD
        ↓
Kubernetes

With GitOps, the Git-defined state should generally remain authoritative.

Otherwise you can create a mismatch:

Git = v2
Cluster = v1

and Argo may reconcile back to v2.

41. The "don't fight GitOps" principle#

Imagine:

Git says:
replicas = 3

You manually execute:

kubectl scale deployment node-api --replicas=10

Argo:

"Git says 3."

You:

"Make it 10."

Argo:

"Git says 3."

This creates a fight.

The correct approach is usually:

Need 10 replicas?
      ↓
Change Git
      ↓
Review
      ↓
Merge
      ↓
Argo
      ↓
10 replicas

42. GitOps repository example for your stack#

For your typical architecture:

platform-config/
│
├── apps/
│   ├── frontend/
│   └── backend/
│
├── infrastructure/
│   ├── redis/
│   └── ingress/
│
└── environments/
    │
    ├── dev/
    │
    ├── staging/
    │
    └── production/

Or Kustomize:

platform-config/
│
├── base/
│   ├── frontend/
│   ├── backend/
│   ├── redis/
│   └── ingress/
│
└── overlays/
    ├── dev/
    ├── staging/
    └── production/

43. Your production architecture with GitOps#

Now combine almost everything we've learned:

                         Git
                          │
                ┌─────────┴─────────┐
                ↓                   ↓
          Application Repo     Deployment Repo
                │                   │
                ↓                   ↓
               CI                 Argo CD
                │                   │
                ↓                   ↓
           Docker Image          Sync
                │                   │
                ↓                   ↓
             Registry           Kubernetes
                                    │
                       ┌────────────┼────────────┐
                       ↓            ↓            ↓
                    Frontend     Backend       Redis
                       │            │
                       ↓            ↓
                    Next.js      Node.js
                                    │
                             ┌──────┴──────┐
                             ↓             ↓
                          PostgreSQL      RAG

And monitoring:

Kubernetes
    ↓
Prometheus
    ↓
Grafana

Logging:

Pods
 ↓
Log collector
 ↓
Centralized logging

44. GitOps with your AI application#

Imagine your AI support system:

Next.js
   ↓
Node.js API
   ↓
Agent Orchestrator
   ↓
Retriever
   ↓
Vector DB
   ↓
LLM

You might have:

frontend Deployment
backend Deployment
retriever Deployment
worker Deployment
redis
vector DB
ingress
HPA
network policies

GitOps manages the Kubernetes configuration for all of these.

Example:

Git
│
├── frontend
├── backend
├── retriever
├── worker
├── redis
├── ingress
├── HPA
└── network policies
        │
        ↓
      Argo CD
        │
        ↓
    Kubernetes

45. GitOps advantages#

1. Auditability#

Git records:

Who
What
When

2. Reproducibility#

You can reconstruct environments from Git.

3. Drift detection#

Cluster configuration can be compared against Git.

4. Review#

Infrastructure changes can go through Pull Requests.

5. Rollback#

Git history provides a natural rollback mechanism.

6. Reduced direct cluster access#

Developers don't necessarily need unrestricted production kubectl access.

46. GitOps challenges#

GitOps isn't magic.

Potential challenges include:

Secrets#

Don't blindly commit:

password=secret123

to Git.

Use:

External Secrets
Secret Manager
Sealed Secrets
SOPS

or another appropriate secret-management strategy.

Large repositories#

Very large organizations need careful repository structure.

Database migrations#

This is especially important.

Suppose Git changes:

application v1 → v2

but database schema isn't compatible.

GitOps doesn't automatically solve migration compatibility.

You still need:

expand
 ↓
migrate
 ↓
application transition
 ↓
contract

strategies where appropriate.

47. GitOps vs CI/CD#

Don't say:

"GitOps replaces CI."

That's incorrect.

A better model:

CI
 ↓
Build/Test/Package

while:

GitOps
 ↓
Deploy/Reconcile

Together:

CI + GitOps

can form a complete delivery system.

48. Interview question: What is GitOps?#

Strong answer:

"GitOps is an operational model where Git stores the desired state of applications and infrastructure, and an automated controller continuously reconciles the Kubernetes cluster with that state. Argo CD is a popular GitOps controller for Kubernetes."

49. Interview question: What is Argo CD?#

"Argo CD is a Kubernetes continuous delivery and GitOps tool. It monitors Git repositories containing desired Kubernetes configuration, compares that configuration with the cluster, detects drift, and synchronizes the cluster according to the configured policies."

50. Interview question: What is drift?#

"Drift occurs when the actual state of the Kubernetes cluster differs from the desired state defined in Git."

Example:

Git:
replicas=3
 
Cluster:
replicas=5

That's drift.

51. Interview question: What does self-healing mean?#

"With automated reconciliation and self-healing enabled, Argo CD can detect certain out-of-band changes and synchronize the cluster back toward the Git-defined desired state."

52. Interview question: Helm + Argo CD?#

Answer:

"Helm packages and templates Kubernetes resources, while Argo CD acts as the GitOps controller that tracks the desired configuration and synchronizes the resulting resources to Kubernetes."

53. Interview question: Kustomize + Argo CD?#

Answer:

"Kustomize manages environment-specific Kubernetes customization using bases and overlays, while Argo CD monitors the Git repository and synchronizes the rendered desired state to the cluster."

54. The entire Kubernetes course in one architecture#

Warrior, you've now reached the point where the pieces connect:

                           GIT
                            │
                            ↓
                           CI
                            │
                  ┌─────────┴─────────┐
                  ↓                   ↓
                Tests             Docker Build
                                      │
                                      ↓
                                  Registry
                                      │
                                      ↓
                              Deployment Config
                                      │
                                      ↓
                                  Argo CD
                                      │
                              Reconciliation
                                      │
                                      ↓
                                Kubernetes
                                      │
             ┌────────────────────────┼─────────────────────┐
             ↓                        ↓                     ↓
        Deployment                 Service               Config
             │                        │                     │
             ↓                        ↓             ConfigMap/Secret
           Pods                    Networking
             │                        │
       ┌─────┼─────┐             Ingress
       ↓     ↓     ↓                │
      Pod   Pod   Pod               ↓
                                  Users
       │
       ├── HPA
       ├── Probes
       ├── RBAC
       ├── NetworkPolicy
       ├── Logging
       └── Monitoring
             │
             ↓
       Prometheus/Grafana

And the infrastructure:

Cloud
 │
 ├── Compute
 ├── Networking
 ├── Load Balancer
 ├── Registry
 ├── Storage
 ├── Database
 └── Identity

🧠 Chapter 31 Cheat Sheet#

GitOps
  ↓
Git = desired state
 
Argo CD
  ↓
GitOps controller
 
Sync
  ↓
Bring cluster toward Git state
 
Drift
  ↓
Git state ≠ cluster state
 
Self-heal
  ↓
Reconcile certain manual changes
 
Prune
  ↓
Remove resources no longer desired
 
Application
  ↓
Argo CD definition of a deployed application
 
ApplicationSet
  ↓
Generate many Applications
 
AppProject
  ↓
Govern Applications
 
Helm
  ↓
Package/template Kubernetes resources
 
Kustomize
  ↓
Customize Kubernetes YAML
 
Argo CD
  ↓
Deploy/reconcile Helm or Kustomize output

The most important mental model:#

                GIT
                 │
          Desired State
                 │
                 ↓
              ARGO CD
                 │
            Compare State
                 │
          ┌──────┴──────┐
          │             │
       Same          Different
          │             │
       Synced          Drift
                        │
                        ↓
                    Reconcile
                        │
                        ↓
                   Kubernetes

🎯 You have completed Chapter 31#

Only Chapter 32 — Final Production Project remains.

In the final chapter, we'll combine almost everything you've learned into one realistic system:

                    INTERNET
                       │
                       ↓
                    Ingress
                       │
              ┌────────┴────────┐
              ↓                 ↓
         Next.js Frontend    Node.js API
              │                 │
              │          ┌──────┼──────┐
              │          ↓      ↓      ↓
              │        Redis PostgreSQL Workers
              │
              └──────────┬──────────┘
                         ↓
                    AI Services
                         │
                 ┌───────┴───────┐
                 ↓               ↓
              Retriever         LLM
                 │
                 ↓
              Vector DB

And around it:

Docker
Kubernetes
Helm
Kustomize
HPA
Node Autoscaling
RBAC
NetworkPolicy
Secrets
Persistent Storage
Ingress
Prometheus
Grafana
Centralized Logging
GitHub Actions
Argo CD
AWS/GCP/Azure

Next → Chapter 32: Build a Production-Style Kubernetes Application 🚀

Finished this chapter?

Mark it as complete to track your mastery.

Previous ChapterChapter 30 — Kubernetes + CI/CD 🚀Next ChapterChapter 32 — Final Production-Style Kubernetes Project

Prev Next

In this chapter (74 sections)

You've already learned:

Git → CI → Docker → Registry → Kubernetes

Now we're going to change how Kubernetes deployments are controlled.

Instead of CI directly telling Kubernetes:

kubectl apply ...

we'll use:

Git
 ↓
Argo CD
 ↓
Kubernetes

This is called GitOps.

1. What is GitOps?#

The simplest definition:

GitOps means using Git as the source of truth for the desired state of your infrastructure and applications, with an automated system continuously reconciling Kubernetes to that state.

Remember Chapter 1?

Kubernetes works using:

Desired State
      ↓
Controller
      ↓
Actual State

GitOps takes that idea and makes Git the source of the desired state.

2. Traditional deployment#

Previously we learned:

Developer
    ↓
Git
    ↓
GitHub Actions
    ↓
Docker build
    ↓
Container Registry
    ↓
kubectl apply
    ↓
Kubernetes

For example:

kubectl apply -f deployment.yaml

The CI server directly changes the cluster.

3. GitOps deployment#

With GitOps:

Developer
    ↓
Git
    ↓
CI
    ↓
Docker Image
    ↓
Registry
 
Git
    ↓
Kubernetes manifests
    ↓
Argo CD
    ↓
Kubernetes

Notice something important:

CI doesn't necessarily need to directly deploy to Kubernetes.

Argo CD does.

4. Why is this useful?#

Imagine someone manually changes production:

kubectl scale deployment node-api --replicas=10

But Git says:

replicas: 3

Now:

Git = 3
Kubernetes = 10

The cluster has drifted from the desired configuration.

A GitOps controller can detect this difference.

Desired
3 replicas
 
Actual
10 replicas
 
        ↓
 
Drift detected

Depending on your Argo CD configuration, it can synchronize the cluster back to the Git-defined state.

5. The GitOps mental model#

This is extremely important:

                 Git
                  │
          Desired State
                  │
                  ↓
               Argo CD
                  │
          Reconciliation
                  │
                  ↓
             Kubernetes
                  │
            Actual State
                  │
                  ↓
             Pods/Services

Argo CD continuously compares:

Desired state
      VS
Actual state

6. What is Argo CD?#

Argo CD is a GitOps continuous delivery tool for Kubernetes.

Its primary job is:

Git repository
      ↓
Read Kubernetes configuration
      ↓
Compare with cluster
      ↓
Synchronize
      ↓
Kubernetes

It supports configurations such as:

plain Kubernetes YAML
Kustomize
Helm
Jsonnet
other supported configuration sources

7. Argo CD is not CI#

This distinction is critical.

CI#

Usually handles:

Build
Test
Lint
Security
Docker image

Argo CD#

Handles:

Deployment
Synchronization
Drift detection
Reconciliation

So:

CI
 ↓
Build artifact
 
Argo CD
 ↓
Deploy artifact/configuration

8. Complete GitOps architecture#

A modern pipeline can look like:

                    Developer
                        │
                        ↓
                       Git
                        │
             ┌──────────┴──────────┐
             ↓                     ↓
        Application repo       Deployment repo
             │                     │
             ↓                     ↓
            CI                  Argo CD
             │                     │
             ↓                     ↓
       Docker Image           Kubernetes
             │                     │
             ↓                     ↓
          Registry              Pods

There are different repository structures, but the separation is useful to understand.

9. Two Git repositories#

A common pattern:

Repository 1 — Application#

node-api/
├── src/
├── package.json
├── Dockerfile
└── tests/

Repository 2 — Deployment#

k8s-config/
├── base/
└── overlays/
    ├── dev/
    ├── staging/
    └── production/

Then:

Application repo
       ↓
CI
       ↓
Docker image
       ↓
Registry
 
Deployment repo
       ↓
Argo CD
       ↓
Kubernetes

10. Why separate repositories?#

Because application code and infrastructure configuration have different purposes.

Application repo:

"How does my application work?"

Deployment repo:

"How should this application run?"

For example:

replicas: 5

is deployment configuration.

While:

app.get("/users")

is application code.

11. But you don't have to use two repositories#

GitOps can also use a single repository.

For example:

my-project/
│
├── src/
├── Dockerfile
│
└── k8s/
    ├── base/
    └── overlays/

Argo CD watches:

/k8s

This is perfectly valid.

The right structure depends on team size, release model, ownership, and organizational needs.

12. Git becomes the source of truth#

Suppose Git contains:

replicas: 3

Argo CD sees:

Git = 3
Cluster = 3

Everything is synchronized.

Now someone changes the cluster manually:

kubectl scale deployment node-api --replicas=7

Now:

Git = 3
Cluster = 7

Argo CD sees:

DRIFT

If automated sync/self-healing is configured, Argo CD can reconcile the cluster back toward Git's desired state.

13. Desired vs actual state#

This is the heart of GitOps.

              Git
               │
               ↓
        Desired State
          replicas=3
               │
               ↓
            Argo CD
               │
               ↓
       Kubernetes Cluster
               │
               ↓
         Actual State
          replicas=3

When they differ:

Desired = 3
Actual  = 7
 
      ↓
 
     DRIFT

Argo CD can synchronize.

14. Argo CD Application#

Argo CD introduces an important object:

Application

An Argo CD Application tells Argo:

"This Git repository/path represents the desired state for this Kubernetes application."

Conceptually:

Argo CD Application
 
Repository:
github.com/company/platform
 
Path:
k8s/overlays/production
 
Destination:
production-cluster

15. Example Argo CD Application#

A simplified Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
 
metadata:
  name: node-api
 
spec:
  project: default
 
  source:
    repoURL: https://github.com/example/k8s-config.git
    targetRevision: main
    path: overlays/production
 
  destination:
    server: https://kubernetes.default.svc
    namespace: production
 
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Let's understand this piece by piece.

16. `source`#

source:
  repoURL: https://github.com/example/k8s-config.git
  targetRevision: main
  path: overlays/production

This says:

Git repository
     ↓
main branch
     ↓
overlays/production

That's where Argo CD gets the desired Kubernetes configuration.

17. `destination`#

destination:
  server: https://kubernetes.default.svc
  namespace: production

This specifies where the application should be deployed.

In a multi-cluster environment, the destination can identify a particular Kubernetes cluster.

18. `syncPolicy`#

This controls synchronization behavior.

For example:

syncPolicy:
  automated:
    prune: true
    selfHeal: true

This enables automated reconciliation behavior.

19. What is `selfHeal`?#

Imagine Git says:

replicas: 3

Someone manually changes:

replicas = 10

Argo CD detects:

Git      = 3
Cluster  = 10

With self-healing enabled, Argo CD can restore the Git-defined state.

Conceptually:

Manual change
     ↓
Drift
     ↓
Argo CD detects
     ↓
Reconcile
     ↓
Back toward desired state

20. What is `prune`?#

Suppose Git originally contains:

deployment.yaml
service.yaml
configmap.yaml

Then someone removes:

configmap.yaml

from Git.

Without appropriate pruning behavior, the old ConfigMap may remain in the cluster.

With pruning enabled:

Git
 ↓
ConfigMap removed
 ↓
Argo CD detects resource no longer desired
 ↓
Prune
 ↓
ConfigMap removed from cluster

Be careful with pruning in production.

You want Git to be authoritative, but accidental Git changes can have real consequences.

21. Sync#

Argo CD uses the concept of sync.

If:

Git desired state
        ≠
Cluster actual state

the application is out of sync.

Sync means:

Bring cluster toward Git-defined desired state.

22. Argo CD UI#

Argo CD provides a web UI where you can see:

Applications
Clusters
Resources
Sync status
Health
History
Events

You might see:

node-api
 
SYNC: Synced
HEALTH: Healthy

Or:

SYNC: OutOfSync
HEALTH: Degraded

This is extremely useful operationally.

23. Sync status vs health#

These are different.

Sync status#

Answers:

Does the cluster match the Git configuration?

Possible conceptual state:

Synced
OutOfSync

Health#

Answers:

Is the application/resource functioning according to Argo CD's health assessment?

Conceptually:

Healthy
Progressing
Degraded
Missing
Unknown

You can have:

Synced + Degraded

For example:

Git configuration = correctly applied
but
Pods = crashing

24. Very important distinction#

Synced

does not necessarily mean:

Application is healthy.

It means the cluster matches the desired configuration.

Example:

Deployment says:
 
image: broken-image:v5

Argo CD successfully applies it.

So:

SYNC = Synced
HEALTH = Degraded

because the Pods may fail to start.

25. GitOps deployment flow#

Let's say you release:

node-api v2

Developer changes:

image:
  tag: "v2"

Then:

git commit
      ↓
git push
      ↓
Argo CD detects change
      ↓
OutOfSync
      ↓
Sync
      ↓
Kubernetes Deployment
      ↓
Rolling Update
      ↓
New Pods
      ↓
Readiness
      ↓
Healthy

26. Where does CI fit?#

CI still builds the image.

For example:

Developer
   ↓
Git
   ↓
GitHub Actions
   ↓
Tests
   ↓
Docker Build
   ↓
Registry

Then CI needs to update the deployment configuration.

For example:

image:
  tag: "a8f72c1"

A commit is pushed to the deployment repository.

Then:

Deployment Git
     ↓
Argo CD
     ↓
Kubernetes

This creates a clean separation.

27. Image update automation#

Imagine CI builds:

node-api:a8f72c1

Then it updates:

images:
  - name: node-api
    newTag: a8f72c1

and commits that change.

Now:

Git
 ↓
new image reference
 ↓
Argo CD
 ↓
Kubernetes

The deployment itself becomes Git-driven.

28. Kustomize + Argo CD#

This is particularly relevant because Chapter 26 covered Kustomize.

Repository:

k8s/
│
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
│
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    │
    ├── staging/
    │   └── kustomization.yaml
    │
    └── production/
        └── kustomization.yaml

Argo CD can point to:

overlays/production

Argo understands the Kustomize configuration and generates the desired manifests.

29. Helm + Argo CD#

Argo CD can also deploy Helm charts.

Repository:

helm/
└── node-api/
    ├── Chart.yaml
    ├── values.yaml
    └── templates/

Argo CD points to:

helm/node-api

and can supply appropriate Helm values.

So:

Helm
   ↓
Kubernetes manifests
   ↓
Argo CD
   ↓
Kubernetes

30. Kustomize vs Helm with Argo#

Both work.

Helm#

Chart
 +
Values
 ↓
Rendered resources
 ↓
Argo CD

Kustomize#

Base
 +
Overlay
 ↓
Rendered resources
 ↓
Argo CD

Argo CD becomes the GitOps controller responsible for synchronizing the resulting desired state.

31. Multi-environment GitOps#

Suppose:

Development
Staging
Production

Repository:

k8s/
│
├── base/
│
└── overlays/
    ├── dev/
    ├── staging/
    └── production/

Then create Argo Applications:

node-api-dev
node-api-staging
node-api-production

Each points to:

different path

For example:

node-api-dev
    ↓
overlays/dev
 
node-api-staging
    ↓
overlays/staging
 
node-api-production
    ↓
overlays/production

32. ApplicationSet#

Imagine you have:

20 applications
3 environments

Creating every Argo Application manually can become repetitive.

Argo CD provides ApplicationSet for generating Applications from templates.

Conceptually:

ApplicationSet
      │
      ├── app1-dev
      ├── app1-prod
      ├── app2-dev
      ├── app2-prod
      ├── app3-dev
      └── app3-prod

This becomes extremely useful at platform scale.

33. Argo CD Projects#

Argo CD also has:

AppProject

Projects help define boundaries such as:

Which repositories can be used?
Which clusters?
Which namespaces?
Which resource types?

For example:

team-a project
   ↓
team-a Git repositories
   ↓
team-a namespaces

This provides an additional governance layer.

34. RBAC in Argo CD#

You now have another authorization layer.

Remember:

AWS IAM
Kubernetes RBAC
Argo CD RBAC

These are different systems.

Argo CD RBAC can control:

Who can view applications?
Who can sync?
Who can modify applications?
Who can access projects?

35. GitOps and Kubernetes reconciliation#

This is one of the deepest concepts in the course.

Kubernetes already does:

Desired State
      ↓
Controllers
      ↓
Actual State

GitOps adds:

Git
 ↓
Desired State
 ↓
Argo CD
 ↓
Kubernetes API
 ↓
Controllers
 ↓
Actual State

So:

GitOps

is very naturally aligned with Kubernetes' controller-based architecture.

36. Drift example#

Suppose Git:

replicas: 3

Cluster:

Everything is fine.

Someone executes:

kubectl scale deployment node-api --replicas=8

Now:

Git      = 3
Cluster  = 8

Argo:

OutOfSync

If self-healing is enabled:

8
 ↓
Argo reconciliation
 ↓
3

This is GitOps in action.

37. What if someone changes Git?#

Suppose:

Git
replicas: 3

Developer changes:

replicas: 5

and creates a pull request.

After approval:

Git
replicas: 5

Argo sees:

Desired = 5
Actual = 3

Then syncs:

3 → 5

This is a much more auditable deployment model.

38. Git history becomes deployment history#

Suppose:

Commit A
replicas: 3
 
Commit B
replicas: 5
 
Commit C
image: v2

You can trace:

Git commit
    ↓
Configuration change
    ↓
Argo synchronization
    ↓
Kubernetes deployment

This improves:

auditing
traceability
review
rollback
collaboration

39. Rollback with GitOps#

Suppose production is running:

v2

and it is broken.

Git history:

Commit A → v1
Commit B → v2

You can revert the deployment configuration:

Commit B
    ↓
revert
    ↓
Commit A state
    ↓
Argo CD
    ↓
Kubernetes
    ↓
v1

This makes Git itself part of the rollback mechanism.

40. GitOps rollback vs Kubernetes rollback#

You now have two mechanisms.

Kubernetes rollback#

kubectl rollout undo deployment/node-api

GitOps rollback#

Revert Git commit
        ↓
Argo CD
        ↓
Kubernetes

With GitOps, the Git-defined state should generally remain authoritative.

Otherwise you can create a mismatch:

Git = v2
Cluster = v1

and Argo may reconcile back to v2.

41. The "don't fight GitOps" principle#

Imagine:

Git says:
replicas = 3

You manually execute:

kubectl scale deployment node-api --replicas=10

Argo:

"Git says 3."

You:

"Make it 10."

Argo:

"Git says 3."

This creates a fight.

The correct approach is usually:

Need 10 replicas?
      ↓
Change Git
      ↓
Review
      ↓
Merge
      ↓
Argo
      ↓
10 replicas

42. GitOps repository example for your stack#

For your typical architecture:

platform-config/
│
├── apps/
│   ├── frontend/
│   └── backend/
│
├── infrastructure/
│   ├── redis/
│   └── ingress/
│
└── environments/
    │
    ├── dev/
    │
    ├── staging/
    │
    └── production/

Or Kustomize:

platform-config/
│
├── base/
│   ├── frontend/
│   ├── backend/
│   ├── redis/
│   └── ingress/
│
└── overlays/
    ├── dev/
    ├── staging/
    └── production/

43. Your production architecture with GitOps#

Now combine almost everything we've learned:

                         Git
                          │
                ┌─────────┴─────────┐
                ↓                   ↓
          Application Repo     Deployment Repo
                │                   │
                ↓                   ↓
               CI                 Argo CD
                │                   │
                ↓                   ↓
           Docker Image          Sync
                │                   │
                ↓                   ↓
             Registry           Kubernetes
                                    │
                       ┌────────────┼────────────┐
                       ↓            ↓            ↓
                    Frontend     Backend       Redis
                       │            │
                       ↓            ↓
                    Next.js      Node.js
                                    │
                             ┌──────┴──────┐
                             ↓             ↓
                          PostgreSQL      RAG

And monitoring:

Kubernetes
    ↓
Prometheus
    ↓
Grafana

Logging:

Pods
 ↓
Log collector
 ↓
Centralized logging

44. GitOps with your AI application#

Imagine your AI support system:

Next.js
   ↓
Node.js API
   ↓
Agent Orchestrator
   ↓
Retriever
   ↓
Vector DB
   ↓
LLM

You might have:

frontend Deployment
backend Deployment
retriever Deployment
worker Deployment
redis
vector DB
ingress
HPA
network policies

GitOps manages the Kubernetes configuration for all of these.

Example:

Git
│
├── frontend
├── backend
├── retriever
├── worker
├── redis
├── ingress
├── HPA
└── network policies
        │
        ↓
      Argo CD
        │
        ↓
    Kubernetes

45. GitOps advantages#

1. Auditability#

Git records:

Who
What
When

2. Reproducibility#

You can reconstruct environments from Git.

3. Drift detection#

Cluster configuration can be compared against Git.

4. Review#

Infrastructure changes can go through Pull Requests.

5. Rollback#

Git history provides a natural rollback mechanism.

6. Reduced direct cluster access#

Developers don't necessarily need unrestricted production kubectl access.

46. GitOps challenges#

GitOps isn't magic.

Potential challenges include:

Secrets#

Don't blindly commit:

password=secret123

to Git.

Use:

External Secrets
Secret Manager
Sealed Secrets
SOPS

or another appropriate secret-management strategy.

Large repositories#

Very large organizations need careful repository structure.

Database migrations#

This is especially important.

Suppose Git changes:

application v1 → v2

but database schema isn't compatible.

GitOps doesn't automatically solve migration compatibility.

You still need:

expand
 ↓
migrate
 ↓
application transition
 ↓
contract

strategies where appropriate.

47. GitOps vs CI/CD#

Don't say:

"GitOps replaces CI."

That's incorrect.

A better model:

CI
 ↓
Build/Test/Package

while:

GitOps
 ↓
Deploy/Reconcile

Together:

CI + GitOps

can form a complete delivery system.

48. Interview question: What is GitOps?#

Strong answer:

"GitOps is an operational model where Git stores the desired state of applications and infrastructure, and an automated controller continuously reconciles the Kubernetes cluster with that state. Argo CD is a popular GitOps controller for Kubernetes."

49. Interview question: What is Argo CD?#

"Argo CD is a Kubernetes continuous delivery and GitOps tool. It monitors Git repositories containing desired Kubernetes configuration, compares that configuration with the cluster, detects drift, and synchronizes the cluster according to the configured policies."

50. Interview question: What is drift?#

"Drift occurs when the actual state of the Kubernetes cluster differs from the desired state defined in Git."

Example:

Git:
replicas=3
 
Cluster:
replicas=5

That's drift.

51. Interview question: What does self-healing mean?#

"With automated reconciliation and self-healing enabled, Argo CD can detect certain out-of-band changes and synchronize the cluster back toward the Git-defined desired state."

52. Interview question: Helm + Argo CD?#

Answer:

"Helm packages and templates Kubernetes resources, while Argo CD acts as the GitOps controller that tracks the desired configuration and synchronizes the resulting resources to Kubernetes."

53. Interview question: Kustomize + Argo CD?#

Answer:

"Kustomize manages environment-specific Kubernetes customization using bases and overlays, while Argo CD monitors the Git repository and synchronizes the rendered desired state to the cluster."

54. The entire Kubernetes course in one architecture#

Warrior, you've now reached the point where the pieces connect:

                           GIT
                            │
                            ↓
                           CI
                            │
                  ┌─────────┴─────────┐
                  ↓                   ↓
                Tests             Docker Build
                                      │
                                      ↓
                                  Registry
                                      │
                                      ↓
                              Deployment Config
                                      │
                                      ↓
                                  Argo CD
                                      │
                              Reconciliation
                                      │
                                      ↓
                                Kubernetes
                                      │
             ┌────────────────────────┼─────────────────────┐
             ↓                        ↓                     ↓
        Deployment                 Service               Config
             │                        │                     │
             ↓                        ↓             ConfigMap/Secret
           Pods                    Networking
             │                        │
       ┌─────┼─────┐             Ingress
       ↓     ↓     ↓                │
      Pod   Pod   Pod               ↓
                                  Users
       │
       ├── HPA
       ├── Probes
       ├── RBAC
       ├── NetworkPolicy
       ├── Logging
       └── Monitoring
             │
             ↓
       Prometheus/Grafana

And the infrastructure:

Cloud
 │
 ├── Compute
 ├── Networking
 ├── Load Balancer
 ├── Registry
 ├── Storage
 ├── Database
 └── Identity

🧠 Chapter 31 Cheat Sheet#

GitOps
  ↓
Git = desired state
 
Argo CD
  ↓
GitOps controller
 
Sync
  ↓
Bring cluster toward Git state
 
Drift
  ↓
Git state ≠ cluster state
 
Self-heal
  ↓
Reconcile certain manual changes
 
Prune
  ↓
Remove resources no longer desired
 
Application
  ↓
Argo CD definition of a deployed application
 
ApplicationSet
  ↓
Generate many Applications
 
AppProject
  ↓
Govern Applications
 
Helm
  ↓
Package/template Kubernetes resources
 
Kustomize
  ↓
Customize Kubernetes YAML
 
Argo CD
  ↓
Deploy/reconcile Helm or Kustomize output

The most important mental model:#

                GIT
                 │
          Desired State
                 │
                 ↓
              ARGO CD
                 │
            Compare State
                 │
          ┌──────┴──────┐
          │             │
       Same          Different
          │             │
       Synced          Drift
                        │
                        ↓
                    Reconcile
                        │
                        ↓
                   Kubernetes

🎯 You have completed Chapter 31#

Only Chapter 32 — Final Production Project remains.

In the final chapter, we'll combine almost everything you've learned into one realistic system:

                    INTERNET
                       │
                       ↓
                    Ingress
                       │
              ┌────────┴────────┐
              ↓                 ↓
         Next.js Frontend    Node.js API
              │                 │
              │          ┌──────┼──────┐
              │          ↓      ↓      ↓
              │        Redis PostgreSQL Workers
              │
              └──────────┬──────────┘
                         ↓
                    AI Services
                         │
                 ┌───────┴───────┐
                 ↓               ↓
              Retriever         LLM
                 │
                 ↓
              Vector DB

And around it:

Docker
Kubernetes
Helm
Kustomize
HPA
Node Autoscaling
RBAC
NetworkPolicy
Secrets
Persistent Storage
Ingress
Prometheus
Grafana
Centralized Logging
GitHub Actions
Argo CD
AWS/GCP/Azure

Next → Chapter 32: Build a Production-Style Kubernetes Application 🚀

Finished this chapter?

Mark it as complete to track your mastery.

Previous ChapterChapter 30 — Kubernetes + CI/CD 🚀Next ChapterChapter 32 — Final Production-Style Kubernetes Project

1. What is GitOps?#

2. Traditional deployment#

3. GitOps deployment#

4. Why is this useful?#

5. The GitOps mental model#

6. What is Argo CD?#

7. Argo CD is not CI#

CI#

Argo CD#

8. Complete GitOps architecture#

9. Two Git repositories#

Repository 1 — Application#

Repository 2 — Deployment#

10. Why separate repositories?#

11. But you don't have to use two repositories#

12. Git becomes the source of truth#

13. Desired vs actual state#

14. Argo CD Application#

15. Example Argo CD Application#

16. source#

17. destination#

18. syncPolicy#

19. What is selfHeal?#

20. What is prune?#

21. Sync#

22. Argo CD UI#

23. Sync status vs health#

Sync status#

Health#

24. Very important distinction#

25. GitOps deployment flow#

26. Where does CI fit?#

27. Image update automation#

28. Kustomize + Argo CD#

29. Helm + Argo CD#

30. Kustomize vs Helm with Argo#

Helm#

Kustomize#

31. Multi-environment GitOps#

32. ApplicationSet#

33. Argo CD Projects#

34. RBAC in Argo CD#

35. GitOps and Kubernetes reconciliation#

36. Drift example#

37. What if someone changes Git?#

38. Git history becomes deployment history#

39. Rollback with GitOps#

40. GitOps rollback vs Kubernetes rollback#

Kubernetes rollback#

GitOps rollback#

41. The "don't fight GitOps" principle#

42. GitOps repository example for your stack#

43. Your production architecture with GitOps#

44. GitOps with your AI application#

45. GitOps advantages#

1. Auditability#

2. Reproducibility#

3. Drift detection#

4. Review#

5. Rollback#

6. Reduced direct cluster access#

46. GitOps challenges#

Secrets#

Large repositories#

Database migrations#

47. GitOps vs CI/CD#

48. Interview question: What is GitOps?#

49. Interview question: What is Argo CD?#

50. Interview question: What is drift?#

51. Interview question: What does self-healing mean?#

52. Interview question: Helm + Argo CD?#

53. Interview question: Kustomize + Argo CD?#

54. The entire Kubernetes course in one architecture#

🧠 Chapter 31 Cheat Sheet#

The most important mental model:#

🎯 You have completed Chapter 31#

Finished this chapter?

1. What is GitOps?#

2. Traditional deployment#

3. GitOps deployment#

16. `source`#

17. `destination`#

18. `syncPolicy`#

19. What is `selfHeal`?#

20. What is `prune`?#

16. `source`#

17. `destination`#

18. `syncPolicy`#

19. What is `selfHeal`?#

20. What is `prune`?#