[Ep.2] [GitOps와 Argo CD의 기초 #2] GitOps의 핵심 원칙과 Kubernetes에서의 활용법

🔹 GitOps의 핵심 원칙

GitOps는 단순히 Git을 활용한 배포 방식이 아니라, Kubernetes에서 CI/CD를 자동화하는 운영 모델입니다.
GitOps 방식이 효과적으로 작동하려면 반드시 4가지 핵심 원칙을 따라야 합니다.

✅ 1. 선언적(Declarative) 구성

GitOps에서는 모든 인프라와 애플리케이션을 선언적(Declarative) 방식으로 정의해야 합니다.

• 선언적 방식이란, "이렇게 되어야 한다" 라는 최종 상태를 정의하는 방식입니다.
• Kubernetes의 Deployment, Service, ConfigMap, Secret 등 모든 리소스를 YAML 파일로 선언합니다.
• Git 저장소에 선언된 YAML 파일을 변경하면, 자동으로 Kubernetes 클러스터가 업데이트됩니다.

# 선언적 방식 예제 (Deployment 정의)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
spec:
  replicas: 3  # 항상 3개의 Pod을 유지하도록 선언
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v1.0

 

🔹 명령형 vs 선언형 비교

비교 항목 명령형 (Imperative) 선언형 (Declarative)

방식	kubectl 명령어 직접 실행	YAML 파일로 원하는 상태 선언
변경 적용	운영자가 직접 실행해야 적용됨	Git에서 변경하면 자동 적용
롤백	이전 상태를 기억하기 어려움	Git에서 특정 커밋으로 쉽게 롤백 가능
일관성	사람이 직접 실행해야 하므로 불안정	Git에 저장된 상태와 항상 일치

GitOps에서는 Kubernetes의 선언적 구성 방식을 활용하여 Git의 변경 사항이 곧 운영 환경의 변경 사항이 되도록 합니다.

---

✅ 2. Git을 단일 신뢰 원천(Single Source of Truth)으로 활용

GitOps에서는 Git 저장소가 운영 환경의 단일 신뢰 원천이 됩니다.
즉, Git 저장소에 저장된 상태가 Kubernetes 클러스터의 현재 상태와 항상 일치해야 합니다.

🔹 GitOps에서 Git의 역할

• Git에 저장된 모든 변경 사항이 배포와 연동됨
• Git의 커밋 로그를 통해 변경 이력을 추적할 수 있음
• Git 브랜치 및 PR(Pull Request) 워크플로우를 활용하여 배포 안정성을 강화

# GitOps 방식의 배포 예제
git add .
git commit -m "Update deployment to v1.1"
git push origin main

• GitOps를 활용하면 git push만으로 배포가 자동화됩니다.
• 운영자는 kubectl 명령을 직접 실행할 필요가 없습니다.
• GitOps 도구(예: Argo CD)가 자동으로 Git 상태를 감지하고 Kubernetes 클러스터를 업데이트합니다.

---

✅ 3. 자동 동기화(Automated Syncing) 및 지속적인 검증(Continuous Reconciliation)

GitOps 방식에서는 Kubernetes 클러스터가 Git 저장소의 상태와 항상 동기화(Automated Sync)되도록 보장해야 합니다.
이를 위해 GitOps 도구(Argo CD 등)는 Git 저장소를 지속적으로 감시하고, 변경 사항이 감지되면 자동으로 Kubernetes 환경을 업데이트합니다.

 

🔹 GitOps 자동 동기화 과정
1️⃣ 운영자가 Git 저장소에서 YAML 파일 변경 후 커밋(Push)
2️⃣ GitOps 도구(Argo CD)가 Git 저장소의 변경 사항을 감지
3️⃣ 변경된 YAML 파일을 Kubernetes 클러스터에 자동 적용
4️⃣ Kubernetes 클러스터가 선언된 상태와 일치하도록 조정

syncPolicy:
  automated:
    prune: true  # 불필요한 리소스 자동 삭제
    selfHeal: true  # Kubernetes 리소스 변경 시 원래 상태로 복구

• prune: true → Git에 없는 리소스는 자동 삭제
• selfHeal: true → Kubernetes 리소스가 수동 변경되면 자동 복구

자동 동기화를 통해 Git과 Kubernetes 상태가 **불일치한 경우 자동으로 복구(Self-Healing)**됩니다.

---

✅ 4. 감사 가능(Auditability) 및 손쉬운 롤백(Rollback)

GitOps의 가장 큰 장점 중 하나는 Git 커밋 히스토리를 활용하여 배포 이력을 추적하고, 쉽게 롤백할 수 있다는 점입니다.

🔹 GitOps 방식의 롤백 원리

• Git의 커밋 히스토리를 활용하면 특정 시점의 설정을 언제든지 복구할 수 있습니다.
• 문제가 발생하면 이전 커밋으로 되돌리는 것만으로 Kubernetes 클러스터를 원래 상태로 복구할 수 있습니다.

# GitOps 방식의 롤백 예제
git revert HEAD  # 가장 최근 변경 사항 롤백
git push origin main  # 변경 사항을 다시 Git에 적용

Argo CD 같은 GitOps 도구는 자동으로 이전 상태로 복구하며,
운영자는 추가적인 kubectl 명령어 실행 없이 Git 커밋만으로 롤백이 가능합니다.

---

🔹 GitOps의 실전 활용: Kubernetes에서 어떻게 적용할까?

GitOps의 4가지 원칙을 Kubernetes 환경에서 어떻게 실현할 수 있는지 살펴보겠습니다.

✅ GitOps 활용을 위한 필수 요소

요소 역할

Git 저장소	모든 배포 및 인프라 설정을 저장하는 곳
GitOps 도구 (Argo CD)	Git과 Kubernetes의 동기화를 담당
Kubernetes 클러스터	GitOps를 적용할 실제 환경

✅ GitOps 방식의 Kubernetes 배포 흐름

1️⃣ Git 저장소에서 선언적 YAML 작성
2️⃣ Argo CD가 Git 변경 사항을 감지하여 자동 동기화 수행
3️⃣ Kubernetes 클러스터가 Git과 일치하는 상태로 유지

# GitOps를 활용한 배포 과정
git add deployment.yaml
git commit -m "Update my-app to v1.2"
git push origin main

Git에 푸시하는 것만으로 배포, 변경, 롤백이 자동으로 수행됩니다.

---

🔹 결론: 이번 글에서 배운 핵심 내용 정리

🟢 GitOps는 선언적 구성, Git 기반 변경 관리, 자동 동기화, 감사 가능성을 핵심 원칙으로 삼음
🟢 Git을 단일 신뢰 원천으로 사용하여 Kubernetes 상태를 자동으로 동기화
🟢 Argo CD 같은 GitOps 도구를 활용하면 배포를 자동화하고, Kubernetes 환경을 항상 Git과 일치하도록 유지 가능
🟢 Git 커밋 기반 롤백이 가능하여 운영 부담을 줄이고 신뢰성을 높임