26O12a

QK·4일 전

기본 원칙: 사이트 단위로 자율, 사이트 간은 느슨하게

사이트 내(저지연): 클러스터 간 강하게 결합합니다. Cluster Mesh, 동기 복제, 같은 사이트 내 failover가 여기에 속합니다.
사이트 간(WAN): 비동기와 약결합으로 갑니다. 한 사이트가 고립돼도 그 사이트는 독립적으로 동작해야 합니다.

클러스터 역할별 도구

클러스터	핵심 도구
Management (Argo CD, Jenkins, Keycloak, Observability)	사이트별 Argo CD, Keycloak 사이트 내 이중화
Compute ×N	Cilium Cluster Mesh + (필요 시) Karmada로 배치/failover
GPU	Kueue + MultiKueue (Karmada보다 적합)
Storage	외부 스토리지 클러스터 + 사이트 간 비동기 복제

1. 통신 (Cilium)

사이트 내 모든 클러스터는 Cluster Mesh로 연결하고, KVStoreMesh를 켜세요.
사이트 간은 요약 경로만 BGP로 교환하고, 필요한 서비스(Keycloak 동기화 엔드포인트, 스토리지 복제, 관측성 수집)만 선택적으로 노출하세요. 모든 클러스터를 한 메시로 묶으면 ID 상한과 장애 전파가 부담이 됩니다. (일반적인 설계 권고)

2. 관리 클러스터와 Keycloak

Keycloak은 같은 사이트의 서로 다른 클러스터 2곳에 배포하세요(예: Management A + Management B 또는 Compute 1곳). 공식 가이드의 멀티클러스터 구성은 쿠버네티스 클러스터 장애를 견디는 것이 목적입니다. 단, 요구사항이 중요합니다.

DB와 외부 Infinispan의 동기 복제를 위해 저지연 네트워크가 필요하므로, 사이트 내에서만 active-active로 구성하세요. 사이트 간까지 늘리는 것은 비추천입니다.
사이트 간은 Keycloak을 사이트별로 독립 운영하고 realm/DB는 비동기 복제 또는 active-passive DR로 두는 편이 안전합니다(일반적인 판단).
공식 블루프린트는 Infinispan을 Gossip Router로 연결하며, 클러스터 간 직접 네트워크 연동은 고려 대상에서 제외합니다. Cluster Mesh로 풀기보다 가이드의 구성을 따르세요.

Argo CD는 사이트별로 두세요. WAN 단절 시에도 사이트가 자체 배포/복구를 할 수 있습니다. Git은 사이트별 미러를 두고, 이중화된 Argo CD(또는 2개 클러스터에 분산)로 SPOF를 줄입니다. 관측성은 클러스터 에이전트 → 사이트 중앙(Thanos/Mimir/Loki) → 글로벌 조회 계층으로 구성하세요.

3. 워크로드 배치

Compute 클러스터 2개 이상: 사이트 내 failover가 필요한 앱에만 Karmada를 쓰세요. 그 외에는 Argo CD ApplicationSet으로 충분합니다. Karmada는 사이트별로 두어 WAN 의존을 피하는 것을 권합니다(일반 권고).
GPU: MultiKueue를 쓰세요. v0.9에서 베타가 되었고 v0.13에 디스패처 프레임워크가 도입되어 정책 기반 분산이 가능합니다. 중앙 컨트롤플레인이 전역 자원 가용성을 보고 워커 클러스터로 잡을 보냅니다. GPU 사이트 간 자원 활용에도 좋습니다. 배치(학습) 위주면 특히 적합합니다.

4. 스토리지와 데이터 페더레이션 (일반적인 설계 원칙)

컴퓨트/GPU 클러스터는 스토리지 클러스터를 외부 스토리지로 소비(CSI 또는 S3 엔드포인트)하세요. Ceph를 쓴다면 Rook 외부 클러스터 모드가 후보입니다.
사이트 간 복제는 데이터 유형별로 나눕니다. 객체는 멀티사이트 복제, 블록은 미러링, 파일은 비동기 스냅샷이 일반적입니다. 대용량 데이터는 옮기기보다 데이터가 있는 사이트로 잡을 보내는 것(data gravity)이 기본입니다. 이 부분은 MultiKueue/Karmada 배치 정책에 데이터 위치를 반영하세요.
메타데이터/카탈로그(어느 데이터가 어디에 있는지)를 글로벌로 두면 페더레이션이 쉬워집니다.
DB는 앞서 말씀드린 대로 주 리전 쓰기 + 비동기 복제 + 외부 PITR 백업을 기본으로 하세요.

5. 장애 시나리오

