测验：相关实践、模式与工具比较

Terraform 코드를 Git 에 두고 CI 파이프라인이 apply 하는 방식이 OpenGitOps 네 원칙 중 채우지 못하는 것은?

• 원칙 1 Declarative — Terraform 은 절차형 스크립트라 선언적이지 않다
• 원칙 2 Versioned and Immutable — CI 가 실행하면 Git 이력이 남지 않는다
• 원칙 3 Pulled Automatically 와 원칙 4 Continuously Reconciled — 에이전트가 스스로 당겨 어긋남마다 맞추지 않고 트리거로만 민다
• 네 원칙을 모두 채우므로 Git 에 둔 IaC 를 CI 가 apply 하는 것만으로 이미 GitOps 다

Argo CD 나 Flux 에 Git 웹훅을 붙여도 pull 원칙이 깨지지 않는 이유는?

• 웹훅 페이로드에 담긴 매니페스트를 그대로 적용하므로 Git 을 다시 읽을 필요가 없기 때문
• 웹훅은 '지금 당겨라' 는 신호일 뿐이며 페이로드는 신뢰하지 않고 어차피 주기적으로 일어나는 refresh 를 앞당기는 것이기 때문
• 웹훅을 받으면 조정기가 주기적 폴링을 영구히 끄고 이벤트만으로 동작하기 때문
• 웹훅은 CI 시스템이 클러스터 자격증명으로 직접 apply 한 뒤 결과를 통보하는 것이기 때문

external 조정기 패턴(한 Argo CD 가 여러 클러스터를 관리)에서 in-cluster 패턴과 달라지는 것은?

• 대상 클러스터의 자격증명이 argocd.argoproj.io/secret-type: cluster 시크릿으로 관리 클러스터에 모인다
• 각 클러스터마다 애플리케이션 컨트롤러가 따로 떠서 자기 클러스터만 조정한다
• destination.server 를 https://kubernetes.default.svc 로 두어 모든 클러스터를 같은 주소로 가리킨다
• Git 저장소를 클러스터마다 따로 두어야 하므로 상태 저장소가 여러 개가 된다

Argo CD 의 세 구성요소 중 Git 저장소의 로컬 캐시를 유지하며 리비전·경로·values 를 받아 매니페스트를 생성하는 것은?

• API 서버 — UI 와 CLI 요청을 받을 때마다 저장소를 직접 clone 해 렌더한다
• 애플리케이션 컨트롤러 — 비교 직전에 저장소를 읽어 helm template 을 실행한다
• 저장소 서버(repo-server) — 캐시를 유지하고 입력에 따라 매니페스트를 생성해 돌려준다
• notification 컨트롤러 — 저장소 변경 사건을 받아 매니페스트를 미리 만들어 둔다

Flux 에서 HelmRelease 를 보고 실제 Helm 설치·업그레이드·롤백을 수행하는 컨트롤러와 그 특징은?

• kustomize-controller — 차트를 kustomize build 로 렌더한 뒤 적용한다
• source-controller — HelmRepository 에서 차트를 받아 바로 설치한다
• notification-controller — Helm 저장소 웹훅을 받아 릴리스를 갱신한다
• helm-controller — HelmChart 아티팩트로 Helm 액션을 실행하고 실패 시 롤백·재시도 같은 자동 조치를 제공한다

두 도구의 알림 구성 방식을 바르게 짝지은 것은?

• Argo CD 는 Provider·Alert CRD 로, Flux 는 Application 어노테이션으로 구독한다
• Argo CD 는 Application·Project 의 subscribe 어노테이션으로, Flux 는 Provider 와 Alert 리소스로 구성한다
• 둘 다 Prometheus Alertmanager 에만 의존하며 자체 알림 기능이 없다
• 둘 다 Slack 웹훅 URL 을 ConfigMap 에 적으면 모든 앱에 자동으로 알림이 간다