허브-스포크, 메시 등 멀티클러스터 패턴과 ArgoCD ApplicationSet, Flux Kustomize 오버레이를 활용한 클러스터 플릿 관리 전략을 다룹니다.
2장과 3장에서 ArgoCD와 Flux의 아키텍처를 각각 살펴보았습니다. 실제 프로덕션 환경에서는 단일 클러스터가 아닌 여러 클러스터를 운영하는 경우가 대부분입니다. 개발/스테이징/프로덕션 환경 분리, 리전별 배포, 재해 복구(DR) 등 다양한 이유로 멀티클러스터 전략이 필요합니다. 이번 장에서는 멀티클러스터 관리의 핵심 패턴과 GitOps 도구별 구현 방법을 다루겠습니다.
중앙의 관리 클러스터(허브)에서 여러 워크로드 클러스터(스포크)를 제어하는 패턴입니다. ArgoCD의 기본 멀티클러스터 모델이 이 패턴을 따릅니다.
장점:
단점:
각 클러스터에 GitOps 에이전트를 독립적으로 설치하는 패턴입니다. Flux의 기본 멀티클러스터 모델이 이 패턴을 따릅니다.
장점:
단점:
ArgoCD에서 멀티클러스터를 관리하려면 먼저 스포크 클러스터를 등록해야 합니다.
# CLI로 클러스터 등록
argocd cluster add eks-prod-ap \
--name production-ap \
--kubeconfig ~/.kube/config \
--context eks-prod-ap
# 또는 선언적으로 Secret으로 등록apiVersion: v1
kind: Secret
metadata:
name: production-ap-cluster
namespace: argocd
labels:
argocd.argoproj.io/secret-type: cluster
env: production
region: ap-northeast-2
tier: primary
stringData:
name: production-ap
server: https://ABCDEF.gr7.ap-northeast-2.eks.amazonaws.com
config: |
{
"awsAuthConfig": {
"clusterName": "production-ap",
"roleARN": "arn:aws:iam::123456789012:role/argocd-manager"
}
}등록된 클러스터의 레이블을 기반으로 ApplicationSet을 구성합니다.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: platform-components
namespace: argocd
spec:
goTemplate: true
goTemplateOptions: ["missingkey=error"]
generators:
- clusters:
selector:
matchLabels:
env: production
values:
revision: main
- clusters:
selector:
matchLabels:
env: staging
values:
revision: staging
template:
metadata:
name: 'platform-{{ .name }}'
labels:
env: '{{ .metadata.labels.env }}'
spec:
project: platform
source:
repoURL: https://github.com/org/platform-manifests.git
targetRevision: '{{ .values.revision }}'
path: 'platform/overlays/{{ .metadata.labels.env }}/{{ .metadata.labels.region }}'
destination:
server: '{{ .server }}'
namespace: platform
syncPolicy:
automated:
prune: true
selfHeal: true매트릭스 제너레이터(Matrix Generator)는 여러 제너레이터의 결과를 조합합니다. "모든 프로덕션 클러스터에 특정 앱 목록을 배포"하는 시나리오에 적합합니다.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: tenant-apps
namespace: argocd
spec:
goTemplate: true
generators:
- matrix:
generators:
# 제너레이터 1: 클러스터 목록
- clusters:
selector:
matchLabels:
env: production
# 제너레이터 2: 앱 목록 (Git 디렉토리)
- git:
repoURL: https://github.com/org/app-manifests.git
revision: main
directories:
- path: 'apps/*'
template:
metadata:
name: '{{ .path.basename }}-{{ .name }}'
spec:
project: applications
source:
repoURL: https://github.com/org/app-manifests.git
targetRevision: main
path: '{{ .path.path }}/overlays/{{ .metadata.labels.region }}'
destination:
server: '{{ .server }}'
namespace: '{{ .path.basename }}'
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true매트릭스 제너레이터는 결과의 카르테시안 곱을 생성하므로, 클러스터 수와 앱 수가 많아지면 생성되는 Application 수가 급격히 증가합니다. 예를 들어 10개 클러스터와 50개 앱의 조합은 500개의 Application을 생성합니다. ArgoCD 컨트롤러의 리소스와 조정 주기를 적절히 설정해야 합니다.
Flux는 각 클러스터에 독립적으로 설치되므로, Git 저장소의 디렉토리 구조와 Kustomize 오버레이(Kustomize Overlay)를 활용하여 멀티클러스터를 관리합니다.
fleet-infra/
clusters/
production-ap/
flux-system/ # Flux 자체 동기화
infrastructure.yaml # 인프라 Kustomization 참조
apps.yaml # 앱 Kustomization 참조
production-us/
flux-system/
infrastructure.yaml
apps.yaml
staging/
flux-system/
infrastructure.yaml
apps.yaml
infrastructure/
base/ # 공통 인프라 컴포넌트
ingress-nginx/
cert-manager/
monitoring/
overlays/
production-ap/ # AP 리전 오버레이
production-us/ # US 리전 오버레이
staging/ # 스테이징 오버레이
apps/
base/ # 공통 앱 매니페스트
api-server/
web-frontend/
overlays/
production/ # 프로덕션 오버레이
staging/ # 스테이징 오버레이
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: infrastructure
namespace: flux-system
spec:
interval: 10m
sourceRef:
kind: GitRepository
name: flux-system
path: ./infrastructure/overlays/production-ap
prune: true
wait: true
postBuild:
substitute:
CLUSTER_NAME: production-ap
REGION: ap-northeast-2
ENVIRONMENT: production
substituteFrom:
- kind: Secret
name: cluster-secretsapiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: infrastructure
resources:
- ../../base/ingress-nginx
- ../../base/cert-manager
- ../../base/monitoring
patches:
- target:
kind: HelmRelease
name: ingress-nginx
patch: |
- op: replace
path: /spec/values/controller/replicaCount
value: 3
- op: add
path: /spec/values/controller/service/annotations
value:
service.beta.kubernetes.io/aws-load-balancer-type: nlb
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing대규모 클러스터 플릿을 관리할 때는 단순한 멀티클러스터 배포를 넘어 체계적인 관리 전략이 필요합니다.
개발에서 프로덕션까지 변경사항을 단계적으로 승격하는 파이프라인을 구성합니다.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: promoted-apps
namespace: argocd
spec:
goTemplate: true
generators:
- list:
elements:
- cluster: staging
server: https://staging.example.com
branch: main
autoSync: "true"
- cluster: production-ap
server: https://prod-ap.example.com
branch: release
autoSync: "false"
- cluster: production-us
server: https://prod-us.example.com
branch: release
autoSync: "false"
template:
metadata:
name: 'app-{{ .cluster }}'
spec:
project: applications
source:
repoURL: https://github.com/org/app-manifests.git
targetRevision: '{{ .branch }}'
path: apps/overlays/{{ .cluster }}
destination:
server: '{{ .server }}'
namespace: app
syncPolicy:
automated:
prune: '{{ eq .autoSync "true" }}'
selfHeal: '{{ eq .autoSync "true" }}'멀티클러스터 환경에서는 클러스터 간 설정 드리프트(Configuration Drift)가 발생하기 쉽습니다.
ArgoCD의 app diff 명령이나 Flux의 flux diff kustomization 명령을 CI 파이프라인에서 정기적으로 실행하여 드리프트를 조기에 감지하십시오. 특히 self-heal 옵션이 비활성화된 프로덕션 환경에서는 주기적인 드리프트 점검이 필수입니다.
# ArgoCD: 모든 앱의 동기화 상태 확인
argocd app list -o json | jq '.[] | select(.status.sync.status != "Synced") | {name, status: .status.sync.status}'
# Flux: 모든 Kustomization 상태 확인
flux get kustomizations --all-namespaces --status-selector ready=false일관된 라벨 체계는 멀티클러스터 관리의 기반입니다.
# 권장 라벨 체계
labels:
# 환경
env: production # production | staging | development
# 리전
region: ap-northeast-2 # AWS 리전 코드
# 클라우드 프로바이더
cloud: aws # aws | gcp | azure | on-prem
# 용도
tier: primary # primary | secondary | dr
# 팀/테넌트
team: platform # platform | backend | frontend
# 비용 센터
cost-center: engineering멀티클러스터 관리는 GitOps 도입의 자연스러운 확장입니다. ArgoCD는 허브-스포크 패턴과 ApplicationSet으로 중앙 집중형 관리를, Flux는 메시 패턴과 Kustomize 오버레이로 분산형 관리를 제공합니다. 두 접근 방식 모두 장단점이 있으므로, 조직의 클러스터 규모, 네트워크 구조, 운영 팀 구조에 맞게 선택해야 합니다.
다음 장에서는 Kubernetes의 핵심 확장 메커니즘인 커스텀 컨트롤러와 오퍼레이터 개발을 살펴보겠습니다. Kubernetes 컨트롤러 패턴의 원리를 이해하고, Kubebuilder를 사용하여 실제 오퍼레이터를 구현하는 과정을 다룹니다.
이 글이 도움이 되셨나요?
Kubernetes 컨트롤러 패턴의 원리, 조정 루프, controller-runtime과 Kubebuilder를 활용한 오퍼레이터 개발, CRD 설계 모범 사례를 다룹니다.
Flux의 멀티컨트롤러 아키텍처, 다양한 소스 관리, Kustomization 리소스, 이미지 자동 업데이트 기능을 분석하고 ArgoCD와 비교합니다.
Karpenter의 아키텍처, Cluster Autoscaler와의 비교, NodePool/EC2NodeClass CRD, 통합과 중단 관리, 스팟 인스턴스 전략, GPU 노드 프로비저닝을 다룹니다.