장애	기대 동작
클러스터 1개	같은 사이트 다른 클러스터의 Keycloak 등이 계속 서비스. Compute는 Karmada/Argo가 재배치
Management 전체	기존 워크로드는 계속 동작, 새 배포만 중단 → Argo CD 이중화로 완화
사이트 간 WAN 단절	각 사이트 자율 운영 (Failover 폭주를 막도록 대기 시간 넉넉히)
사이트 전체	DR 사이트로 수동/반자동 승격 (DB, Keycloak, 스토리지)

도입 순서

사이트별 IP/ASN, 사이트 요약 경로 설계 + Cluster Mesh(사이트 내)
사이트별 Argo CD 이중화 + Keycloak 사이트 내 2클러스터 구성
GPU 클러스터에 Kueue → 이후 MultiKueue
스토리지 사이트 간 복제 + 관측성 중앙화
필요해지면 Karmada, 이후 신규 클러스터부터 CAPI

Keycloak은 사이트 간 DR을 어느 정도(RPO/RTO)로 원하시는지, 그리고 스토리지는 Ceph인지 다른 솔루션인지 알려주시면 구체적인 복제 구성으로 이어서 설명드리겠습니다.

===

한 줄 요약

Kueue는 한 클러스터 안에서 "잡을 언제 시작할지" 결정하고, MultiKueue는 그 결정을 여러 클러스터로 확장해 "어느 클러스터에서 돌릴지"까지 정합니다. MultiKueue는 별도 제품이 아니라 Kueue의 멀티클러스터 기능입니다.

비교

항목	Kueue	MultiKueue
범위	단일 클러스터	매니저 1개 + 워커 N개
역할	잡 레벨 관리자로, 잡을 시작(Pod 생성 허용)할 시점과 중지할 시점을 결정	여유 용량을 찾아 메인 클러스터의 부하를 덜어주는 멀티클러스터 잡 디스패치
핵심 기능	팀별 쿼터, 우선순위 큐, 유휴 용량 빌려쓰기(borrowing), GPU 종류별 flavor	위 기능 + 워커 선택, 클러스터 간 공정 분배
지원 워크로드	Job, JobSet, KubeRay, Kubeflow Trainer, LeaderWorkerSet 등	Kueue가 관리하는 워크로드(연동 종류는 버전별 확인)
성숙도	안정적, 널리 사용	v0.9에서 베타, v0.13에서 디스패처 프레임워크 도입

MultiKueue 동작 방식

사용자는 매니저 클러스터에 평소처럼 잡을 제출합니다. 라벨이나 클러스터 지정 없이 제출하는 것이 특징입니다.
매니저에서 쿼터를 통과하면 워커 클러스터를 선택하고, 그곳에 복제본(mirror)을 생성합니다.
예를 들어 TrainJob은 매니저에서는 Pod 생성을 건너뛰고, 실제 연산은 선택된 워커의 복제본에서 일어납니다.

모든 클러스터에 Kueue가 설치되어야 하고, 매니저가 워커의 kubeconfig로 접근하는 구조입니다(일반적인 구성 방식).

현재 환경에서의 선택

사이트당 GPU 클러스터 1개: Kueue만 써도 충분합니다. 팀별 GPU 쿼터, 우선순위, 유휴 GPU 공유가 핵심 가치입니다.
GPU 클러스터가 2개 이상, 또는 사이트 간 GPU 공유가 필요: MultiKueue를 추가하세요. 클러스터 하나에 큰 잡이 들어갈 자리가 없을 때 원격 클러스터에서 자동 실행되는 시연이 소개된 바 있습니다.
도입 순서: Kueue 먼저 → 쿼터 체계 안정화 → MultiKueue로 확장

주의점 (일반적인 설계 관점)

매니저가 잡 제출의 단일 진입점이 됩니다. 매니저가 죽어도 이미 실행 중인 잡은 워커에서 계속 돌지만, 신규 제출은 막히니 이중화를 고려하세요. 사이트별 매니저를 두면 WAN 의존을 피할 수 있습니다.
데이터 위치: 잡이 다른 사이트로 가면 데이터도 필요합니다. 데이터가 있는 사이트의 워커로만 보내도록 정책을 구성하세요.
워커마다 GPU 종류가 다르면 flavor를 정확히 정의해야 의도한 곳에 배치됩니다.
서빙(추론) 워크로드: Kueue 자체는 Deployment 같은 서빙도 다룰 수 있지만, MultiKueue의 주 용도는 배치/학습입니다. 서빙의 멀티클러스터 배치와 failover는 Karmada나 Gateway 쪽이 더 적합합니다.
멀티클러스터 UX 개선은 2026년 Kueue의 우선 과제로 올라 있으니, 최신 릴리스 노트를 확인하고 PoC로 검증하세요.

