クイズ: Argoプロジェクトの全体像

GitOps 의 풀(pull) 배포 모델이 푸시 모델보다 낫다고 말할 때, 가장 정확한 근거는 무엇인가?

• 매니페스트를 평범한 YAML 로 쓸 수 있어서 러닝 커브가 낮다
• 배포 속도가 kubectl apply 보다 빠르다
• 클러스터마다 파이프라인을 따로 만들 수 있다
• 클러스터 자격 증명이 CI 시스템 밖으로 나가지 않고, 컨트롤러가 계속 비교하므로 드리프트가 상태로 드러난다

Argo CD 와 Argo Workflows 를 한 컨트롤러로 합치지 않은 가장 본질적인 이유는?

• 두 프로젝트의 개발팀이 다르기 때문
• Argo CD 는 완료 개념이 없는 무한 조정 루프이고 Workflows 는 완료가 전부인 유한 실행이라, 재시도·실패·성공의 의미 자체가 다르기 때문
• Workflows 가 Argo CD 보다 한참 나중에 만들어져 합칠 기회가 없었기 때문
• Workflows 는 CRD 를 쓰지 않기 때문

Argo Events 가 Argo CD 안에 들어가지 않고 별도 프로젝트로 존재하는 이유로 가장 적절한 것은?

• Argo CD 가 웹훅을 전혀 처리하지 못하기 때문
• Argo Events 가 쿠버네티스 클러스터 외부에서만 동작하도록 설계돼 안에 넣을 수 없었기 때문
• GitHub·S3·Kafka·캘린더 같은 온갖 외부 신호 어댑터를 배포 컨트롤러 안에 넣지 않기 위해 EventSource/Sensor/Trigger 라는 별도 축으로 분리한 것
• Events 는 CNCF 프로젝트가 아니기 때문

Argo CD 가 CNCF Graduated 등급이라는 사실이 실무 판단에 주는 의미로 가장 적절한 것은?

• 무료로 쓸 수 있다는 뜻이다
• 성능이 다른 GitOps 도구보다 빠르다는 것을 CNCF 가 인증한 것이다
• 보안 취약점이 없다는 보증이다
• API 와 동작이 안정 단계에 들어섰다는 신호라, Application 매니페스트를 조직 표준으로 삼아도 되는 판단 근거가 된다

etcd 멤버가 3개로 쿼럼이 유지되는데도 클러스터에 kubectl 로 접속할 수 없는 상황이 벌어질 수 있다. 가장 흔한 원인은?

• 모든 클라이언트의 서버 주소가 특정 컨트롤 플레인의 물리 IP 로 고정돼 있고 apiserver 인증서 SAN 에 다른 노드 IP 가 없어서
• etcd 스냅샷 백업이 없어서
• 컨트롤 플레인 수가 홀수가 아니어서
• kubelet 버전이 apiserver 보다 높아 버전 스큐를 벗어나서

네 Argo 프로젝트와 그 역할을 잘못 짝지은 것은?

• Argo Rollouts — 카나리·블루그린으로 새 버전 노출 비율을 지표를 보며 늘린다
• Argo Workflows — 컨테이너 작업들을 DAG 로 엮어 한 번 완주시킨다
• Argo CD — 컨테이너 이미지를 빌드하고 레지스트리에 푸시한다
• Argo Events — 외부 신호를 받아 트리거를 발동시킨다