クイズ: Applicationと同期

같은 sync wave 안에 Service 와 Deployment 가 있습니다. 적용 순서를 정하는 것은?

• 한 파일 안에 매니페스트가 적힌 순서, 즉 YAML 문서가 등장한 순
• 정해진 규칙 없이 컨트롤러가 잡히는 대로 병렬로 적용하는 순서
• kustomization.yaml 의 resources 에 적힌 파일 이름의 사전순
• 리소스 종류별 기본 순서(Namespace, ConfigMap, Service, 워크로드 순)

argocd.argoproj.io/hook-delete-policy 를 지정하지 않았을 때의 기본값과 그 효과는?

• HookSucceeded — 훅 Job 이 성공으로 끝나는 즉시 그 리소스가 삭제된다
• BeforeHookCreation — 훅 리소스가 남아 있다가 다음 sync 에서 새로 만들기 직전에 삭제된다
• HookFailed — 훅 Job 이 실패했을 때만 삭제되고 성공하면 그대로 남는다
• 기본 정책이 없어 삭제 정책을 명시하기 전까지는 훅 자체가 실행되지 않는다

syncPolicy.automated.prune: true 가 특히 위험한 이유는?

• prune 은 앱이 만든 리소스뿐 아니라 그것들이 들어 있는 네임스페이스까지 통째로 지워 버리기 때문
• prune 이 지운 리소스를 다시 만드는 과정에서 모든 파드가 한꺼번에 재시작되어 순간 다운타임이 생기기 때문
• prune 이 켜져 있으면 이전 리비전 기록이 남지 않아 argocd app rollback 으로 되돌릴 수 없기 때문
• source.path 를 잘못 가리킨 커밋 하나로 렌더 결과가 0 개가 되면 그 앱이 관리하던 리소스가 모두 삭제 대상이 되기 때문

selfHeal: true 가 하는 일은?

• 저장소에서 지워진 리소스를 클러스터에서도 따라 지운다
• 클러스터의 실제 상태가 저장소와 달라지면 저장소 쪽으로 되돌린다
• 헬스 체크에 실패한 파드를 찾아 자동으로 재시작한다
• 실패한 동기화를 정해진 간격으로 자동 재시도한다

AppProject 의 sourceRepos 를 ["*"] 로 두면 생기는 문제는?

• 어떤 저장소에서든 배포할 수 있게 되어 프로젝트로 경계를 나눈 의미가 사라진다
• repo-server 가 저장소 목록을 고정하지 못해 매니페스트 캐시를 쓰지 못한다
• 와일드카드는 유효한 값이 아니라 Application 생성 단계에서 거부된다
• 허용 목록을 매번 전부 훑느라 동기화가 눈에 띄게 느려진다

HPA 가 관리하는 Deployment 에서 ArgoCD 가 계속 Syncing 을 반복합니다. 가장 적절한 조치는?

• ignoreDifferences 로 /spec/replicas 를 비교 대상에서 제외한다
• 이 Application 의 자동 동기화를 끄고 필요할 때만 수동으로 동기화한다
• HPA 를 지우고 replicas 를 저장소에 고정값으로 적어 스케일을 고정한다
• retry.limit 을 늘려 반복되는 동기화가 결국 한 값으로 수렴하게 한다

retry.backoff 에 factor 를 주는 이유는?

• 훅 Job 하나가 붙잡을 수 있는 최대 실행 시간을 제한해 두기 위해
• 재시도 간격을 점점 벌려 실패한 동기화가 API 서버를 같은 간격으로 계속 두드리지 않게 하려고
• 정해진 시간 안에 시도할 수 있는 재시도 횟수를 더 많이 늘리기 위해
• 여러 앱이 동시에 실패했을 때 어느 것부터 재시도할지 정해 두기 위해