GitOps 와 ArgoCD · Application 과 동기화 · 퀴즈
퀴즈: Application 과 동기화
문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
같은 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 서버를 같은 간격으로 계속 두드리지 않게 하려고
- 정해진 시간 안에 시도할 수 있는 재시도 횟수를 더 많이 늘리기 위해
- 여러 앱이 동시에 실패했을 때 어느 것부터 재시도할지 정해 두기 위해