クイズ: GitOpsと継続的デリバリー

kustomize 오버레이를 쓰는 저장소에서 이미지 태그 정책을 검사할 때 무엇을 대상으로 삼아야 합니까?

• kustomize build 로 렌더한 결과. 클러스터에 들어가는 것이 그것이기 때문입니다
• base 디렉터리의 원본 매니페스트. 모든 오버레이의 출발점이기 때문입니다
• 커밋 diff 에 포함된 줄만. 바뀐 것만 보면 검사가 빨라지기 때문입니다
• 레지스트리에 올라간 이미지 목록. 실제 아티팩트가 그곳에 있기 때문입니다

정책 도구를 파이프라인에서 돌리는데 위반이 있어도 빌드가 초록불입니다. 가장 먼저 고쳐야 할 것은 무엇입니까?

• 정책의 심각도를 높여 로그에 더 눈에 띄게 출력합니다
• 정책 규칙을 더 촘촘하게 써서 위반을 더 많이 잡습니다
• 검사 결과를 0 이 아닌 종료 코드로 옮기고 그 코드로 파이프라인을 멈춥니다
• 검사 단계를 배포 이후로 옮겨 실제 상태를 기준으로 판정합니다

운영 매니페스트에서 이미지를 태그가 아니라 다이제스트로 고정하는 주된 이유는 무엇입니까?

• 다이제스트가 태그보다 이미지 풀 속도가 빠르기 때문입니다
• 다이제스트를 쓰면 레지스트리 인증을 건너뛸 수 있기 때문입니다
• 태그는 길이 제한이 있어 버전 정보를 다 담지 못하기 때문입니다
• 태그는 다시 밀 수 있어서 검증한 것과 배포되는 것이 달라질 수 있기 때문입니다

카나리 전략의 steps 를 setWeight 10 다음 바로 setWeight 100 으로 적으면 무엇이 문제입니까?

• 가중치 사이에 pause 가 없어 판단할 자리가 없고, 결과적으로 조금 느린 전면 배포가 됩니다
• 가중치의 합이 110 이 되어 Rollout 컨트롤러가 매니페스트를 거절합니다
• 첫 단계의 10% 트래픽이 안정 버전으로 가서 카나리가 관측되지 않습니다
• 100 이라는 값은 허용되지 않으므로 마지막 단계는 항상 생략해야 합니다

두 버전의 동시 쓰기를 허용하지 않는 원장 서비스에서 블루/그린을 검토합니다. 올바른 설계 조건은 무엇입니까?

• 카나리 가중치를 1%로 낮추면 같은 원장의 동시 쓰기가 사라집니다
• 미리보기 버전의 쓰기를 별도로 통제하고 데이터 호환성과 전환 절차를 검증합니다
• autoPromotionEnabled를 false로 두면 미리보기 버전의 파일 쓰기도 막힙니다
• RWO를 쓰면 이전 버전이 자동으로 종료되므로 writer 제어는 필요 없습니다

Rollout 의 prePromotionAnalysis 가 참조하는 AnalysisTemplate 이름을 오타 냈습니다. 언제 드러납니까?

• 매니페스트를 apply 하는 순간 스키마 검증이 참조를 확인하고 거절합니다
• Rollout 컨트롤러가 시작될 때 모든 참조를 미리 해석해 이벤트로 알립니다
• 승격 직전 분석을 실행하려는 시점에야 드러납니다. 그래서 배포 전에 따로 확인해야 합니다
• 분석이 조용히 성공으로 처리되어 끝까지 드러나지 않습니다

Argo CD Application 을 만들 때 spec.project 를 default 로 두면 어떤 위험이 있습니까?

• default 프로젝트는 자동 동기화를 지원하지 않아 수동 sync 만 가능합니다
• default 프로젝트에 속한 Application 은 prune 옵션이 무시됩니다
• default 프로젝트는 네임스페이스를 자동으로 만들지 못해 첫 동기화가 실패합니다
• default 프로젝트는 어떤 저장소와 클러스터, 어떤 리소스 종류든 허용합니다

Argo CD 동기화는 성공했다고 나오는데 대상 네임스페이스에 아무것도 없습니다. 가장 먼저 대조할 두 값은 무엇입니까?

• Application 의 destination.namespace 와 렌더 결과의 metadata.namespace
• Application 의 targetRevision 과 저장소의 기본 브랜치 이름
• Application 의 project 이름과 AppProject 의 sourceRepos 목록
• Application 의 syncPolicy.automated 와 컨트롤러의 재시도 횟수