Flux의 멀티컨트롤러 아키텍처, 다양한 소스 관리, Kustomization 리소스, 이미지 자동 업데이트 기능을 분석하고 ArgoCD와 비교합니다.
이전 장에서 ArgoCD의 아키텍처와 고급 기능을 살펴보았습니다. 이번 장에서는 CNCF Graduated 프로젝트인 Flux를 심층적으로 분석합니다. Flux는 ArgoCD와는 근본적으로 다른 아키텍처 철학을 가지고 있으며, 특히 멀티소스 지원과 이미지 자동 업데이트에서 강점을 보여줍니다.
Flux는 단일 모놀리식 애플리케이션이 아닌, 각각 독립적인 책임을 가진 여러 마이크로컨트롤러(Micro-Controller)의 집합입니다. 이 설계 철학은 관심사 분리(Separation of Concerns) 원칙을 따르며, 필요한 컴포넌트만 선택적으로 설치할 수 있습니다.
소스 컨트롤러는 외부 소스로부터 아티팩트를 가져오는 역할을 합니다. Flux가 ArgoCD와 가장 크게 차별화되는 부분 중 하나가 바로 이 다양한 소스 지원입니다.
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
name: infra-repo
namespace: flux-system
spec:
interval: 5m
url: https://github.com/org/infra-manifests
ref:
branch: main
secretRef:
name: git-credentials
ignore: |
# 불필요한 파일 제외
/*
!/clusters/
!/infrastructure/
!/apps/apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
name: bitnami
namespace: flux-system
spec:
interval: 30m
url: https://charts.bitnami.com/bitnami
type: default # default (HTTP) 또는 ociapiVersion: source.toolkit.fluxcd.io/v1beta2
kind: OCIRepository
metadata:
name: app-manifests
namespace: flux-system
spec:
interval: 5m
url: oci://ghcr.io/org/manifests/app
ref:
tag: latest
provider: genericOCI 레지스트리(OCI Repository)를 소스로 사용하면 Git 저장소 없이도 GitOps를 구현할 수 있습니다. CI 파이프라인에서 매니페스트를 OCI 아티팩트로 패키징하여 레지스트리에 푸시하고, Flux가 이를 풀링하는 방식입니다. 이를 OCI 기반 GitOps라고 합니다.
Kustomize 컨트롤러는 소스 컨트롤러가 가져온 아티팩트에서 Kustomization을 빌드하고 Kubernetes에 적용합니다. ArgoCD의 Application CRD에 대응하는 리소스입니다.
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: infrastructure
namespace: flux-system
spec:
interval: 10m
retryInterval: 2m
timeout: 5m
sourceRef:
kind: GitRepository
name: infra-repo
path: ./infrastructure/production
prune: true
healthChecks:
- apiVersion: apps/v1
kind: Deployment
name: nginx-ingress-controller
namespace: ingress-nginx
dependsOn:
- name: cert-manager
- name: sealed-secrets
postBuild:
substitute:
CLUSTER_NAME: production-ap-northeast-2
DOMAIN: example.com
substituteFrom:
- kind: ConfigMap
name: cluster-varsHelm 컨트롤러는 HelmRelease CRD를 통해 Helm 차트의 선언적 관리를 담당합니다.
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
name: prometheus-stack
namespace: monitoring
spec:
interval: 30m
chart:
spec:
chart: kube-prometheus-stack
version: ">=55.0.0 <56.0.0"
sourceRef:
kind: HelmRepository
name: prometheus-community
namespace: flux-system
values:
prometheus:
prometheusSpec:
retention: 30d
storageSpec:
volumeClaimTemplate:
spec:
storageClassName: gp3
resources:
requests:
storage: 100Gi
grafana:
enabled: true
adminPassword:
existingSecret: grafana-admin
valuesFrom:
- kind: ConfigMap
name: prometheus-cluster-values
valuesKey: values.yamlchart.spec.version에 SemVer 범위를 지정하면 마이너 버전 업데이트를 자동으로 추적할 수 있습니다. 예를 들어 ">=55.0.0 <56.0.0"은 55.x.x 범위의 최신 버전을 자동으로 가져옵니다.
알림 컨트롤러는 Flux 이벤트를 외부 시스템으로 전달하고, 외부 웹훅을 수신합니다.
apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
name: slack
namespace: flux-system
spec:
type: slack
channel: platform-alerts
secretRef:
name: slack-webhook-url
---
apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Alert
metadata:
name: infra-alerts
namespace: flux-system
spec:
providerRef:
name: slack
eventSeverity: error
eventSources:
- kind: Kustomization
name: '*'
- kind: HelmRelease
name: '*'
exclusionList:
- ".*upgrade.*retries exhausted.*"Flux의 가장 독보적인 기능 중 하나는 이미지 자동 업데이트(Image Auto-Update)입니다. 컨테이너 레지스트리에 새 이미지가 푸시되면 Git 저장소의 매니페스트를 자동으로 업데이트합니다.
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageRepository
metadata:
name: api-server
namespace: flux-system
spec:
image: ghcr.io/org/api-server
interval: 5m
secretRef:
name: ghcr-credentials
---
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
name: api-server
namespace: flux-system
spec:
imageRepositoryRef:
name: api-server
policy:
semver:
range: ">=1.0.0"
filterTags:
pattern: '^(?P<ts>\d+)-(?P<sha>[a-f0-9]{7})$'
extract: '$ts'apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageUpdateAutomation
metadata:
name: api-server-update
namespace: flux-system
spec:
interval: 30m
sourceRef:
kind: GitRepository
name: infra-repo
git:
checkout:
ref:
branch: main
commit:
author:
name: flux-bot
email: flux@example.com
messageTemplate: |
chore: auto-update images
Automation: {{ .AutomationObject }}
Updates:
{{ range .Updated.Images }}
- {{ .Repository }}:{{ .Identifier }}
{{ end }}
push:
branch: main
update:
path: ./apps
strategy: Setters매니페스트에서 업데이트 대상 이미지를 마커 주석으로 지정합니다.
spec:
containers:
- name: api
image: ghcr.io/org/api-server:1.2.3 # {"$imagepolicy": "flux-system:api-server"}두 도구를 프로덕션 관점에서 비교하면 다음과 같습니다.
| 기준 | ArgoCD | Flux |
|---|---|---|
| 아키텍처 | 모놀리식 (단일 배포) | 마이크로컨트롤러 (개별 배포) |
| UI | 풍부한 네이티브 웹 UI | CLI 중심, Weave GitOps UI 별도 |
| 소스 유형 | Git, Helm | Git, Helm, OCI, S3, Bucket |
| 멀티클러스터 | 중앙 집중형 (허브에서 관리) | 분산형 (각 클러스터에 설치) |
| 이미지 자동 업데이트 | 미지원 (Argo Image Updater 별도) | 네이티브 지원 |
| Helm 관리 | Application에서 Helm 소스 지정 | HelmRelease CRD로 선언적 관리 |
| 정책 지원 | AppProject RBAC | Tenant 기반 격리 |
| 확장성 | ApplicationSet, 플러그인 | 컨트롤러 조합, 커스텀 소스 |
ArgoCD를 선택하는 경우:
Flux를 선택하는 경우:
두 도구를 함께 사용하는 하이브리드 전략도 가능합니다. 예를 들어, ArgoCD를 메인 GitOps 도구로 사용하면서 Flux의 Image Automation만 활용하여 이미지 태그 자동 업데이트를 구현하는 패턴이 실무에서 종종 사용됩니다.
Flux 설치는 flux bootstrap 명령으로 시작합니다. 이 명령은 Flux 컴포넌트를 클러스터에 설치하고, Git 저장소에 Flux 자체 매니페스트를 커밋합니다.
# GitHub 저장소로 부트스트랩
flux bootstrap github \
--owner=org \
--repository=fleet-infra \
--branch=main \
--path=clusters/production \
--personal=false \
--components-extra=image-reflector-controller,image-automation-controller부트스트랩 후 생성되는 디렉토리 구조는 다음과 같습니다.
fleet-infra/
clusters/
production/
flux-system/
gotk-components.yaml # Flux 컴포넌트 매니페스트
gotk-sync.yaml # Flux 자체 동기화 설정
kustomization.yaml # Kustomize 엔트리포인트
infrastructure.yaml # 인프라 Kustomization
apps.yaml # 앱 Kustomization
infrastructure/
controllers/ # Ingress, Cert-Manager 등
configs/ # ClusterIssuer, StorageClass 등
apps/
production/ # 프로덕션 앱 매니페스트
staging/ # 스테이징 앱 매니페스트
Flux는 마이크로컨트롤러 아키텍처, 다양한 소스 지원, 네이티브 이미지 자동 업데이트라는 세 가지 차별점을 가진 GitOps 도구입니다. ArgoCD가 직관적인 UI와 중앙 집중형 관리에서 강점을 보인다면, Flux는 유연성과 Kubernetes 네이티브 설계에서 강점을 보입니다.
다음 장에서는 ArgoCD와 Flux를 활용한 멀티클러스터 관리 전략을 살펴보겠습니다. 허브-스포크(Hub-Spoke) 패턴, 메시(Mesh) 패턴 등 다양한 멀티클러스터 토폴로지와 각 도구별 구현 방법을 비교합니다.
이 글이 도움이 되셨나요?
ArgoCD의 내부 아키텍처, Application CRD, 동기화 정책, ApplicationSet을 활용한 멀티클러스터 배포, Argo Rollouts 연동, RBAC과 SSO 설정까지 심층적으로 살펴봅니다.
허브-스포크, 메시 등 멀티클러스터 패턴과 ArgoCD ApplicationSet, Flux Kustomize 오버레이를 활용한 클러스터 플릿 관리 전략을 다룹니다.
Kubernetes 운영이 어떻게 성숙해 왔는지, 그리고 GitOps가 왜 현대 Kubernetes 운영의 핵심 패러다임이 되었는지 살펴봅니다.