[Git·GitOps 22] 변경 감지와 복구: 자동 Sync·selfHeal·prune·Git revert

Git에는 replica가 1인데 클러스터에서는 누군가 2로 늘렸다면 어느 쪽을 기준으로 삼을까요? GitOps에서는 Git의 원하는 상태와 실제 상태의 차이를 drift로 관찰합니다. 자동으로 되돌릴지, 검토 후 반영할지는 동기화 정책에 따라 달라집니다.

21편의 전용 실습 클러스터와 gitops-web Application을 사용합니다. 운영에서 장애를 재현하려는 명령이 아닙니다. 먼저 수동 동기화가 성공했고 Deployment가 정상인 상태를 확인합니다.

Git·GitOps 전체 연재 · 22 / 24

이 글의 목차

세 옵션은 같은 의미가 아니다

설정	의미	확인할 위험
automated	Git의 새 원하는 상태를 자동 동기화	승인되지 않은 main 변경도 반영될 수 있음
selfHeal	클러스터 측 변경도 원하는 상태로 재조정	긴급 수동 수정과 충돌할 수 있음
prune	Git에서 빠진 관리 리소스를 삭제	잘못 지운 YAML이 실제 삭제로 이어질 수 있음

자동 동기화만 켰다고 클러스터의 모든 수동 변경을 항상 복구하는 것은 아닙니다. selfHeal 여부와 변경 감지 주기를 구분합니다. HPA나 다른 컨트롤러가 같은 필드를 관리한다면 누가 replica를 소유할지도 설계해야 합니다.

1. replica 변경을 Git으로 보낸다

배포 저장소에서 environments/dev/deployment.yaml의 replica를 1에서 2로 바꾸고 PR로 검토합니다. 수동 정책에서는 Git 변경이 감지되어 OutOfSync가 되어도 Sync 전까지 실제 replica가 그대로일 수 있습니다. UI에서 원하는 차이를 읽은 뒤 Sync합니다.

kubectl -n gitops-demo get deployment gitops-web \
  -o jsonpath='{.spec.replicas}{"\n"}'

Argo CD가 저장소를 확인하는 간격과 webhook 설정에 따라 화면에 바로 반영되지 않을 수 있습니다. Refresh는 원하는 상태를 다시 비교하는 동작이며 Sync와 구분합니다. 커밋 ID와 비교 시각을 확인하세요.

2. 자동 동기화와 selfHeal을 켠다

관리하는 bootstrap application.yaml에서 syncPolicy를 다음처럼 바꿉니다. 아직 삭제 자동화는 켜지 않습니다. bootstrap을 별도 관리한다면 Git에 기록한 뒤 관리자가 그 파일을 apply해야 Application 설정이 바뀝니다.

syncPolicy:
  automated:
    enabled: true
    selfHeal: true
    prune: false

kubectl apply -f application.yaml
# Intentional drift test in the dedicated lab only:
kubectl -n gitops-demo scale deployment/gitops-web --replicas=3
kubectl -n gitops-demo get deployment gitops-web --watch

Git의 값이 2라면 selfHeal이 활성인 컨트롤러는 실제 상태를 다시 2로 맞추려고 합니다. 즉시 반환된 scale 성공과 몇 초 뒤 관찰한 값이 다를 수 있어요. 이벤트와 Argo CD 동기화 이력을 함께 확인합니다. 이 반응은 실제 클러스터에서 독자가 검증할 항목이며 이 글에서 측정한 복구 시간은 제시하지 않습니다.

prune은 삭제까지 자동화한다

실습에서 Service YAML을 지웠을 때 자동으로 실제 Service까지 삭제하려면 prune을 켤 수 있습니다. 다만 자동 삭제를 켜기 전에 Diff와 수동 prune으로 대상을 확인합니다. 데이터가 있는 PVC나 외부 자원으로 실험하지 않습니다.

잘못된 디렉터리, 빈 렌더링 결과, 리소스 이름 변경이 삭제로 이어질 수 있습니다. Argo CD의 allowEmpty와 삭제 보호 정책도 함께 검토합니다. 자동 동기화를 쓰는 이유가 삭제 판단을 생략하기 위해서는 아닙니다.

이전 상태는 Git에서 새 변경으로 복원한다

cd ~/git-lab/gitops-config
git switch main
git pull --ff-only
git log --oneline -5
git switch -c revert/bad-deployment
# Replace BAD_CONFIG_COMMIT with the specific non-merge configuration commit.
git revert BAD_CONFIG_COMMIT
git push -u origin revert/bad-deployment

PR을 검토해 합치면 원하는 상태 자체가 이전 설정으로 돌아갑니다. 운영자가 UI에서 임시로 옛 리비전을 배포하더라도 Git의 main이 여전히 새 상태를 가리키면 다시 전진할 수 있습니다. 자동 동기화가 활성인 상태에서 Argo CD의 rollback 기능에도 제한이 있으므로 공식 정책을 확인합니다.

긴급 수동 조치가 필요하면 자동화 일시 중지의 주체와 대상, Git에 반영할 내용, 재개 조건을 기록합니다. 컨트롤러가 계속 되돌리는데 같은 kubectl edit를 반복하면 장애 판단이 어려워집니다. 코드 롤백과 데이터 복원은 별개의 절차입니다.

세부 동작은 Argo CD Automated Sync Policy, 삭제·적용 옵션은 Sync Options를 참고했습니다.

이전 글 · [Git·GitOps 21] Argo CD 첫 배포: 설치·AppProject·저장소 인증 · 다음 글 · [Git·GitOps 23] 비밀 값 관리: Secret의 base64와 SOPS·age 암호화 · 연재 목록과 예제 파일