Argo CD 와 Flux — 하나의 애플리케이션 컨트롤러와 여러 컨트롤러의 조합

한 줄 요약

Argo CD 는 API 서버·저장소 서버·애플리케이션 컨트롤러 세 부품이 Application 이라는 하나의 리소스를 중심으로 돌고, Flux 는 source·kustomize·helm·notification·image 컨트롤러가 각자의 CRD 를 맡아 조합됩니다. 알림과 지표는 두 도구 모두 표준 방식(어노테이션/CRD, Prometheus)으로 붙습니다.

왜 이게 필요했나

CGOA 의 Tooling 도메인(14%)은 "조정기로 Argo CD 와 Flux 가 있다" 를 아는 것에서 그치지 않습니다. 두 도구가 같은 원칙을 다른 구조로 구현한다는 점, 그래서 Helm 을 다루는 방식이 다르고 UI 의 유무가 다르며 멀티테넌시를 푸는 방식이 다르다는 점을 묻습니다. 실무에서도 도구를 고를 때 "어느 쪽이 좋은가" 보다 "우리 팀은 어느 구조에 맞는가" 가 답에 가깝습니다.

어떻게 동작하나

Argo CD — 세 부품과 Application

공식 아키텍처 문서의 세 구성요소입니다. API 서버는 gRPC/REST 서버로 Web UI·CLI·CI/CD 시스템이 쓰는 API 를 제공하고, 애플리케이션 관리와 상태 보고, sync·rollback 같은 작업 호출, 저장소·클러스터 자격증명 관리(K8s 시크릿), 외부 IdP 인증 위임, RBAC, 그리고 Git 웹훅 수신을 맡습니다. 저장소 서버는 Git 저장소의 로컬 캐시를 유지하며 저장소 URL·리비전·경로·템플릿 설정(parameters, values)을 입력으로 받아 매니페스트를 생성합니다. 애플리케이션 컨트롤러는 실행 중인 애플리케이션을 지속적으로 감시해 실제 상태와 원하는 상태를 비교하고 OutOfSync 를 감지하며, PreSync·Sync·PostSync 훅을 호출합니다.

Git/Helm/OCI  ──►  repo-server (렌더: helm template / kustomize build)                        │                        ▼              application-controller ──► 클러스터(들)   비교·sync·훅                        ▲UI / CLI / CI  ──►  api-server (RBAC, 인증, 웹훅 수신)

Flux — GitOps Toolkit 의 컨트롤러 조합

Flux 는 "GitOps Toolkit" 이라 부르는 전용 컨트롤러·조합 가능한 API·Go 패키지의 묶음이고, 각 컨트롤러는 자기 CRD 만 맡습니다.

| 컨트롤러 | CRD | 맡는 일 |
| --- | --- | --- |
| source-controller | GitRepository, OCIRepository, HelmRepository, HelmChart, Bucket | 소스를 주기적으로 확인해 아티팩트(tar.gz)를 만들고 클러스터 안에서 제공 |
| kustomize-controller | Kustomization | 아티팩트를 Kustomize 로 빌드해 적용, SOPS 복호화, 서비스 계정 가장(impersonation), 건강 평가, depends-on 순서, 제거된 오브젝트 정리(prune) |
| helm-controller | HelmRelease | HelmChart 아티팩트로 실제 Helm 액션(설치·업그레이드·테스트·롤백·제거)을 수행하고 실패 시 자동 조치 |
| notification-controller | Provider, Alert, Receiver | 바깥 사건을 받아(Receiver) 조정을 깨우고, 컨트롤러 사건을 바깥으로 보냄(Provider/Alert) |
| image-reflector/automation | ImageRepository, ImagePolicy, ImageUpdateAutomation | 레지스트리를 스캔해 정책에 맞는 새 태그를 찾고 Git 에 커밋으로 되돌려 씀 |

Source 는 "저장소의 출처와 그것을 얻는 조건(자격증명, 버전 선택자)" 을 정의하고, 정해진 간격으로 확인해 새 버전이 있으면 새 아티팩트를 만듭니다. 한 소스를 여러 소비자가 공유할 수 있습니다. Kustomization 은 기본 5분마다 조정하며, kubectl edit/patch/delete 로 바꾼 것은 곧 되돌려집니다. 모든 Flux CRD 는 리소스 카테고리에 등록되어 있어 kubectl get fluxcd -A 한 번으로 전부 볼 수 있습니다. bootstrap 은 Flux 구성요소 자체를 GitRepository 와 Kustomization 으로 적용해 Flux 가 자기 자신을 관리하게 하는 절차입니다.

구조가 만드는 차이

