Argo CD로 관리하는 Deployment를 운영자가 kubectl로 직접 수정했습니다. Git과 실제 설정이 달라지면 어떻게 감지되며, 어느 쪽 상태가 유지되나요?

Argo CD는 Git에 있는 원하는 상태와 클러스터에서 관찰한 실제 상태를 계속 비교합니다. 운영자가 kubectl로 Deployment를 바꾸면 우선 두 상태 사이에 drift가 생기고, Argo CD는 이를 OutOfSync로 표시할 수 있습니다. 그다음 실제로 원래 선언으로 되돌아가는지는 자동 동기화와 self-heal 설정, 동기화 일시 중지 여부, 그리고 해당 필드를 누가 관리하는지에 달려 있습니다. 따라서 Git에 커밋했다는 사실, Argo CD가 변경을 감지했다는 사실, 새 Pod가 준비됐다는 사실은 각각 확인해야 합니다.

예를 들어 Git에는 replica가 4개인데 운영자가 긴급하게 8개로 늘렸다고 하겠습니다. 자동 동기화와 self-heal이 켜져 있으면 Argo CD가 다음 비교 주기에 4개로 되돌릴 수 있습니다. 반대로 자동 동기화만 켜져 있거나 self-heal을 끈 구성에서는 drift를 표시하지만 수동 sync 전까지 8개가 유지될 수 있습니다. Git이 기준이라는 선언은 자동 복구 정책과 함께 있을 때 실제 효과를 냅니다. 먼저 애플리케이션의 sync 상태, 마지막 비교 시각, sync 정책, 대상 리소스의 metadata.managedFields와 이벤트를 보겠습니다.

상태 비교와 기능 정상 여부를 나눕니다

Argo CD가 비교하는 대상은 선언된 Kubernetes 리소스의 구조와 실제 리소스입니다. 비교가 일치해 Synced가 되어도 앱이 정상이라는 뜻은 아닙니다. 잘못된 이미지가 정상적으로 실행되거나, readiness는 통과했지만 DB 연결이 실패하거나, 새 설정이 기능 오류를 만들 수 있습니다. 그래서 Sync 상태와 Health 상태, 요청 오류율·지연·로그를 별도의 축으로 봅니다. 반대로 실제 클러스터가 Git과 다르다고 해서 항상 수동 변경이 잘못된 것도 아닙니다. HPA가 replicas를 바꾸는 것처럼 다른 컨트롤러가 정당하게 관리하는 필드는 선언에서 제외하거나 필드 소유권을 설계해야 합니다. ignoreDifferences로 비교만 무시하는 것과 동기화 때 그 값을 쓰지 않는 것은 다릅니다. 실제 sync에도 무시 규칙을 반영하려면 RespectIgnoreDifferences 등 적용 정책과 대상 리소스의 기존 존재 여부를 확인해야 합니다. 다만 무시할 필드를 넓히면 사람이 바꾼 보안 설정이나 포트도 drift로 잡히지 않을 수 있습니다.

긴급 변경이 필요하면 먼저 누가 언제 무엇을 바꿨는지 남기고, 자동 복구가 변경을 덮어쓰기 전에 변경을 Git의 일시적 패치나 정식 수정으로 반영하겠습니다. 즉시 반영할 수 없다면 sync를 잠깐 멈추되 만료 시각과 재개 책임자를 정합니다. 긴급 변경을 영구 상태로 두려고 self-heal을 끄는 방식은 통제된 예외이지 운영 절차의 기본값이 아닙니다.

여러 컨트롤러의 경쟁을 실제 필드로 확인합니다

Deployment의 replica를 Argo CD와 HPA가 동시에 쓰면 한쪽은 4로, 다른 쪽은 부하에 따라 10으로 바꾸는 진동이 생길 수 있습니다. 이때 Argo CD가 계속 재동기화하는 것이 문제가 아니라 필드 소유권이 충돌한 것입니다. 선언에서 HPA 대상 필드를 제외하거나, 애초에 autoscaling 정책을 Git에서 관리하고 Deployment의 고정 replica와 함께 사용하지 않는 방식으로 책임을 하나로 만들겠습니다. 설정 변경 뒤에는 수동 drift를 만들고 복구되는지, Git 접근 장애가 나도 이미 실행 중인 Pod는 어떻게 되는지, 잘못된 선언이 적용됐을 때 Health와 사용자 지표가 어떻게 나타나는지를 시험합니다. 반복 비교와 self-heal의 목적은 잘못된 선언을 고치는 것이 아니라 선언된 기준으로 수렴시키는 것입니다. 이를 조정 루프(reconciliation loop)라고 부릅니다.