GPU 워크로드가 학습 위주인지 추론(서빙) 위주인지 알려주시면 Kueue/MultiKueue와 Karmada의 역할 분담을 더 구체적으로 정리해드리겠습니다.

===

결론: 요즘은 네트워크 계층(통신)과 관리 계층(배포/라이프사이클)을 분리해서 각각 표준 도구를 고르는 게 대세입니다. 과거의 "KubeFed식 단일 federation"은 사실상 퇴장했습니다. (KubeFed는 아카이브됨)

1. 클러스터 간 통신

요구	추천
같은 리전/사설망, 성능 우선	Cilium Cluster Mesh: 별도 멀티클러스터 게이트웨이 없이 크로스 클러스터 연결, 로드밸런싱, 정책 적용이 가능
mTLS, L7 트래픽 제어, 관측성 필요	Istio: KubeCon EU 2026에서 사이드카 없는 ambient 멀티클러스터가 베타로 발표되어 운영 부담이 줄어드는 중
클러스터 L3 터널만 필요	Submariner
관리 권한이 없는 클러스터 간 연결, 간편함	Skupper

Red Hat의 성능 비교에 따르면 Submariner는 낮고 일정한 지연, Istio는 높은 처리량, Skupper는 설정 용이성이 강점입니다. 또 Submariner는 관리자 권한과 클러스터 내부 접근을 전제로 하고 보안 정책 기능이 서비스 메시보다 제한적입니다.

서비스 디스커버리는 벤더 종속을 피하려면 MCS API(ClusterSet)와 Gateway API 멀티클러스터 확장 같은 표준 방향으로 가는 게 좋습니다. Multi-Cluster Gateway API는 커뮤니티가 새로운 표준으로 인식하는 방향입니다.

2. 클러스터 관리

라이프사이클: Cluster API(CAPI)로 생성/업그레이드를 선언적으로 관리
배포: Argo CD ApplicationSets 또는 Flux로 GitOps 팬아웃. 중앙 컨트롤플레인 없이 Git이 기준점
워크로드 배치/스케줄링: Karmada. 2026년 9월 CNCF Graduated 프로젝트가 되었고, AI 학습 잡의 멀티 컴포넌트 스케줄링도 강화됨. 대안은 OCM(정책/거버넌스 강점), Rancher Fleet(UI 필요 시), Azure 환경이면 KubeFleet 기반 Fleet Manager
관측성/정책: 클러스터 라벨을 붙인 중앙 Prometheus/Thanos 또는 OTel, Kyverno/OPA로 정책 통일

3. 원거리 사이트 federation 시 주의점

아래는 출처 기반이 아닌 일반적인 설계 원칙입니다.

컨트롤플레인은 클러스터별로 독립시키세요. 하나의 etcd나 컨트롤플레인을 WAN으로 늘리면 안 됩니다. Cilium Cluster Mesh처럼 클러스터별 컨트롤플레인 + 상태 동기화 구조가 WAN에 적합합니다.
로컬 우선 라우팅(예: service.cilium.io/affinity: local)을 기본으로 하고, 원격은 장애 시 failover로만 쓰세요. 매 요청이 WAN을 타면 지연과 egress 비용이 커집니다.
언더레이: Pod/Service CIDR을 겹치지 않게 설계하고, 사이트 간은 IPsec/WireGuard VPN 또는 전용선으로 연결합니다. 퍼블릭 인터넷이면 Istio east-west gateway나 Skupper처럼 게이트웨이/L7 터널 방식이 현실적입니다.
데이터 계층은 별도 설계: 상태 저장 서비스는 네트워크만으론 해결되지 않으므로 DB 자체의 멀티리전 복제 전략이 필요합니다.
mTLS 신뢰 루트 공유: 공통 루트 CA에서 클러스터별 중간 CA를 발급하세요.

구성 순서

1. MCS 구현체 선택 (Gateway 구현체와 짝이 맞아야 함)

Cilium: MCS-API 지원이 베타이며, Cilium Gateway API 구현체는 자체 MCS-API 구현과 완전히 호환됩니다.
GKE: MCS 컨트롤러가 ServiceExport/ServiceImport를 관리하고 멀티클러스터 Gateway가 이를 사용합니다.
AWS: Gateway API Controller는 MCS 표준이 아닌 자체 ServiceImport 리소스로 통합합니다.

2. 각 클러스터에서 서비스 export (Service와 이름/네임스페이스가 같아야 함)

apiVersion: multicluster.x-k8s.io/v1beta1
kind: ServiceExport
metadata:
  name: store
  namespace: shop

