Kubernetes Multi-Cloud: federacja, Submariner i ujednolicone zarządzanie
76% organizacji korporacyjnych korzysta z więcej niż jednego dostawcy usług w chmurze (Flexera State of the Chmura 2026). Niektóre, aby uniknąć uzależnienia od dostawcy, inne, aby spełnić wymagania suwerenność danych (RODO: dane europejskie w Europie), jeszcze inne dotyczące odzyskiwania po awarii geograficzne. Rezultatem jest to samo wyzwanie: jak zarządzać wieloma klastrami Kubernetes rozproszone w różnych chmurach, jakby były jedną platformą?
W tym artykule przyjrzymy się strategiom i narzędziom wiele chmur Federacja Kubernetesa: z Okręt podwodny dla sieci międzyklastrowe (pozwól Podom na AWS rozmawiać z Podami na GCP), np Admiralicja/Liqo dla planowania międzyklastrowego, do Menedżer floty e Zestaw aplikacji ArgoCD dla zarządzania deklaratywny dziesiątek klastrów z jednego punktu kontrolnego.
Czego się nauczysz
- Modele wieloklastrowe: aktywny-aktywny, aktywny-pasywny, stowarzyszony
- Submariner: Sieć nakładkowa międzyklastrowa pomiędzy różnymi chmurami
- ServiceExport/ServiceImport z MCS API do wykrywania usług w wielu klastrach
- Zestaw aplikacji ArgoCD z generatorami klastrów do wdrożenia w N klastrach
- KubeAdmiral/Liqo: Inteligentne planowanie obciążenia między klastrami
- Flota Ranczerów: Scentralizowane zarządzanie ponad 1000 klastrów
- Istio wieloklastrowe: ujednolicona siatka usług w różnych klastrach
- Kwestie bezpieczeństwa i zgodności w wielu chmurach K8
Modele architektury wieloklastrowej
Nie ma jednego podejścia do tworzenia wielu klastrów. Wybór zależy od celów:
| Model | Opis | Przypadek użycia |
|---|---|---|
| Hub i szprycha | Klaster koncentrujący zarządza klastrami szprych za pośrednictwem ArgoCD/Flux | Scentralizowane GitOps, zarządzanie polityką |
| Aktywny-aktywny | Wiele aktywnych klastrów, ruch dystrybuowany za pomocą globalnego modułu równoważenia obciążenia | Wysoka dostępność i niskie opóźnienia dla użytkowników na całym świecie |
| Aktywny-Pasywny (DR) | Klaster podstawowy + klaster odzyskiwania po awarii | Ciągłość działania, zdefiniowano RTO/RPO |
| Krawędź + środek | Klaster centralny + klastry brzegowe geograficzne | IoT, logika CDN, bardzo małe opóźnienia |
| Suwerenność danych | Klaster według regionu (UE, USA, APAC) na potrzeby RODO | Zgodność danych z przepisami |
Submariner: Sieć międzyklastrowa
Podstawowym problemem wieloklastrowania jest to, że każdy klaster ma swój własny zakres adresów IP Pody i usługi. Pody w klastrze A nie mogą dotrzeć do Podów w klastrze B, ponieważ sieci są odizolowani. Okręt podwodny rozwiązuje ten problem, tworząc bezpieczną sieć nakładkową pomiędzy klastrami poprzez tunel IPsec lub WireGuard.
Instalacja łodzi podwodnej
# 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 i ServiceImport: wieloklastrowe wykrywanie usług
Gdy Submariner połączy sieci, użyjesz Interfejs API usług wieloklastrowych (MCS). aby wyeksportować usługi z jednego klastra i zaimportować je do innego:
# 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)
Zestaw aplikacji ArgoCD do wdrażania wielu klastrów
Dzięki ArgoCD ApplicationSet i generatorowi klastrów możesz wdrożyć tę samą aplikację na wszystkich klastrach zarejestrowanych w ArgoCD z jednym manifestem:
# 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
Flota ranczerów: zarządzanie ponad 1000 klastrami
Flota Ranczerów (część projektu Rancher) i zaprojektowany z myślą o obsłudze tysiące klastrów z pojedynczą płaszczyzną kontrolną GitOps. I szczególnie przydatne dla obliczeń brzegowych (klastry IoT) oraz dla organizacji posiadających klastry dla każdego klienta:
# 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 Multi-Cluster: ujednolicona siatka usług
Aby umożliwić mTLS i zarządzanie ruchem między usługami w różnych klastrach, Istio obsługuje tryb wielu klastrów ze współdzieloną siatką:
# 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
Globalne równoważenie obciążenia za pomocą Cloudflare i 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
}
Tworzenie kopii zapasowych w wielu klastrach i przywracanie danych po awarii
# 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
Zagadnienia dotyczące bezpieczeństwa w Kubernetesie w wielu chmurach
Lista kontrolna zabezpieczeń wielu chmur
- Poświadczenia izolowanego klastra: Każdy klaster ma własne konto usługi. Nie udostępniaj poświadczeń między klastrami
- Szyfrowana komunikacja między klastrami: Submariner z WireGuard lub IPsec gwarantuje poufność danych przesyłanych pomiędzy klastrami
- Ujednolicone zasady z OPA: Użyj scentralizowanego rejestru OPA/Gatekeeper, aby zapewnić spójne zasady bezpieczeństwa we wszystkich klastrach
- Scentralizowany dziennik audytu: Agreguj dzienniki audytu API ze wszystkich klastrów w centralnym SIEM
- Zarządzanie RODO: Regularnie sprawdzaj, czy dane UE pozostają w klastrach UE, korzystając z zasad sieciowych i powinowactwa węzłów
- Certyfikaty automatycznej rotacji: Dzięki menedżerowi certyfikatów w każdym klastrze zautomatyzuj rotację certyfikatów TLS
Wnioski: Kubernetes na ścieżce Scale
To ostatni artykuł z serii Kubernetes at Scale. W 12 artykułach omówiliśmy Cię pełny zakres operacji Kubernetes dla przedsiębiorstw: od zaawansowanego networkingu z Cilium eBPF, do pamięci masowej ze sterownikami StatefulSet i CSI, do Operatorów do obciążeń stanowych, do autoskalowania w Karpenterze, do obsługi meshu w Istio, do bezpieczeństwa z RBAC i OPA, aż do wielu chmur z Submariner i Federation.
Wielochmurowy Kubernetes to nie cel, ale podróż: zaczynasz od dwóch klastrów (może produkcja + DR), dodano narzędzia takie jak Submariner i ArgoCD ApplicationSet, np skaluje się stopniowo. Kluczem jest budowanie na solidnym fundamencie — bezpiecznej sieci, GitOps zapewniający spójność stanu i ujednoliconą obserwowalność — przed dodaniem złożoność wieloklastrowa.
Cała seria Kubernetes w skali
- 01 - Kubernetes Networking: CNI, Cilium z eBPF i polityką sieciową
- 02 - Pamięć trwała: CSI, PV, StorageClass i StatefulSet
- 03 - Operatory Kubernetes: CRD, wzorzec kontrolera i SDK operatora
- 04 - Autoskalowanie: HPA, VPA, KEDA i Karpenter
- 05 — Service Mesh: Istio vs Linkerd, mTLS i zarządzanie ruchem
- 06 - Bezpieczeństwo: RBAC, standardy bezpieczeństwa kapsuł i strażnik OPA
- 07 — Wielodostępność: przestrzeń nazw, przydział zasobów i HNC
- 08 — Obciążenia AI i GPU: wtyczki urządzeń i zadania szkoleniowe
- 09 - FinOps: Prawa do rozmiaru, instancje punktowe i redukcja kosztów
- 10 — GitOps z ArgoCD: wdrażanie deklaratywne i wdrażanie progresywne
- 11 - Obserwowalność: Prometheus, Grafana i OpenTelemetry
- 12 — Multi-Cloud: Federacja, Submariner i ujednolicone zarządzanie (ten artykuł)
Powiązane serie
- Terraforma i infrastruktura jako kod — wielochmurowe udostępnianie klastrów Kubernetes
- Przetwarzanie brzegowe i bezserwerowe — klaster brzegowy jako rozszerzenie multi-cloud
- DevSecOps — polityka jako kod i jednolite bezpieczeństwo w klastrach wielochmurowych







