Karmada — 멀티 클러스터 페더레이션 3리전 페일오버 프로덕션 | 기술노트

핵심 요약

Karmada 1.10으로 서울·도쿄·싱가포르 3리전 EKS를 페더레이션. PropagationPolicy로 워크로드 배포, FailoverPolicy로 리전 장애 시 30s 내 자동 페일오버. 멀티 클러스터 운영에서 발생하던 manifest 중복 95% 제거, 리전 다운 시 다운타임 0.

1. 아키텍처

┌─ Karmada Control Plane (별도 클러스터 또는 SaaS)
├─ EKS Seoul (member)
├─ EKS Tokyo (member)
└─ EKS Singapore (member)

중앙 컨트롤 플레인이 멤버 클러스터에 propagation. 멤버는 일반 K8s.

2. PropagationPolicy

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
spec:
  resourceSelectors:
  - apiVersion: apps/v1
    kind: Deployment
    name: api
  placement:
    clusterAffinity: { clusterNames: [seoul, tokyo, singapore] }
    replicaScheduling:
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
        - targetCluster: { clusterNames: [seoul] }
          weight: 5
        - targetCluster: { clusterNames: [tokyo] }
          weight: 3
        - targetCluster: { clusterNames: [singapore] }
          weight: 2

10 replica를 5:3:2 분산. 트래픽 분포에 맞춰.

3. FailoverPolicy — 리전 장애

apiVersion: policy.karmada.io/v1alpha1
kind: FailoverPolicy
spec:
  application:
    decisionConditions: { tolerationSeconds: 30 }
    purgeMode: Graciously
    gracePeriodSeconds: 60

30s 응답 없는 리전의 replica를 다른 리전으로 자동 재배치.

4. 트래픽 라우팅

Karmada가 K8s 리소스 페더레이션만 담당. DNS·트래픽은 외부(Route53 geolocation, CloudFlare Argo). 응답 못 받는 리전은 health check 실패로 자연 제외 + Karmada가 워크로드 회수.

5. 함정

모든 리소스가 페더레이션 대상은 아님 — Secret, ConfigMap은 별도 OverridePolicy
StatefulSet 페일오버는 데이터 동기화 외부 필요(Vitess, Cassandra, Aurora Global)
네트워크 비용 — 멀티 리전 데이터 송수신 폭증, 주의

6. 관측

Karmada metrics을 Prometheus로 수집, 멀티 클러스터 Grafana 대시보드. 멤버 클러스터 health, propagation 성공률, failover 발생 횟수가 핵심.

7. 결정 가이드

단일 리전 모놀리식 → Karmada 불필요
2개 이상 리전, 같은 워크로드 → Karmada
StatefulSet 중심 → Karmada + 외부 데이터 동기화 필수

자주 묻는 질문

Q. ClusterAPI와 차이? ClusterAPI는 클러스터 자체 프로비저닝, Karmada는 워크로드 페더레이션. 보통 함께 사용.