Service와 ServiceExport 쌍이 존재하면 컨트롤러가 fleet 내 모든 클러스터에 대응하는 ServiceImport를 배포합니다.

3. HTTPRoute에서 ServiceImport를 백엔드로 지정

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store
  namespace: shop
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - backendRefs:
    - group: multicluster.x-k8s.io
      kind: ServiceImport
      name: store
      port: 8080

이렇게 하면 여러 클러스터에 흩어진 Pod 집합으로 트래픽이 분산됩니다.

4. 클러스터 내부 호출용 DNS (선택)
앱끼리 직접 호출하려면 store.shop.svc.clusterset.local을 사용합니다. 이를 위해 CoreDNS에 clusterset 설정이 필요합니다. Cilium은 MCS-API용 CoreDNS 설정 단계를 별도로 안내합니다.

주의점

구현체 호환성: Cilium Gateway는 ServiceImport에 연결된 기반 Service가 있고 multicluster.kubernetes.io/derived-service 어노테이션이 있는 MCS 구현만 지원합니다. 다른 Gateway 구현체와 섞어 쓰려면 해당 구현체의 GEP-1748 지원 여부를 확인하세요.
구현체별 제약: AWS 컨트롤러는 ServiceImport를 HTTPRoute로만 지원하고 직접 트래픽 전송은 지원하지 않으며, backendRef의 포트 값도 무시합니다. 포트는 ServiceExport 어노테이션으로 지정합니다.
WAN 환경: 가중치/지역 우선 라우팅이 구현체마다 다릅니다. 원거리 사이트라면 로컬 클러스터 우선 + 장애 시 원격 failover가 되는지(Cilium은 서비스 affinity 어노테이션) 꼭 확인하세요. 이 부분은 일반적인 설계 권고입니다.
성숙도: MCS API는 아직 알파/베타 단계라 프로덕션 도입 전 PoC로 검증하는 게 안전합니다.

Cilium, Istio, GKE/EKS 중 어떤 환경이신가요? 알려주시면 해당 구현체 기준 설정 예시를 더 구체적으로 드리겠습니다.

===

Karmada(Kubernetes Armada)는 여러 클러스터를 하나의 Kubernetes API처럼 다루면서 어느 클러스터에 워크로드를 몇 개 배치할지 정책으로 결정해주는 멀티클러스터 오케스트레이터입니다. 2026년 9월 CNCF Graduated 프로젝트가 되었습니다.

구조

별도의 컨트롤플레인(Karmada API Server, Controller Manager, Scheduler)이 자체 etcd를 두고 상태를 관리합니다. 사용자는 평범한 Deployment 같은 표준 매니페스트를 Karmada API에 제출하고, 배치 규칙은 별도 정책 리소스로 분리합니다. 그래서 기존 YAML을 거의 수정하지 않고 단일 클러스터에서 멀티클러스터로 확장할 수 있습니다. 멤버 클러스터에는 Push 방식(직접 접근) 또는 Pull 방식(에이전트 설치)으로 연결합니다. 방화벽 뒤 원거리 사이트는 Pull 방식이 유리합니다(일반적인 설계 권고).

핵심 API 두 가지

PropagationPolicy: 정책과 워크로드를 1:n으로 매핑하며, 클러스터 어피니티, 멀티클러스터 분할/재조정, 리전/AZ/클러스터/프로바이더 단위 HA 같은 제약을 정의합니다. 네임스페이스 범위 리소스는 PropagationPolicy, 클러스터 범위는 ClusterPropagationPolicy를 씁니다.
OverridePolicy: 원본 템플릿을 건드리지 않고 클러스터별 설정을 바꿉니다. 예를 들어 리전별 이미지 레지스트리 접두사나 클라우드별 StorageClass를 교체할 수 있습니다.

복제본 스케줄링 방식

Duplicated는 대상 클러스터마다 요청한 복제본 수 전체를 배치하고, Divided는 복제본을 클러스터들에 나눠 배치합니다. Divided에서는 가중치 기반 정적 분배나 클러스터 가용 자원을 반영한 동적 분배를 선택할 수 있습니다.

예시 (직접 작성한 샘플)

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: web-policy
spec:
  resourceSelectors:
  - apiVersion: apps/v1
    kind: Deployment
    name: web
  placement:
    clusterAffinity:
      clusterNames: [seoul, busan, tokyo]
    replicaScheduling:
      replicaSchedulingType: Divided
      replicaDivisionPreference: Weighted
      weightPreference:
        staticWeightList:
        - targetCluster: {clusterNames: [seoul]}
          weight: 2
        - targetCluster: {clusterNames: [busan, tokyo]}
          weight: 1

