Kubernetes Çoklu Bulut: Federasyon, Denizaltı ve Birleşik Yönetim
Kurumsal kuruluşların %76'sı birden fazla bulut sağlayıcısı kullanıyor (Flexera Eyaleti) Bulut 2026). Bazıları satıcıya bağımlı kalmayı önlemek için, bazıları ise gereksinimlere uymak için veri egemenliği (GDPR: Avrupa'daki Avrupa verileri), felaket kurtarma için hala diğerleri coğrafi. Sonuç aynı zorluktur: birden fazla Kubernetes kümesinin nasıl yönetileceği sanki tek bir platformmuş gibi farklı bulutlara dağıtılmış mı?
Bu yazıda aşağıdaki stratejileri ve araçları inceleyeceğiz: çoklu bulut Kubernetes federasyonu: itibaren Denizaltı ağ oluşturmak için kümeler arası (AWS'deki Pod'ların GCP'deki Pod'larla konuşmasına izin verin), ör. Amirallik/Liqo kümeler arası planlama için Filo Müdürü e ArgoCD Uygulama Seti yönetim için Tek bir kontrol noktasından onlarca kümenin bildirimi.
Ne Öğreneceksiniz
- Çoklu küme modelleri: aktif-aktif, aktif-pasif, birleştirilmiş
- Submariner: Farklı bulutlar arasındaki kümeler arası katman ağı
- Çoklu küme hizmet keşfi için MCS API ile ServiceExport/ServiceImport
- N kümede dağıtım için küme oluşturuculara sahip ArgoCD ApplicationSet
- KubeAdmiral/Liqo: Akıllı kümeler arası iş yükü planlaması
- Rancher Filosu: 1000'den fazla kümenin merkezi yönetimi
- Çoklu Küme Istio: Farklı kümeler genelinde birleşik hizmet ağı
- K8s çoklu bulutunda güvenlik ve uyumlulukla ilgili hususlar
Çoklu Küme Mimari Modelleri
Çoklu kümelemeye yönelik tek bir yaklaşım yoktur. Seçim hedeflere bağlıdır:
| Modeli | Tanım | Kullanım Örneği |
|---|---|---|
| Hub ve Konuşmacı | Bir hub kümesi, bağlı kümeleri ArgoCD/Flux aracılığıyla yönetir | Merkezi GitOps, politika yönetimi |
| Aktif-Aktif | Birden fazla etkin küme, küresel yük dengeleyiciyle dağıtılan trafik | Küresel kullanıcılar için yüksek kullanılabilirlik, düşük gecikme süresi |
| Aktif-Pasif (DR) | Birincil küme + olağanüstü durum kurtarma kümesi | İş sürekliliği, RTO/RPO tanımlı |
| Kenar + Merkez | Merkezi küme + coğrafi kenar kümeleri | IoT, CDN mantığı, ultra düşük gecikme süresi |
| Veri egemenliği | GDPR için bölgeye göre küme (AB, ABD, APAC) | Düzenleyici veri uyumluluğu |
Submariner: Kümeler Arası Ağ İletişimi
Çoklu kümelemenin temel sorunu, her kümenin kendi IP aralığına sahip olmasıdır. Kapsüller ve Hizmetler. Ağlar nedeniyle A kümesindeki bölmeler B kümesindeki bölmelere ulaşamıyor izole edilmişlerdir. Denizaltı güvenli bir yer paylaşımlı ağ oluşturarak bu sorunu çözer IPsec tüneli veya WireGuard aracılığıyla kümeler arasında.
Denizaltı kurulumu
# 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 ve ServiceImport: Hizmet Keşfi Çoklu Kümesi
Submariner ağlara bağlandıktan sonra, Çoklu Küme Hizmetleri (MCS) API'si Hizmetleri bir kümeden dışa aktarıp diğerine aktarmak için:
# 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)
Çoklu Kümeyi Dağıtmak için ArgoCD ApplicationSet
ArgoCD ApplicationSet ve Cluster Generator ile aynı uygulamayı dağıtabilirsiniz ArgoCD'de kayıtlı tüm kümelerde tek bir bildirimle:
# 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
Çiftçi Filosu: 1000'den Fazla Kümenin Yönetimi
Çiftçi Filosu (Rancher projesinin bir parçası) ve Tek bir GitOps kontrol düzlemine sahip binlerce küme. Ve özellikle yararlı uç bilişim (IoT kümeleri) ve her müşteri için kümeleri olan kuruluşlar için:
# 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 Çoklu Küme: Birleşik Hizmet Ağı
Farklı kümelerdeki hizmetler arasında mTLS ve trafik yönetimini etkinleştirmek için Istio paylaşılan ağ ile çoklu küme modunu destekler:
# 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 ve AWS Global Accelerator ile Küresel Yük Dengeleme
# 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
}
Çoklu Küme Yedekleme ve Felaket Kurtarma
# 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
Çoklu Bulut Kubernetes'te Güvenlik Konuları
Çoklu Bulut Güvenliği Kontrol Listesi
- Yalıtılmış küme kimlik bilgileri: Her kümenin kendi hizmet hesabı vardır. Kimlik bilgilerini kümeler arasında paylaşmayın
- Şifreli kümeler arası iletişim: WireGuard veya IPsec özellikli Submariner, kümeler arasında aktarılan verilerin gizliliğini garanti eder
- OPA ile birleştirilmiş politikalar: Tüm kümelerde tutarlı güvenlik politikaları sağlamak için merkezi bir OPA/Gatekeeper kayıt defteri kullanın
- Merkezi denetim günlüğü: Tüm kümelerdeki API denetim günlüklerini merkezi bir SIEM'de toplayın
- GDPR Yönetişimi: Ağ Politikasını ve düğüm benzeşimini kullanarak AB verilerinin AB kümelerinde kaldığını düzenli olarak test edin
- Otomatik rotasyon sertifikaları: Her kümedeki sertifika yöneticisiyle TLS sertifika rotasyonunu otomatikleştirin
Sonuçlar: Ölçek Yolundaki Kubernetes
Bu, Kubernetes at Scale serisinin son makalesidir. 12 makalede sizi ele alıyoruz Cilium ile gelişmiş ağ oluşturmadan tüm kurumsal Kubernetes işlemlerine kadar eBPF, StatefulSet ve CSI sürücüleri ile depolamaya, durum bilgisi olan iş yükleri için Operatörlere, Karpenter ile otomatik ölçeklendirmeye, Istio ile hizmet ağına, RBAC ve OPA ile güvenliğe, Submariner ve Federasyon ile çoklu buluta kadar.
Çoklu bulut Kubernetes bir hedef değil bir yolculuktur: iki kümeyle başlarsınız (belki üretim + DR), Submariner ve ArgoCD ApplicationSet gibi araçlar eklenir, ör. kademeli olarak ölçeklenir. Önemli olan sağlam bir temel üzerine inşa etmektir: güvenli ağ oluşturma, Durum tutarlılığı ve birleştirilmiş gözlemlenebilirlik için GitOps — eklemeden önce çoklu küme karmaşıklığı.
Ölçekli Kubernetes Serisinin tamamı
- 01 - Kubernetes Ağı: eBPF ve Ağ Politikası ile CNI, Cilium
- 02 - Kalıcı Depolama: CSI, PV, StorageClass ve StatefulSet
- 03 - Kubernetes Operatörleri: CRD, Denetleyici Kalıbı ve Operatör SDK'sı
- 04 - Otomatik ölçeklendirme: HPA, VPA, KEDA ve Karpenter
- 05 - Hizmet Ağı: Istio ve Linkerd, mTLS ve Trafik Yönetimi
- 06 - Güvenlik: RBAC, Pod Güvenlik Standartları ve OPA Ağ Geçidi Bekçisi
- 07 - Çoklu Kiralama: Ad Alanı, Kaynak Kotası ve HNC
- 08 - Yapay Zeka ve GPU İş Yükleri: Cihaz Eklentileri ve Eğitim İşleri
- 09 - FinOps: Doğru Boyutlandırma, Spot Bulut Sunucuları ve Maliyet Azaltma
- 10 - ArgoCD ile GitOps: Bildirime Dayalı Dağıtım ve Aşamalı Sunum
- 11 - Gözlemlenebilirlik: Prometheus, Grafana ve OpenTelemetry
- 12 - Çoklu Bulut: Federasyon, Denizaltı ve Birleşik Yönetim (bu makale)
İlgili Seriler
- Kod Olarak Terraform ve Altyapı — Kubernetes kümelerinin çoklu bulut provizyonu
- Uç Bilgi İşlem ve Sunucusuz — çoklu bulutun bir uzantısı olarak uç küme
- DevSecOps — çoklu bulut kümelerinde kod olarak politika ve tek tip güvenlik







