Fully Automating Kubernetes Deployments with GitOps and Argo CD

What Is GitOps

GitOps is a methodology that uses a Git repository as the "single source of truth" to manage infrastructure and application deployments. The core idea is Git commit = automated deployment.

Installing Argo CD

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 초기 비밀번호 확인
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

Repository Structure

gitops-repo/
├── apps/
│   └── my-app/
│       ├── base/
│       │   ├── deployment.yaml
│       │   └── kustomization.yaml
│       └── overlays/
│           ├── staging/
│           └── prod/
└── argocd/
    └── applications/

Defining an Argo CD Application

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app-prod
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/my-org/gitops-repo
    targetRevision: main
    path: apps/my-app/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true      # Git에서 삭제된 리소스 자동 제거
      selfHeal: true   # 클러스터 직접 변경 시 자동 복원

Per-Environment Kustomize Config

# overlays/prod/kustomization.yaml
resources:
- ../../base

images:
- name: my-app
  newTag: v1.2.3

patches:
- path: patch-replicas.yaml

Wiring Up the CI/CD Pipeline

- name: Update GitOps Repo
  run: |
    git clone https://github.com/my-org/gitops-repo
    cd gitops-repo/apps/my-app/overlays/prod
    kustomize edit set image my-app=my-registry/my-app:${{ github.sha }}
    git add -A
    git commit -m "chore: update to ${{ github.sha }}"
    git push

GitOps is more than deployment automation — it is a paradigm shift in how you operate. You can fully reconstruct everything happening in the cluster from Git history alone.

Secret Management — GitOps's Hardest Problem

"Put everything in Git" is the principle, but you must not commit passwords and keys in plaintext. Common approaches:

When You Scale — App of Apps & Multi-Cluster

Once you have dozens of applications, you manage Argo CD Applications with another Application using the App of Apps pattern, or templatize declarations with ApplicationSet. Multiple clusters (staging/prod/per-region) can also be managed as targets from a single Argo CD instance.

Drift Detection and Rollback

selfHeal: true automatically restores Git state even if someone changes the cluster directly with kubectl edit. Rollback during an incident is simply a Git revert — revert to a previous commit and Argo CD syncs. Deployment history = Git history is GitOps's biggest advantage.

Diagnostic Decision Table by Symptom

Practical diagnostic paths for situations you actually hit when running Argo CD.

FAQ

Q. Argo CD or Flux? Argo CD is strong on UI, multi-tenancy, and App of Apps; Flux is strong as a lightweight GitOps toolkit combination. If dashboards and RBAC matter, Argo CD has a lower barrier to entry.

Q. Isn't enabling selfHeal dangerous? Emergency manual patches can be reverted immediately, so ops policy must already enforce "changes always go through Git." That discipline is also the core of GitOps.

Editor's Note — From the Field

What breaks most often in early GitOps adoption is not Argo CD but people's habits. When things get urgent, someone kubectl edits directly, and at that moment Git and the cluster drift apart. Turn on selfHeal and those changes auto-rollback — then complaints flood in: "why did my fix disappear?" In the end GitOps is not a tool; it only works once the discipline "every change goes through a PR" is established. The tool is just the mechanism that enforces that discipline.

References

• Argo CD official docs
• OpenGitOps — GitOps principles