필드 이름은 버전에 따라 다를 수 있으니 사용 버전의 문서로 확인하세요.

장애 대응(Failover)

클러스터 장애 시 다른 클러스터로 워크로드를 옮기는 기능이 있습니다. 한 가이드는 장애 판단 후 tolerationSeconds: 300처럼 대기 시간을 두고 failover하는 설정을 예시로 듭니다. 원거리 사이트에서는 일시적인 WAN 단절로 불필요한 이동이 일어날 수 있으니, 이 값을 넉넉하게 잡는 게 좋습니다. 한 분석 글도 failover storm(장애 이동 폭주)을 운영 리스크로 지적합니다.

다른 도구와 조합

GitOps(Argo CD/Flux)와 병행: Flux는 GitOps 조정 루프를, Karmada는 지능형 워크로드 분배와 failover를 맡는 조합이 소개됩니다. Git에 앱과 정책을 두고 Karmada API로 동기화하는 구조입니다.
네트워크: Karmada는 배치만 담당하므로 서비스 간 통신은 앞서 말씀드린 Cilium Cluster Mesh, Istio, MCS API가 필요합니다.

도입 전 고려사항

컨트롤플레인 자체가 HA 대상입니다. 자체 etcd를 운영해야 하므로 호스트 클러스터를 이중화하세요.
클러스터 수가 적으면 과할 수 있습니다. 2~3개 클러스터에 고정 배치라면 ApplicationSet + Kustomize 오버레이로 충분한 경우가 많습니다. 반면 동적 분산, 자동 failover, 리전 간 재조정이 필요하면 Karmada의 가치가 큽니다.
Karmada의 CRD가 다루지 못하는 커스텀 리소스는 별도 ResourceInterpreter 설정이 필요할 수 있습니다.

원하시면 사용 중인 환경(클러스터 수, 사이트 간 RTT, GitOps 도구)에 맞춰 Karmada 도입 구성안이나 Argo CD 연동 방식을 정리해드리겠습니다.

===

왜 네트워크만으론 안 되나

Cluster Mesh나 Istio는 "원격 DB에 접속할 수 있는 길"만 열어줍니다. 데이터를 어느 지역에 두고, 어떻게 복제하고, 장애 시 누가 쓰기 권한을 가질지는 DB 자체의 문제입니다. 또 PV(디스크)는 클러스터 간에 이동되지 않기 때문에, 워크로드는 Karmada로 옮길 수 있어도 데이터는 따라가지 않습니다.

먼저 정할 것

RPO(허용 데이터 유실)와 RTO(복구 시간)
쓰기가 한 곳이면 충분한지, 여러 지역에서 동시에 써야 하는지
동기 복제를 감수할 수 있는 지연 (거리가 멀수록 트랜잭션마다 RTT만큼 느려짐. 서울-도쿄 수십 ms, 서울-미국 서부 100ms대가 일반적인 수준)

복제 패턴 3가지

패턴	특징	적합한 경우
Active-Passive (비동기 복제)	쓰기는 주 리전 1곳, 타 리전은 읽기/DR용. 장애 시 승격하며 약간의 유실 가능(RPO>0)	대부분의 업무 시스템, 가장 흔하고 단순
동기 복제 / 합의 기반 분산 DB	유실 없음(RPO≈0), 대신 쓰기 지연 증가. CockroachDB, YugabyteDB, Spanner류	금융 등 무손실 요구, 리전 간 RTT가 짧은 경우
Active-Active (멀티 마스터)	지역별 로컬 쓰기, 충돌 해결 필요	쓰기 지연 최소화가 필수. 설계 난이도 가장 높음

K8s 위의 PostgreSQL 예 (CloudNativePG)

복제 클러스터(replica cluster)는 다른 리전의 다른 Kubernetes 클러스터에 두는 것이 일반적이며, 이를 "분산 토폴로지"라고 부릅니다.
계획된 전환(switchover)은 기존 primary를 demote한 뒤 replica 클러스터를 promote하면 되고, 이전 primary를 다시 복제할 필요가 없습니다.
단, 클러스터 간 자동 failover는 오퍼레이터가 단일 Kubernetes 클러스터 안에서만 동작하기 때문에 범위 밖입니다. 즉 리전 간 승격은 사람이나 별도 자동화(예: GitOps 파이프라인, 헬스체크 + 승인 흐름)가 트리거해야 합니다.
분산 클러스터에서는 어느 시점이든 primary가 하나만 존재할 수 있습니다. 그래서 split-brain 방지가 핵심입니다.
멀티 리전 active-active는 별도 솔루션 영역입니다. 예를 들어 pgEdge는 CloudNativePG 위에서 Spock 기반 active-active 복제로 여러 리전에 분산 Postgres를 배포하는 Helm 차트를 제공합니다.

