GitOps란
GitOps는 Git 리포지토리를 "단일 진실의 원천"으로 사용해 인프라와 애플리케이션 배포를 관리하는 방법론입니다. Git 커밋 = 배포 자동화가 핵심입니다.
ArgoCD 설치
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리포지토리 구조
gitops-repo/
├── apps/
│ └── my-app/
│ ├── base/
│ │ ├── deployment.yaml
│ │ └── kustomization.yaml
│ └── overlays/
│ ├── staging/
│ └── prod/
└── argocd/
└── applications/ArgoCD 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 # 클러스터 직접 변경 시 자동 복원Kustomize 환경별 설정
# overlays/prod/kustomization.yaml
resources:
- ../../base
images:
- name: my-app
newTag: v1.2.3
patches:
- path: patch-replicas.yamlCI/CD 파이프라인 연동
- 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 pushGitOps는 배포 자동화를 넘어 운영 방식의 패러다임 전환입니다. 클러스터에서 무슨 일이 벌어지는지 Git 히스토리만으로 완전히 추적할 수 있게 됩니다.
시크릿 관리 — GitOps의 최대 난제
"모든 걸 Git에"가 원칙이지만 비밀번호·키를 평문으로 커밋하면 안 됩니다. 대표적 해법:
| 방식 | 특징 |
|---|---|
| Sealed Secrets | 공개키로 암호화해 Git에 저장, 클러스터에서만 복호화 |
| External Secrets Operator | Vault/AWS Secrets Manager 등 외부 저장소 참조 |
| SOPS + age/KMS | 파일 단위 암호화, 리뷰 가능 |
규모가 커지면 — App of Apps & 멀티클러스터
애플리케이션이 수십 개가 되면 ArgoCD Application을 또 다른 Application으로 관리하는 App of Apps 패턴이나 ApplicationSet으로 선언을 템플릿화합니다. 여러 클러스터(스테이징/프로드/리전별)도 단일 ArgoCD에서 타깃으로 관리할 수 있습니다.
드리프트 감지와 롤백
selfHeal: true는 클러스터에서 누군가 kubectl edit로 직접 바꿔도 Git 상태로 자동 복원합니다. 장애 시 롤백은 단순히 Git revert — 이전 커밋으로 되돌리면 ArgoCD가 동기화합니다. 배포 이력=Git 히스토리라는 GitOps의 가장 큰 장점입니다.
장애 증상별 진단 분기표
ArgoCD 운영에서 실제로 마주치는 상황별 진단 경로입니다.
| 증상 | 먼저 확인 | 대응 |
|---|---|---|
| OutOfSync가 고착됨 | argocd app diff로 실제 차이 확인 | 컨트롤러가 아닌 다른 주체(HPA·웹훅·오퍼레이터)가 필드를 수정 중이면 ignoreDifferences 등록 |
| Sync는 성공인데 파드가 안 뜸 | Application 상태가 아닌 파드 이벤트(kubectl describe pod) | ArgoCD는 매니페스트 적용까지만 책임 — 이미지 풀 실패·리소스 부족은 K8s 층 문제 |
| 드리프트가 반복 감지됨 | 누가 수동 kubectl 변경을 하는지 감사 로그 | selfHeal 활성화 전에 수동 변경 관행부터 차단 (원인 제거 없이 selfHeal은 싸움만 남) |
| Git 푸시 후 반영이 늦다 | 폴링 주기(기본 3분) vs 웹훅 설정 | 웹훅 등록으로 즉시 동기화, 폴링은 백업 수단으로 |
| 시크릿 변경이 반영 안 됨 | External Secrets/SealedSecrets 컨트롤러 로그 | 시크릿 도구는 ArgoCD 밖의 별도 컨트롤러 — 각자의 동기화 주기 확인 |
자주 묻는 질문 (FAQ)
Q. ArgoCD와 Flux 중 무엇을 쓰나요? UI·멀티테넌시·App of Apps가 강점인 ArgoCD, 경량·GitOps 툴킷 조합이 강점인 Flux. 대시보드와 RBAC가 중요하면 ArgoCD가 진입장벽이 낮습니다.
Q. selfHeal을 켜면 위험하지 않나요? 긴급 수동 패치가 즉시 되돌려질 수 있으니, 운영 정책상 "변경은 항상 Git을 통해서만" 한다는 규율이 전제되어야 합니다. 그게 GitOps의 핵심이기도 합니다.
에디터 노트 — 현장에서는
GitOps 도입 초기에 가장 자주 깨지는 건 ArgoCD가 아니라 '사람의 습관'입니다. 급하면 누군가 kubectl edit로 직접 고치고, 그 순간 Git과 클러스터가 어긋납니다. selfHeal을 켜자 그 변경이 자동 롤백돼 '왜 내 수정이 사라지냐'는 항의가 빗발쳤죠. 결국 GitOps는 도구가 아니라 '변경은 무조건 PR로'라는 규율이 정착돼야 굴러갑니다. 도구는 그 규율을 강제하는 장치일 뿐입니다.
참고 자료
이 글은 AI 에이전트가 자료 조사와 1차 초안 작성을 담당하고, 사람 편집자가 사실관계·출처·톤과 맥락을 검토한 뒤 발행했습니다. 환경(OS·버전)에 따라 결과가 다를 수 있으니 적용 전 공식 문서를 함께 확인하세요. 오류를 발견하시면 이메일로 제보해 주세요 — 확인 후 신속히 정정합니다.
댓글
첫 번째 댓글을 남겨보세요.