무엇을 비교에서 뺄 것인가

한 줄 요약

무시 규칙은 동기화 판정에서 특정 필드를 빼는 장치이고, 넓게 쓰면 소음과 함께 진짜 드리프트도 사라지므로
argocd admin settings resource-overrides ignore-differences 로 지워지는 줄을 눈으로 확인하고 커밋해야 한다.

왜 이 장치가 필요했나

GitOps 의 이상은 "저장소에 적힌 것이 곧 클러스터" 다. 현실은 그렇지 않다. 클러스터에는 저장소에 적을 수
없는 값이 계속 생긴다. HPA 가 spec.replicas 를 바꾸고, 사이드카 주입 웹훅이 컨테이너를 하나 더 끼워
넣고, 컨트롤러가 deployment.kubernetes.io/revision 같은 주석을 붙인다. 이 값들을 저장소에 적을 수는
없다 — 적는 순간 그 값은 고정되고, 그러면 HPA 나 웹훅이 존재할 이유가 없어진다.

그래서 무시 규칙이 있다. "이 필드의 차이는 OutOfSync 로 치지 않는다" 를 선언하는 자리다. 문제는 이
장치에 한쪽으로만 기우는 힘이 있다는 점이다. 넓게 무시하면 화면이 조용해지고, 좁게 무시하면 계속
시끄럽다. 조용한 쪽의 대가는 몇 달 뒤에 온다.

어떻게 동작하나

규칙은 두 자리에 쓸 수 있다. 전역은 argocd-cm 의
resource.customizations.ignoreDifferences.<그룹>_<종류> 이고, 앱별은 Application 의
spec.ignoreDifferences 리스트다. 둘은 합쳐져 적용된다 — 그래서 **전역에 넓게 걸어 두고 앱에서 좁히는
일은 되지 않는다.** 좁히는 방향의 규칙은 처음부터 앱 쪽에 두어야 한다.

규칙 블록 안에는 세 가지 목록을 쓸 수 있다.

resource.customizations.ignoreDifferences.apps_Deployment: |  jsonPointers:  - /spec/replicas  jqPathExpressions:  - .spec.template.spec.containers[] | select(.name == "sidecar").image  managedFieldsManagers:  - kubectl

jsonPointers 는 슬래시로 내려가는 경로다. 간단하지만 배열은 자리 번호로만 가리킬 수 있어서, 컨테이너
순서가 바뀌면 엉뚱한 원소를 무시하게 된다. jqPathExpressions 는 조건으로 고를 수 있다 — 위 예처럼
"이름이 sidecar 인 컨테이너의 image" 를 지목할 수 있고, 이건 포인터로는 안정적으로 쓸 수 없다.
managedFieldsManagers 는 종류가 다르다. 필드 경로가 아니라 그 필드를 마지막으로 쓴 관리자 이름으로
무시할 대상을 고른다. 서버측 적용이 남긴 소유 기록을 근거로 삼는 방식이라, 리소스 YAML 만 보고는 무엇이
빠질지 계산할 수 없다. 미리보기 명령이 이 목록만으로는 아무것도 렌더하지 못하는 이유다.

이름이 비슷한 다른 손잡이가 하나 더 있다. ignoreResourceUpdates 는 조정 루프를 깨울지를 정한다.
주석 한 칸이 바뀔 때마다 컨트롤러가 앱 전체를 다시 계산하는 것을 막는 성능 손잡이이고, 동기화 판정은
바꾸지 않는다. 이름이 닮아서 자주 혼동되는데, 목적이 아예 다르다.

현장에서 만나는 모습

가장 자주 보는 장면은 이렇다. 앱 열 개가 전부 노란불이고, 원인은 HPA 다. 급한 사람이 전역 argocd-cm 에
apps_Deployment 의 /spec 을 통째로 무시하는 한 줄을 넣는다. 화면이 조용해지고 아무도 이 줄을 다시
보지 않는다. 몇 달 뒤 누군가 운영에서 손으로 이미지 태그를 바꾼다. Argo CD 는 여전히 초록이다.
저장소를 진실의 원천이라고 부르는 시스템이 그날부터 거짓말을 하기 시작한 것인데, 그 사실을 알려 주는
화면이 없다.

두 번째는 순서 문제다. 사이드카를 무시하려고 /spec/template/spec/containers/1 을 썼는데, 어느 날 웹훅이
사이드카를 앞에 끼워 넣는다. 이제 무시되는 것은 애플리케이션 컨테이너다. 이런 규칙은 틀렸다는 신호를
내지 않는다 — 조용히 반대로 동작한다.

그래서 무시 규칙에는 두 가지 습관이 필요하다. 첫째, 쓰기 전에 렌더해서 지워지는 줄을 본다.
둘째, 규칙을 넣은 줄 옆에 그 규칙이 필요한 이유를 적는다. 이유가 사라졌을 때 규칙을 지울 수 있는
사람은 그 이유를 아는 사람뿐이다.

이 실습 환경의 한계

실습 파드에는 Argo CD 컨트롤러가 없다. 그래서 "규칙을 넣었더니 OutOfSync 가 Synced 로 바뀌었다" 는
볼 수 없고, managedFieldsManagers 가 실제로 어떤 필드를 걸러 내는지도 미리보기로는 확인할 수 없다.
대신 규칙을 해석해 필드를 지우는 그 코드가 CLI 안에 있어서, 어떤 줄이 비교에서 빠지는지는 정확히 같은
결과로 볼 수 있다.

다음 실습에서 할 것

같은 Deployment 한 장을 재료로 규칙을 하나씩 바꿔 가며 렌더한다. 포인터와 jq 식의 차이를 직접 보고,
/spec 을 통째로 무시했을 때 이미지 줄까지 사라지는 것을 확인한다. 관리자 이름 규칙과
ignoreResourceUpdates 가 미리보기에서 어떻게 보이는지도 정직하게 기록한다. 마지막에는 Application 에
앱별 규칙을 얹어 kwok 클러스터에 올리고, "이 규칙이 이 글자를 지우는가" 를 표로 만들어 한 번에 검사한다.