데이터 유형별 일반적인 접근 (일반 지식)

Kafka: 클러스터별 독립 운영 + MirrorMaker 2 등으로 토픽 복제(주로 비동기). 컨슈머 오프셋 동기화 방식을 같이 설계해야 합니다.
Redis/캐시: 지역별 독립 캐시가 기본. 공유가 꼭 필요한 데이터만 별도 복제합니다.
객체 스토리지(S3, MinIO): 버킷 복제 기능 사용.
검색(Elasticsearch/OpenSearch): Cross-cluster replication 또는 원본 DB에서 지역별로 재색인.

운영 시 체크리스트

읽기는 로컬, 쓰기는 주 리전으로 앱에서 분리 (read replica 엔드포인트 사용)
Fencing: 장애 난 구 primary가 되살아나도 쓰지 못하도록 격리 (split-brain 방지)
Failover 훈련: 실제로 전환 시간(RTO)과 유실량(RPO)을 측정하고 정기적으로 리허설
백업은 별도: 복제는 백업이 아닙니다. 잘못된 DELETE도 즉시 복제되므로 PITR 백업을 다른 리전 객체 스토리지에 두세요.
앱 failover 연동: DB 승격 후 앱의 연결 대상 전환(DNS/Service 변경)을 자동화
복제 지연 모니터링과 경보

핵심 전제

Native routing + BGP이면 Pod IP가 이미 언더레이에서 라우팅되므로, Cluster Mesh에서는 Pod 트래픽을 터널링하지 않고 라우팅으로 그대로 전달하게 됩니다. 이 방식은 BGP가 VXLAN 오버레이보다 성능이 좋고, 별도 메시 설정 없이 컨테이너 IP를 라우팅 가능하게 만든다는 장점이 있습니다. 대신 IP 설계와 BGP 경계 설계가 전부입니다.

1. Cluster Mesh 필수 조건

모든 클러스터와 노드의 PodCIDR이 겹치지 않아야 하고, 각 클러스터의 native routing CIDR이 연결된 모든 클러스터의 PodCIDR을 포함해야 합니다.
모든 클러스터가 같은 데이터패스 모드(터널 또는 라우팅)를 써야 합니다. 일부만 VXLAN을 쓰는 혼합 구성은 피하세요.
클러스터별 cluster.name / cluster.id는 고유해야 합니다. 클러스터 수가 많으면 ID 상한(기본 255, 설정으로 확대 가능)을 버전 문서에서 확인하세요.

2. IP / ASN 설계 (가장 먼저)

전사 Pod CIDR 대역을 하나 정하고(예: 10.0.0.0/8) 클러스터마다 큰 블록(예: /16)을 할당하세요. 이러면 native routing CIDR을 한 줄로 쓸 수 있고, WAN에는 클러스터 단위 요약 경로만 흘릴 수 있습니다.
Service/LB IP 대역도 클러스터별로 분리하세요.
ASN은 클러스터(또는 사이트)별 프라이빗 ASN으로 나누고, 사이트 간은 eBGP로 구성하는 것이 일반적입니다.

3. BGP / ECMP 운영 (일반적인 설계 권고)

Cilium BGP Control Plane(v2)로 노드가 ToR과 피어링하고, PodCIDR과 LoadBalancer IP를 광고합니다.
노드별 /24 경로를 WAN으로 새지 않게 하고, 사이트 경계 라우터에서 클러스터 요약 경로만 광고하세요. 경로 수와 flap 영향을 줄입니다.
경계에는 prefix 필터와 max-prefix를 두세요. Pod CIDR이 라우팅되므로 BGP 오광고 하나가 여러 클러스터의 장애로 번질 수 있습니다.
ECMP는 flow 단위 해시라 문제없지만 비대칭 경로와 MTU를 점검하세요. BFD로 링크 장애를 빨리 감지하고, Graceful Restart로 Cilium 재시작 시 경로 유실을 줄입니다.
서비스 LB는 필요하면 Maglev + DSR 조합을 고려하세요.

4. Cluster Mesh 컨트롤플레인

clustermesh-apiserver는 LoadBalancer, NodePort, ClusterIP 서비스로 다른 클러스터에 노출합니다. BGP 환경이면 LoadBalancer IP를 BGP로 광고하는 방식이 깔끔합니다.
KVStoreMesh를 켜세요. Cluster Mesh의 확장성을 개선하는 기능입니다. 원거리 사이트 간 직접 연결 수와 의존성도 줄어듭니다.
클러스터 간 mTLS용 CA는 공통으로 관리하세요.