가장 자주 묻는 차이는 Helm 입니다. Argo CD 는 helm template 으로 부풀리기만 하고 수명주기를 직접 관리하므로 Helm 릴리스 히스토리와 Helm 훅 의미론에 기대지 않습니다. Flux 의 helm-controller 는 HelmRelease 를 보고 실제 Helm 설치·업그레이드를 실행하며 Helm 테스트와 롤백을 포함한 자동 조치(remediation)를 제공합니다. 둘째는 화면입니다. Argo CD 는 API 서버와 Web UI 가 핵심 구성요소이고, Flux 는 CLI 가 기본이며 UI 는 Flux Operator·Capacitor·Headlamp 플러그인·Weave GitOps 같은 별도 프로젝트 목록으로 안내합니다. 셋째는 멀티테넌시입니다. Flux 는 "가장(impersonation)을 통한 진짜 Kubernetes RBAC" 로 Kustomization 마다 서비스 계정을 지정하고, Argo CD 는 AppProject 와 자체 RBAC 로 나눕니다.

알림 — 어디에 무엇을 붙이는가

Argo CD Notifications 는 애플리케이션 상태 변화를 감시해 트리거와 템플릿으로 알림을 만듭니다. 카탈로그에 유용한 트리거·템플릿이 있어 그대로 쓸 수 있고, 서비스는 argocd-notifications-cm 과 argocd-notifications-secret 에 등록하며, 구독은 Application 이나 Project 에 notifications.argoproj.io/subscribe.on-sync-succeeded.slack: <채널> 같은 어노테이션으로 겁니다. Flux 는 컨트롤러가 리소스 상태 변화마다 Kubernetes 이벤트를 내고, notification-controller 가 Provider(type: slack 등, secretRef)와 Alert(providerRef, eventSources 로 kind/name 선택, eventSeverity info/error)로 그것을 바깥으로 보냅니다. GitHub·GitLab·Gitea·Bitbucket·Azure DevOps 공급자는 채팅 대신 커밋 상태로 되돌려 주는 점이 다릅니다.

관측성 — Prometheus 지표

Argo CD 는 서버마다 다른 지표 집합을 내고, 애플리케이션 컨트롤러 지표는 argocd-metrics:8082/metrics 에서 긁습니다. argocd_app_info(sync_status·health_status 라벨을 가진 gauge), argocd_app_sync_total(counter), argocd_app_reconcile(histogram) 이 대표적입니다. Flux 컨트롤러는 기본으로 포트 8080 의 /metrics 에 gotk_reconcile_duration_seconds_bucket{kind,name,namespace,le} 같은 조정 소요 시간 히스토그램과 controller_runtime_reconcile_total{controller,result} 를 냅니다. Flux 리소스 자체의 상태 지표는 컨트롤러가 내지 않고 kube-state-metrics 로 수집하며, flux2-monitoring-example 저장소가 준비된 구성을 제공합니다.

CI 와의 연동

두 도구 모두 CI 를 실행하지 않습니다. 연동 지점은 세 가지입니다. 첫째, CI 가 Git 을 바꾸면 웹훅으로 조정을 앞당깁니다(Argo CD /api/webhook, Flux Receiver). 둘째, Argo CD 의 API 서버는 CI/CD 시스템이 호출하는 API 이므로 파이프라인이 sync 를 요청하거나 상태를 조회할 수 있습니다. 셋째, Flux 의 이미지 자동화는 CI 가 레지스트리에 올린 새 태그를 찾아 Git 에 커밋으로 되돌려 쓰므로, CI 가 매니페스트를 고치지 않아도 배포가 이어집니다. 어느 경우든 클러스터를 바꾸는 주체는 조정기 하나입니다.

현장에서 만나는 모습

Argo CD 를 쓰는 팀이 "Synced 인데 실제 파드가 옛 이미지" 라는 문의를 자주 합니다. 원인은 대개 조정기가 아니라 그 앞입니다. CI 가 태그를 바꾸지 않았거나, 저장소 서버의 캐시가 아직 옛 리비전이거나, 웹훅이 오지 않아 3분 폴링을 기다리는 중입니다. 지표에서 argocd_app_info 의 sync_status 와 Git 의 최신 커밋을 함께 보면 어느 단계에서 멈췄는지 갈립니다.

Flux 에서는 kubectl get fluxcd -A 를 먼저 보면 대부분 답이 나옵니다. GitRepository 가 Ready 가 아니면 source 단계, Kustomization 이 Ready 가 아니면 빌드·적용·건강 평가 중 어디서 막혔는지 조건(condition)에 적혀 있습니다.

다음 퀴즈에서 확인할 것

IaC·CI/CD 와 GitOps 의 경계, 웹훅이 pull 원칙과 어떻게 양립하는지, in-cluster 와 external 조정기의 자격증명 위치, 점진적 배포와 Git 선언의 관계, Argo CD 세 부품의 역할, Flux 컨트롤러와 CRD 의 짝, Helm 을 다루는 방식의 차이, 알림·지표가 붙는 자리를 묻습니다. 참고: [Argo CD Architectural Overview](https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/), [GitOps Toolkit components](https://fluxcd.io/flux/components/), [Argo CD Notifications](https://argo-cd.readthedocs.io/en/stable/operator-manual/notifications/), [Flux alerts](https://fluxcd.io/flux/monitoring/alerts/), [Argo CD Metrics](https://argo-cd.readthedocs.io/en/stable/operator-manual/metrics/), [Flux Prometheus metrics](https://fluxcd.io/flux/monitoring/metrics/).