クイズ: GitOpsの原則

kubectl diff 를 실행했더니 종료 코드가 1 이었습니다. 무슨 뜻인가요?

• 선언과 실제 상태 사이에 차이가 있다
• 클러스터 접속에 실패해 비교를 못 했다
• 적용 단계에서 오류가 나 실패했다
• 매니페스트에 스키마 오류가 있어 거부됐다

프로덕션 매니페스트에 :latest 태그를 쓰면 안 되는 근본적인 이유는?

• 같은 커밋이 시점에 따라 다른 이미지를 배포해 저장소가 상태를 정의하지 못한다
• latest 태그가 가리키는 이미지가 커져 노드마다 풀 시간이 길어진다
• 대부분의 레지스트리가 latest 태그를 덮어쓰는 것을 정책으로 막는다
• 쿠버네티스가 latest 태그에는 imagePullPolicy 를 적용하지 않는다

장애 대응 중 kubectl scale 로 replicas 를 늘려 서비스를 살렸습니다. 사태가 끝난 뒤 반드시 해야 할 일은?

• 그 값을 저장소에 커밋해 반영하거나, 저장소 기준으로 되돌린다
• 손으로 바꾼 값은 필드 소유자가 kubectl 로 바뀌어 그대로 유지된다
• 그 리소스를 ignoreDifferences 에 넣어 비교 대상에서 빼 둔다
• 다음 정기 배포 때 저절로 정리되므로 그때까지 기다린다

GitOps 가 push 방식(CI 가 직접 배포) 대신 pull 방식(클러스터 안의 에이전트가 저장소를 읽음)을 선호하는 보안상 이유는?

• push 방식은 배포 이력이 git 이 아니라 CI 로그에만 남기 때문
• pull 방식에서만 커밋 되돌리기로 롤백할 수 있기 때문
• 클러스터 자격 증명을 CI 시스템에 넘기지 않아도 되기 때문
• 에이전트가 클러스터 안에 있어 배포가 언제나 더 빠르기 때문

앱 코드 저장소와 매니페스트 저장소를 분리하라고 권하는 이유로 가장 적절한 것은?

• 한 저장소에 애플리케이션 코드와 YAML 을 섞으면 빌드 캐시가 매번 깨지기 때문
• 앱 CI 가 돌 때마다 동기화가 트리거되고 코드 리뷰와 배포 리뷰가 뒤섞이기 때문
• ArgoCD 가 저장소 안의 하위 디렉터리를 경로로 지정하지 못하기 때문
• 매니페스트 이력이 쌓이면 저장소 용량 한도에 먼저 걸리기 때문

매니페스트에 app.kubernetes.io/managed-by: gitops 같은 라벨을 붙이는 실용적 목적은?

• 쿠버네티스가 이 라벨을 보고 리소스 적용 순서를 정하기 때문
• 권장 라벨이 빠지면 admission 단계에서 apply 가 거부되기 때문
• 이 라벨이 파드를 같은 노드에 모으는 스케줄링 힌트가 되기 때문
• 손으로 만든 오브젝트와 저장소가 소유한 오브젝트를 구분하기 위해

커밋 메시지 규율이 GitOps 에서 특히 중요한 이유는?

• 정해진 형식을 벗어난 커밋 메시지는 자동 동기화 대상에서 아예 제외되기 때문
• 커밋 메시지가 렌더링 변수로 들어가 매니페스트 내용 자체에 반영되기 때문
• 커밋 메시지가 길수록 저장소 폴링과 diff 계산이 함께 눈에 띄게 느려지기 때문
• 롤백은 되돌릴 커밋을 고르는 일이고, 장애 중에 사람이 읽는 것은 커밋 로그 한 화면뿐이기 때문