5. 원거리 사이트 추가 고려

암호화: native routing은 기본적으로 평문입니다. 사이트 간 구간은 IPsec/MACsec 전용 링크를 쓰거나 Cilium 투명 암호화(WireGuard)를 적용하세요. 오버헤드만큼 MTU를 조정해야 합니다.
로컬 우선: 글로벌 서비스에 로컬 affinity를 적용해 평상시에는 사이트 내부로만 트래픽이 가고, 장애 시에만 원격으로 넘어가게 하세요.
서비스 디스커버리는 Global Service 어노테이션 또는 앞서 설명한 MCS API(+Gateway API)를 쓰세요.

6. 관리 방안

영역	추천
클러스터 생성/업그레이드	Cluster API
Cilium 설정	하나의 Helm 베이스 values + 클러스터별 오버라이드(name/id/CIDR/ASN)를 Git으로 관리
배포	Argo CD ApplicationSet(Cluster generator)
배치/failover	Karmada (필요 시)
관측성	Hubble + 클러스터 라벨 포함 Prometheus/Grafana 중앙 집계
정책	CiliumNetworkPolicy를 클러스터 인지형으로 작성 + Kyverno/OPA

운영 팁:

Cilium 업그레이드는 클러스터를 하나씩 진행하고, 버전 skew 허용 범위를 릴리스 노트에서 확인하세요.
연결 점검은 cilium clustermesh status와 cilium connectivity test --multi-cluster로 자동화하세요.
BGP 설정 변경도 GitOps로 관리하고 canary 클러스터에 먼저 적용하세요.

현실적인 3가지 경로

1. 신규 클러스터부터 CAPI로 생성 (가장 안전, 권장)
Management 클러스터를 새로 만들고, 앞으로 생성하는 클러스터만 CAPI로 관리합니다. 기존 클러스터는 건드리지 않고, 교체 시점에 워크로드를 신규 CAPI 클러스터로 옮겨 점진적으로 대체합니다. 앞서 말씀드린 Karmada/GitOps 배치와도 잘 맞습니다.

2. 기존 클러스터를 CAPI 리소스로 "입양" (프로바이더별로 다름)

관리형(AKS 등): CAPZ는 기존 AKS 클러스터를 입양하는 방법을 문서화하고 있으며, 기존 클러스터를 설명하는 CAPI/CAPZ 매니페스트를 만들어 management 클러스터에 생성하는 방식입니다. 다만 CAPZ webhook이 기본값을 채워 기존 클러스터와 맞지 않을 수 있으니 주의해야 합니다.
자체 구축형(kubeadm, 온프렘/베어메탈): 가능은 하지만 고난도입니다. 사례로는 Mercedes-Benz가 OpenStack 프로바이더로 수백 개 클러스터를 이전한 경험이 있고, 관련 PoC 저장소가 단계별(인프라 → 컨트롤플레인 → 워커) 마이그레이션을 시연합니다. 핵심 아이디어는 "CAPI로 만든 클러스터와 동일한 상태의 리소스를 먼저 구성한 뒤 고아 클러스터를 단계적으로 흡수"하는 것입니다. 이 방식은 위험이 있으니 반드시 테스트 환경에서 리허설하세요.

3. 라이프사이클은 기존 방식 유지, "관리"만 통합
Cluster API 대신 Argo CD, Karmada, Rancher 같은 도구에 기존 클러스터를 등록해 배포/정책/관측만 통합합니다. 생성/업그레이드는 기존 도구(Kubespray, Ansible 등)에 맡깁니다. 위험이 가장 낮습니다.

어떤 걸 고를까

상황	추천
클러스터를 곧 교체/증설할 계획	1번 (신규부터 CAPI)
관리형 K8s(AKS/EKS/GKE) 위주	2번 (프로바이더의 adopt 기능 확인)
온프렘 자체 구축, 수가 적고 안정적	3번 + 신규만 CAPI
온프렘 자체 구축, 수십 개 이상	2번 PoC 검토 (투자 필요)

도입 시 체크포인트

온프렘/베어메탈: 프로바이더가 필요합니다. 일반적으로 Metal3(베어메탈), vSphere, OpenStack 등이며, 기존 인프라에 맞는 프로바이더 성숙도를 먼저 확인하세요.
Management 클러스터 HA: CAPI의 단일 장애점이 되므로 별도 이중화와 백업(clusterctl move로 다른 management로 이전 가능)을 준비하세요.
Cilium(native/BGP) 연동: CAPI의 ClusterResourceSet 또는 Argo CD로 Cilium과 BGP 설정을 자동 배포하고, 클러스터별 PodCIDR/ASN은 템플릿 변수로 관리하세요. ClusterClass를 쓰면 표준화에 좋습니다.
버전 호환: CAPI, 프로바이더, Kubernetes의 지원 매트릭스를 확인하세요.

