Kubernetes Multi-Cloud: Federace, ponorka a sjednocená správa
76 % podnikových organizací využívá více než jednoho poskytovatele cloudu (Flexera State of the Cloud 2026). Některé proto, aby se vyhnuly uzamčení dodavatele, jiné kvůli splnění požadavků datová suverenita (GDPR: evropská data v Evropě), další pro obnovu po havárii zeměpisné. Výsledkem je stejná výzva: jak spravovat více clusterů Kubernetes distribuovány napříč různými cloudy, jako by byly jedinou platformou?
V tomto článku prozkoumáme strategie a nástroje pro multi-cloud federace Kubernetes: od Ponorník pro vytváření sítí inter-cluster (umožňuje Pods na AWS mluvit s Pods na GCP), např Admiralita/Liqo pro plánování napříč skupinami až Fleet Manager e Sada aplikací ArgoCD pro řízení deklarativní o desítkách shluků z jednoho kontrolního bodu.
Co se naučíte
- Multi-clusterové modely: aktivní-aktivní, aktivní-pasivní, federované
- Submariner: Překryvná síť napříč skupinami mezi různými mraky
- ServiceExport/ServiceImport s MCS API pro zjišťování víceklastrových služeb
- ArgoCD ApplicationSet s generátory clusterů pro nasazení na N clusterech
- KubeAdmiral/Liqo: Inteligentní plánování pracovní zátěže napříč clustery
- Rancher Fleet: Centralizovaná správa 1000+ klastrů
- Multi-cluster Istio: Sjednocená síť služeb napříč různými clustery
- Aspekty zabezpečení a souladu v multicloudu K8s
Modely architektury s více clustery
Neexistuje jediný přístup k multi-shlukování. Výběr závisí na cílech:
| Model | Popis | Use Case |
|---|---|---|
| Hub a Spoke | Hub cluster spravuje paprskové clustery přes ArgoCD/Flux | Centralizované GitOps, správa zásad |
| Aktivní-Aktivní | Více aktivních clusterů, provoz distribuovaný pomocí globálního nástroje pro vyrovnávání zatížení | Vysoká dostupnost, nízká latence pro globální uživatele |
| Aktivně-pasivní (DR) | Primární cluster + cluster pro obnovu po havárii | Kontinuita podnikání, definováno RTO/RPO |
| Hrana + střed | Centrální shluk + geografické okrajové shluky | IoT, CDN logika, ultra nízká latence |
| Datová suverenita | Seskupení podle regionu (EU, USA, APAC) pro GDPR | Dodržování regulačních údajů |
Submariner: Cross-Cluster Networking
Základním problémem multi-clusteringu je, že každý cluster má svůj vlastní rozsah IP adres Pody a služby. Pody na clusteru-A nemohou dosáhnout podů na clusteru-B, protože sítě jsou izolováni. Ponorník to řeší vytvořením zabezpečené překryvné sítě mezi clustery prostřednictvím tunelu IPsec nebo WireGuard.
Instalace ponorky
# 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 a ServiceImport: Multi-Cluster zjišťování služeb
Poté, co Submariner připojí sítě, použijete Multi-Cluster Services (MCS) API exportovat služby z jednoho clusteru a importovat je do jiného:
# 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)
Sada aplikací ArgoCD pro nasazení více clusterů
S ArgoCD ApplicationSet a Cluster Generator můžete nasadit stejnou aplikaci na všech clusterech registrovaných v ArgoCD s jedním 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
Rančerská flotila: Správa 1000+ klastrů
Rančerská flotila (součást projektu Rancher) a navržený tak, aby zvládl tisíce clusterů s jedinou řídicí rovinou GitOps. A zvláště užitečné pro edge computing (IoT clustery) a pro organizace s clustery pro každého zákazníka:
# 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: Unified Service Mesh
Chcete-li povolit mTLS a správu provozu mezi službami v různých clusterech, Istio podporuje režim více clusterů se sdílenou sítí:
# 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
Globální vyrovnávání zátěže pomocí Cloudflare a 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
}
Multi-Cluster Backup a Disaster Recovery
# 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
Bezpečnostní aspekty v Multi-Cloud Kubernetes
Kontrolní seznam zabezpečení pro více cloudů
- Přihlašovací údaje izolovaného clusteru: Každý cluster má svůj vlastní servisní účet. Nesdílejte přihlašovací údaje mezi clustery
- Šifrovaná komunikace mezi clustery: Submariner s WireGuard nebo IPsec zaručuje důvěrnost dat při přenosu mezi clustery
- Sjednocené zásady s OPA: Použijte centralizovaný registr OPA/Gatekeeper k zajištění konzistentních zásad zabezpečení ve všech clusterech
- Centralizovaný protokol auditu: Agregujte protokoly auditu API ze všech clusterů do centrální SIEM
- GDPR Governance: Pravidelně testujte, zda data EU zůstávají v klastrech EU, pomocí síťových zásad a afinity uzlů
- Certifikáty automatické rotace: Pomocí správce certifikátů v každém clusteru automatizujte rotaci certifikátů TLS
Závěry: Kubernetes v měřítku cesty
Toto je poslední článek ze série Kubernetes at Scale. Ve 12 článcích jsme vás probrali celá řada podnikových operací Kubernetes: od pokročilých sítí s Ciliem eBPF, na úložiště s ovladači StatefulSet a CSI, na operátory pro stavové úlohy, na automatické škálování s Karpenter, na servisní síť s Istio, na zabezpečení s RBAC a OPA, až po multi-cloud s Submariner a Federation.
Multicloud Kubernetes není cíl, ale cesta: začínáte se dvěma clustery (možná výroba + DR), jsou přidány nástroje jako Submariner a ArgoCD ApplicationSet, např. postupně se to škáluje. Klíčem je stavět na pevných základech – zabezpečené sítě, GitOps pro konzistenci stavu, jednotnou pozorovatelnost — před přidáním víceshluková složitost.
Celá řada Kubernetes at Scale Series
- 01 - Kubernetes Networking: CNI, Cilium s eBPF a síťová politika
- 02 - Trvalé úložiště: CSI, PV, StorageClass a StatefulSet
- 03 - Operátoři Kubernetes: CRD, Controller Pattern a Operator SDK
- 04 - Automatické škálování: HPA, VPA, KEDA a Karpenter
- 05 - Service Mesh: Istio vs Linkerd, mTLS a Traffic Management
- 06 - Zabezpečení: RBAC, bezpečnostní standardy pod a OPA Gatekeeper
- 07 - Multi-Tenancy: Namespace, Resource Quota a HNC
- 08 - Pracovní zátěže AI a GPU: Zásuvné moduly zařízení a školicí úlohy
- 09 - FinOps: Rightsizing, spotové instance a snižování nákladů
- 10 - GitOps s ArgoCD: Deklarativní nasazení a progresivní zavádění
- 11 - Pozorovatelnost: Prometheus, Grafana a OpenTelemetry
- 12 - Multi-Cloud: Federation, Submariner a Unified Management (tento článek)
Související série
- Terraform a infrastruktura jako kód — multi-cloud poskytování clusterů Kubernetes
- Edge Computing a bez serveru — edge cluster jako rozšíření multi-cloudu
- DevSecOps — policy-as-code a jednotné zabezpečení napříč multi-cloudovými clustery







