Kubernetes 멀티 클라우드: 페더레이션, Submariner 및 통합 관리
기업 조직의 76%는 둘 이상의 클라우드 제공업체를 사용합니다(Flexera State of the 클라우드 2026). 일부는 공급업체 종속을 방지하기 위한 것이고 일부는 요구 사항을 준수하기 위한 것입니다. 데이터 주권(GDPR: 유럽의 유럽 데이터), 재해 복구를 위한 기타 지리적. 결과는 동일한 과제입니다: 여러 Kubernetes 클러스터를 관리하는 방법 마치 단일 플랫폼인 것처럼 여러 클라우드에 분산되어 있습니까?
이 기사에서는 다음을 위한 전략과 도구를 살펴보겠습니다. 멀티 클라우드 쿠버네티스 페더레이션: 에서 잠수함 네트워킹을 위한 클러스터 간(AWS의 포드가 GCP의 포드와 통신하도록 허용), 예: 애드미럴티/리코 클러스터 간 예약의 경우 최대 함대 관리자 e ArgoCD 애플리케이션 세트 관리를 위해 단일 제어 지점에서 수십 개의 클러스터를 선언합니다.
무엇을 배울 것인가
- 다중 클러스터 모델: 활성-활성, 활성-수동, 페더레이션
- Submariner: 서로 다른 클라우드 간의 클러스터 간 오버레이 네트워크
- 멀티 클러스터 서비스 검색을 위한 MCS API를 사용한 ServiceExport/ServiceImport
- N 클러스터에 배포하기 위한 클러스터 생성기가 포함된 ArgoCD ApplicationSet
- KubeAdmiral/Liqo: 지능형 클러스터 간 워크로드 스케줄링
- Rancher Fleet: 1000개 이상의 클러스터를 중앙 집중식으로 관리
- 멀티 클러스터 Istio: 다양한 클러스터에 걸친 통합 서비스 메시
- K8s 멀티 클라우드의 보안 및 규정 준수 고려 사항
다중 클러스터 아키텍처 모델
다중 클러스터링에 대한 단일 접근 방식은 없습니다. 선택은 목표에 따라 다릅니다.
| 모델 | 설명 | 사용 사례 |
|---|---|---|
| 허브 및 스포크 | 허브 클러스터는 ArgoCD/Flux를 통해 스포크 클러스터를 관리합니다. | 중앙 집중식 GitOps, 정책 관리 |
| 액티브-액티브 | 다중 활성 클러스터, 글로벌 로드 밸런서로 분산된 트래픽 | 글로벌 사용자를 위한 고가용성, 짧은 대기 시간 |
| 액티브-패시브(DR) | 기본 클러스터 + 재해 복구 클러스터 | 비즈니스 연속성, RTO/RPO 정의 |
| 엣지 + 센트럴 | 중앙 클러스터 + 지리적 엣지 클러스터 | IoT, CDN 로직, 초저지연 |
| 데이터 주권 | GDPR을 위한 지역별 클러스터(EU, US, APAC) | 규제 데이터 준수 |
Submariner: 클러스터 간 네트워킹
멀티 클러스터링의 근본적인 문제는 각 클러스터가 고유한 IP 범위를 갖는다는 것입니다. 포드 및 서비스. 클러스터-A의 포드는 클러스터-B의 포드에 도달할 수 없습니다. 그들은 고립되어 있습니다. 잠수함 보안 오버레이 네트워크를 생성하여 이 문제를 해결합니다. IPsec 터널 또는 WireGuard를 통해 클러스터 간.
잠수함 설치
# Installa subctl (CLI di Submariner)
curl -Ls https://get.submariner.io | VERSION=0.17.0 bash
# Pre-requisiti: i cluster devono potersi raggiungere (IP pubblici o VPN)
# Imposta kubeconfig per entrambi i cluster
export KUBECONFIG=~/.kube/cluster-aws:~/.kube/cluster-gcp
# Prepara il cluster broker (uno dei cluster diventa il "broker" di coordinamento)
subctl deploy-broker --kubeconfig ~/.kube/cluster-aws
# Unisci il cluster AWS al broker (il cluster che diventa broker)
subctl join broker-info.subm --kubeconfig ~/.kube/cluster-aws \
--clusterid cluster-aws \
--cable-driver wireguard # WireGuard per performance, IPsec per compatibilita
# Unisci il cluster GCP al broker
subctl join broker-info.subm --kubeconfig ~/.kube/cluster-gcp \
--clusterid cluster-gcp \
--cable-driver wireguard
# Verifica la connessione inter-cluster
subctl show connections # mostra lo stato dei tunnel tra i cluster
subctl verify --kubeconfig ~/.kube/cluster-aws --toconfig ~/.kube/cluster-gcp --verbose
ServiceExport 및 ServiceImport: 서비스 검색 다중 클러스터
Submariner가 네트워크를 연결한 후 멀티 클러스터 서비스(MCS) API 한 클러스터에서 서비스를 내보내고 다른 클러스터로 가져오려면 다음을 수행하세요.
# Nel cluster GCP: esporta il database Service
# ServiceExport rende il Service visibile agli altri cluster
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceExport
metadata:
name: postgres-primary
namespace: data-layer
---
# Nel cluster AWS: il Service appare automaticamente come ServiceImport
# (Submariner lo sincronizza tramite il broker)
# Il Service e raggiungibile come:
# postgres-primary.data-layer.svc.clusterset.local
# Test di connettivita cross-cluster
kubectl run -n app-layer --rm -it test-pod \
--image=postgres:16 \
-- psql -h postgres-primary.data-layer.svc.clusterset.local -U app -d mydb
# SubmarineER gestisce automaticamente il routing del traffico:
# Pod in cluster-aws -> tunnel WireGuard -> Pod in cluster-gcp
# con latenza aggiuntiva ~5-10ms (tunnel overhead)
멀티 클러스터 배포를 위한 ArgoCD ApplicationSet
ArgoCD ApplicationSet 및 Cluster Generator를 사용하면 동일한 애플리케이션을 배포할 수 있습니다. 단일 매니페스트로 ArgoCD에 등록된 모든 클러스터에서:
# Registra i cluster in ArgoCD
argocd cluster add cluster-aws --name production-aws
argocd cluster add cluster-gcp --name production-gcp
argocd cluster add cluster-azure --name production-azure
# Verifica cluster registrati
argocd cluster list
---
# applicationset-multi-cluster.yaml
# Deploya la stessa app su tutti i cluster con label environment=production
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: api-service-global
namespace: argocd
spec:
generators:
# Usa il Cluster Generator: genera un'Application per ogni cluster ArgoCD
- clusters:
selector:
matchLabels:
environment: production # filtra cluster con questo label
template:
metadata:
name: 'api-service-{{name}}' # {{name}} = nome del cluster
labels:
cluster: '{{name}}'
spec:
project: production
source:
repoURL: https://github.com/company/k8s-manifests
targetRevision: main
path: apps/api-service/production
kustomize:
# Personalizzazione per cluster specifici
patches:
- target:
kind: Deployment
name: api-service
patch: |-
- op: replace
path: /spec/replicas
value: '{{metadata.annotations.replicas | default "3"}}'
destination:
server: '{{server}}' # URL API server del cluster
namespace: api-service
syncPolicy:
automated:
prune: true
selfHeal: true
Rancher Fleet: 1000개 이상의 클러스터 관리
랜처 함대 (Rancher 프로젝트의 일부) 처리하도록 설계되었습니다. 단일 GitOps 제어 영역을 갖춘 수천 개의 클러스터. 특히 유용함 엣지 컴퓨팅(IoT 클러스터) 및 각 고객을 위한 클러스터가 있는 조직의 경우:
# Fleet usa il concetto di Bundle: un insieme di manifest da deployare
# e un GitRepo che definisce la sorgente Git
# gitrepo.yaml - registra il repo Git con Fleet
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
name: company-apps
namespace: fleet-default
spec:
repo: https://github.com/company/k8s-manifests
branch: main
paths:
- apps/
targets:
# Deploya su tutti i cluster con label env=production
- name: production
clusterSelector:
matchLabels:
env: production
helm:
values:
replicaCount: 3
resources:
requests:
cpu: 250m
# Configurazione diversa per dev
- name: development
clusterSelector:
matchLabels:
env: development
helm:
values:
replicaCount: 1
---
# Verifica stato deploy su tutti i cluster
kubectl get bundles -A
kubectl get bundledeployments -A | grep -v Healthy # mostra solo problemi
Istio 멀티 클러스터: 통합 서비스 메시
서로 다른 클러스터의 서비스 간 mTLS 및 트래픽 관리를 활성화하려면 Istio 공유 메시를 사용하여 다중 클러스터 모드를 지원합니다.
# Istio multi-cluster con Primary-Remote topology
# Il cluster primario ha il control plane, il remote lo usa
# 1. Installa Istio sul cluster primario
istioctl install --set profile=default \
--set meshConfig.trustDomain=company.com \
--set values.pilot.env.EXTERNAL_ISTIOD=true
# 2. Crea il secret con le credenziali del cluster remote
istioctl x create-remote-secret \
--kubeconfig=~/.kube/cluster-gcp \
--name=cluster-gcp | kubectl apply -f -
# 3. Configura il cluster GCP per usare il control plane AWS
helm install istio-remote manifests/charts/istio-control/istio-discovery \
--set profile=remote \
--set values.global.remotePilotAddress=PILOT_EXTERNAL_IP \
-f kubeconfig.yaml
# Con Istio multi-cluster configurato:
# - mTLS automatico tra servizi su cluster diversi
# - Traffic routing cross-cluster con DestinationRule
# - Kiali mostra la topology completa multi-cluster
# VirtualService per routing intelligente multi-cluster:
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: api-service
spec:
hosts:
- api-service
http:
- route:
# 70% traffico cluster locale (latenza minore)
- destination:
host: api-service.production.svc.cluster.local
port:
number: 8080
weight: 70
# 30% traffico cluster GCP (per load balancing globale)
- destination:
host: api-service.production.svc.clusterset.local # MCS
port:
number: 8080
weight: 30
Cloudflare 및 AWS Global Accelerator를 사용한 글로벌 부하 분산
# DNS-based Global Load Balancing con failover automatico
# Cloudflare Load Balancing con health checks per ogni cluster
# Regola Terraform per configurare il Global LB:
resource "cloudflare_load_balancer" "global_api" {
zone_id = var.cloudflare_zone_id
name = "api.company.com"
fallback_pool_id = cloudflare_load_balancer_pool.aws.id
default_pool_ids = [
cloudflare_load_balancer_pool.aws.id,
cloudflare_load_balancer_pool.gcp.id
]
steering_policy = "geo" # routing geografico
proxied = true
region_pools {
region = "EEU"
pool_ids = [cloudflare_load_balancer_pool.gcp_eu.id]
}
region_pools {
region = "WNAM"
pool_ids = [cloudflare_load_balancer_pool.aws_us.id]
}
}
resource "cloudflare_load_balancer_pool" "aws" {
name = "k8s-aws-production"
origins {
name = "aws-ingress"
address = var.aws_ingress_ip
enabled = true
weight = 1
}
health_check_id = cloudflare_load_balancer_monitor.http.id
}
resource "cloudflare_load_balancer_monitor" "http" {
type = "http"
path = "/health"
expected_codes = "200"
interval = 60
retries = 2
timeout = 5
}
다중 클러스터 백업 및 재해 복구
# Velero per backup cross-cluster
# Installa Velero su tutti i cluster con lo stesso backend S3
helm install velero vmware-tanzu/velero \
--namespace velero \
--create-namespace \
--set configuration.backupStorageLocation[0].name=aws-s3 \
--set configuration.backupStorageLocation[0].provider=aws \
--set configuration.backupStorageLocation[0].bucket=company-k8s-backups \
--set configuration.backupStorageLocation[0].config.region=eu-west-1
# Schedule backup giornaliero
apiVersion: velero.io/v1
kind: Schedule
metadata:
name: daily-backup
namespace: velero
spec:
schedule: "0 2 * * *" # ogni notte alle 2:00
template:
includedNamespaces:
- production
- data-layer
snapshotVolumes: true
ttl: 720h # mantieni per 30 giorni
# Restore su cluster GCP (DR)
velero restore create --from-backup daily-backup-20260901 \
--include-namespaces production \
--kubeconfig ~/.kube/cluster-gcp
멀티 클라우드 Kubernetes의 보안 고려 사항
멀티 클라우드 보안 체크리스트
- 격리된 클러스터 자격 증명: 각 클러스터에는 자체 서비스 계정이 있습니다. 클러스터 간에 자격 증명을 공유하지 마세요.
- 암호화된 클러스터 간 통신: WireGuard 또는 IPsec을 갖춘 Submariner는 클러스터 간에 전송되는 데이터의 기밀성을 보장합니다.
- OPA를 통한 통합 정책: 중앙 집중식 OPA/Gatekeeper 레지스트리를 사용하여 모든 클러스터에서 일관된 보안 정책을 보장합니다.
- 중앙 집중식 감사 로그: 모든 클러스터의 API 감사 로그를 중앙 SIEM으로 집계합니다.
- GDPR 거버넌스: 네트워크 정책 및 노드 선호도를 사용하여 EU 데이터가 EU 클러스터에 남아 있는지 정기적으로 테스트합니다.
- 자동 순환 인증서: 각 클러스터의 cert-manager를 사용하여 TLS 인증서 교체 자동화
결론: 대규모 경로의 Kubernetes
이것은 Kubernetes at Scale 시리즈의 마지막 기사입니다. 12개의 기사에서 우리는 당신을 다뤘습니다. 광범위한 엔터프라이즈 Kubernetes 운영: Cilium을 사용한 고급 네트워킹부터 eBPF, StatefulSet 및 CSI 드라이버가 있는 스토리지, 상태 저장 워크로드를 위한 운영자, Karpenter를 통한 자동 확장, Istio를 통한 서비스 메시, RBAC 및 OPA를 통한 보안, Submariner 및 Federation을 통해 멀티 클라우드까지 가능합니다.
멀티 클라우드 Kubernetes는 목적지가 아니라 여정입니다. 두 개의 클러스터로 시작합니다. (아마도 프로덕션 + DR), Submariner 및 ArgoCD ApplicationSet과 같은 도구가 추가됩니다. 점차적으로 확장됩니다. 핵심은 견고한 기반, 즉 보안 네트워킹, 상태 일관성, 통합 관찰 가능성을 위한 GitOps - 추가 전 다중 클러스터 복잡성.
Scale 시리즈의 전체 Kubernetes
- 01 - Kubernetes 네트워킹: CNI, Cilium(eBPF 및 네트워크 정책 포함)
- 02 - 영구 스토리지: CSI, PV, StorageClass 및 StatefulSet
- 03 - Kubernetes 연산자: CRD, 컨트롤러 패턴 및 연산자 SDK
- 04 - 자동 확장: HPA, VPA, KEDA 및 Karpenter
- 05 - 서비스 메시: Istio 대 Linkerd, mTLS 및 트래픽 관리
- 06 - 보안: RBAC, 포드 보안 표준 및 OPA 게이트키퍼
- 07 - 멀티 테넌시: 네임스페이스, 리소스 할당량 및 HNC
- 08 - AI 및 GPU 워크로드: 장치 플러그인 및 교육 작업
- 09 - FinOps: 규모 조정, 스팟 인스턴스 및 비용 절감
- 10 - ArgoCD를 사용한 GitOps: 선언적 배포 및 점진적 롤아웃
- 11 - 관찰 가능성: Prometheus, Grafana 및 OpenTelemetry
- 12 - 멀티 클라우드: 페더레이션, 잠수함 및 통합 관리(이 문서)
관련 시리즈
- Terraform 및 코드형 인프라 — Kubernetes 클러스터의 다중 클라우드 프로비저닝
- 엣지 컴퓨팅 및 서버리스 — 멀티 클라우드의 확장으로서의 엣지 클러스터
- DevSecOps — 다중 클라우드 클러스터 전반에 걸쳐 코드형 정책 및 균일한 보안