좋아지는 점

단일 진입점: 클러스터마다 배포하던 것을 Karmada API 한 곳에 제출하면 됩니다. 앱 매니페스트는 그대로 두고 배치 규칙만 따로 둡니다.
선언적 배치: PropagationPolicy로 클러스터 어피니티, 분할/재조정, 리전·AZ·클러스터·프로바이더 단위 HA를 정의합니다. "서울 2 : 부산 1" 같은 분산이 정책 한 장으로 끝납니다.
클러스터별 차이 흡수: OverridePolicy로 원본 템플릿을 건드리지 않고 리전별 이미지 레지스트리나 StorageClass 같은 설정을 바꿉니다. 사이트마다 달라지는 값(Ingress, LB IP 대역, 레지스트리 등)을 분리하기 좋습니다.
자동 failover: 클러스터 장애 시 다른 클러스터로 워크로드를 이동합니다. 한 가이드는 대기 시간(tolerationSeconds)을 두고 failover하는 설정을 예시로 듭니다. 수동 대응이 줄어듭니다.
동적 스케줄링: Duplicated(전체 복제)와 Divided(분할) 모드를 지원하고, 클러스터 가용 자원을 반영한 분배도 가능합니다. GPU 같은 자원이 사이트별로 다를 때 유용합니다.
Cilium 환경과 궁합: Cluster Mesh/MCS로 통신을 해결하고 Karmada는 배치만 맡는 역할 분담이 깔끔합니다. 기존 클러스터는 등록(join)만 하면 되어 재구축이 필요 없습니다. 방화벽 뒤 사이트는 Pull 모드(에이전트)가 유리합니다.
표준 API 유지: Karmada는 쿠버네티스 API를 그대로 쓰므로 나중에 빼더라도 매니페스트는 재사용할 수 있습니다.

CAPI 없이 남는 한계

클러스터 생성/업그레이드/노드 교체는 여전히 수동 또는 기존 도구(Ansible, Kubespray 등)입니다. 버전 편차와 설정 드리프트가 쌓일 수 있으니 관리 절차를 표준화해 두세요.
Karmada가 새로운 관리 대상이 됩니다. 자체 컨트롤플레인(API 서버, etcd 등)이 생기므로 이중화와 백업이 필요합니다. 이게 장애 나도 기존 워크로드는 각 클러스터에서 계속 돌지만, 새 배포와 failover 판단은 멈춥니다(일반적인 설계 특성).
네트워크와 데이터는 해결하지 못합니다. 통신은 Cilium Cluster Mesh, 데이터는 DB 자체 복제 전략이 따로 필요합니다.
Failover 폭주 위험: failover storm(장애 이동 폭주)이 운영 리스크로 지적됩니다. 원거리 WAN 단절 시 오작동하지 않도록 대기 시간을 넉넉히 두고, 데이터가 있는 워크로드는 자동 이동에서 제외하세요.

도입 팁

작게 시작: 상태 없는(stateless) 앱 몇 개를 PoC로 Karmada에 올리세요. 기존 배포 방식은 병행 유지합니다.
GitOps와 결합: Git에는 앱과 Karmada 정책을 두고, Argo CD/Flux가 Karmada API로 동기화하는 구조가 일반적입니다.
정책 범위 제한: 처음에는 failover를 끄고 배치/오버라이드만 쓰다가, 검증 후 켜세요.
CRD 호환 확인: 쓰는 커스텀 리소스(오퍼레이터 등)가 Karmada에서 올바르게 전파/상태 수집되는지 확인하세요.
나중에 CAPI 추가 가능: 라이프사이클 자동화가 필요해지는 시점에 신규 클러스터부터 도입하면 됩니다.

판단 기준

클러스터 수가 적고(2~5개) 고정 배치면 → Argo CD ApplicationSet + Kustomize 오버레이만으로도 충분할 수 있습니다.
동적 분산, 자동 failover, 사이트 간 재조정, 멀티클러스터 GPU 스케줄링이 필요하면 → Karmada 도입 가치가 큽니다.

현재 클러스터 수와 가장 풀고 싶은 문제(배포 통합, failover, 자원 분산 중 무엇인지)를 알려주시면 Karmada가 필요한지, Argo CD만으로 충분한지 더 구체적으로 판단해드리겠습니다.

engineer

이전 포스트

26O07n2

다음 포스트