ArgoCD Sync 정책 정리 - automated · selfHeal · prune

ArgoCD의 세 가지 Sync 정책(automated, selfHeal, prune)이 각각 무엇을 감시하고 어떻게 동작하는지, 그리고 환경별로 어떤 조합을 택해야 하는지 정리한다.

핵심 개념

ArgoCD는 Git을 Single Source of Truth로 삼아 클러스터 상태를 관리한다. Sync 정책은 “자동화 범위를 어디까지 허용할 것인가”를 결정한다.

한 줄 요약:

automated	selfHeal	prune	시나리오	동작
✅	✅	✅	Git에 새 매니페스트 추가	✅ 자동 생성
✅	✅	✅	Git에서 매니페스트 삭제	✅ 클러스터에서도 자동 삭제
✅	✅	✅	`kubectl edit`로 수정	✅ 자동 원상복구
✅	✅	✅	`kubectl create`로 리소스 추가	❌ 관여 안 함 (Git에 없는 리소스는 ArgoCD 관리 밖)
✅	✅	❌	Git에서 매니페스트 삭제	❌ 클러스터에 리소스 잔존 (OutOfSync 표시만)
✅	❌	✅	Git에서 매니페스트 삭제	✅ 클러스터에서도 삭제
✅	❌	✅	`kubectl edit`로 수정	❌ 방치
✅	❌	❌	Git 변경	✅ 자동 Sync (추가/수정만)
❌	-	-	뭐든	❌ 수동 Sync 필요

prune: true는 Git의 작은 실수를 즉각적인 장애로 연결한다.

실수로 kustomization.yaml에서 configmap.yaml 참조를 제거
  ↓
Git push
  ↓
prune: true → ConfigMap 클러스터에서 즉시 삭제 💥
  ↓
Pod가 ConfigMap 참조 실패 → 장애

반면 prune: false이면:

같은 실수 발생
  ↓
ArgoCD: "OutOfSync" 표시만 됨 (삭제 안 함)
  ↓
사람이 발견 → 실수 수정하거나 수동으로 정리

prune은 “자동화 편의”와 “안전망” 사이의 트레이드오프다. Git 조작 실수가 곧 리소스 삭제로 이어지는 구조이므로, production에서는 끄는 것이 기본값이다.

환경	automated	selfHeal	prune	이유
test	✅	✅	✅	완전 자동화, 깨져도 괜찮음
staging	✅	✅	❌	자동 배포 + drift 복구, 삭제는 수동 확인
production	✅	✅	❌	자동 배포 + drift 복구, 삭제는 절대 자동화 X

production에서 prune: true는 “Git 실수 = 즉시 리소스 삭제 = 장애”이므로 끄는 것이 안전하다. 리소스 정리가 필요하다면 argocd app sync --prune으로 의도적으로 수행하는 것이 낫다.

spec:
  syncPolicy:
    automated:
      selfHeal: true
      prune: false   # staging/production 권장