Kubernetes Multi-Cloud: Federație, Submariner și Management unificat
76% dintre organizațiile întreprinderilor folosesc mai mult de un furnizor de cloud (Flexera State of the Cloud 2026). Unele pentru a evita blocarea furnizorilor, altele pentru a respecta cerințele suveranitatea datelor (GDPR: date europene în Europa), încă altele pentru recuperarea în caz de dezastru geografice. Rezultatul este aceeași provocare: cum să gestionați mai multe clustere Kubernetes distribuite pe nori diferiți ca și cum ar fi o singură platformă?
În acest articol vom explora strategii și instrumente pentru multi-nori Federația Kubernetes: din Submariner pentru networking inter-cluster (permite Pods pe AWS să vorbească cu Pods pe GCP), de ex Amiraalitate/Liqo pentru programarea cross-cluster, până la Manager de flotă e ArgoCD ApplicationSet pentru management declarativ de zeci de clustere dintr-un singur punct de control.
Ce vei învăța
- Modele multi-cluster: activ-activ, activ-pasiv, federat
- Submariner: rețea de suprapunere încrucișată între diferiți nori
- ServiceExport/ServiceImport cu MCS API pentru descoperirea serviciilor multi-cluster
- ArgoCD ApplicationSet cu generatoare de cluster pentru implementare pe N clustere
- KubeAdmiral/Liqo: programare inteligentă a sarcinilor de lucru între clustere
- Flota fermieră: gestionarea centralizată a peste 1000 de grupuri
- Istio multi-cluster: Mesh de servicii unificate în diferite clustere
- Considerații de securitate și conformitate în multi-cloud K8s
Modele de arhitectură multi-cluster
Nu există o abordare unică pentru multi-clustering. Alegerea depinde de obiective:
| Model | Descriere | Caz de utilizare |
|---|---|---|
| Hub și Spoke | Un cluster hub gestionează clusterele de spițe prin ArgoCD/Flux | GitOps centralizat, managementul politicilor |
| Activ-Activ | Mai multe clustere active, trafic distribuit cu echilibrator global de încărcare | Disponibilitate ridicată, latență scăzută pentru utilizatorii globali |
| Activ-Pasiv (DR) | Cluster primar + cluster de recuperare în caz de dezastru | Continuitatea afacerii, definit de RTO/RPO |
| Edge + Central | Cluster central + clustere de margine geografică | IoT, logica CDN, latență ultra-scăzută |
| Suveranitatea datelor | Cluster în funcție de regiune (UE, SUA, APAC) pentru GDPR | Conformitatea datelor de reglementare |
Submariner: Cross-Cluster Networking
Problema fundamentală a multi-clustering-ului este că fiecare cluster are propriul interval IP pentru Poduri și servicii. Pod-urile de pe cluster-A nu pot ajunge la Pod-urile de pe cluster-B, deoarece rețelele sunt izolate. Submariner rezolvă acest lucru prin crearea unei rețele suprapuse securizate între clustere prin tunel IPsec sau WireGuard.
Instalare submariner
# 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: Service Discovery Multi-Cluster
După ce Submariner conectează rețelele, utilizați API-ul Multi-Cluster Services (MCS). pentru a exporta Servicii dintr-un cluster și a le importa în altul:
# 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 pentru Implementarea Multi-Cluster
Cu ArgoCD ApplicationSet și Cluster Generator, puteți implementa aceeași aplicație pe toate clusterele înregistrate în ArgoCD cu un singur manifest:
# 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 fermieră: gestionarea a peste 1000 de clustere
Flota fermieră (parte a proiectului Rancher) și conceput pentru a se ocupa mii de clustere cu un singur plan de control GitOps. Și deosebit de util pentru edge computing (clustere IoT) și pentru organizațiile cu clustere pentru fiecare client:
# 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
Pentru a activa mTLS și gestionarea traficului între servicii de pe diferite clustere, Istio acceptă modul multi-cluster cu o plasă partajată:
# 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
Echilibrare globală a sarcinii cu 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
}
Backup multi-cluster și recuperare în caz de dezastru
# 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
Considerații de securitate în Multi-Cloud Kubernetes
Lista de verificare a securității multi-cloud
- Acreditări de cluster izolate: Fiecare cluster are propriul cont de serviciu. Nu partajați acreditările între grupuri
- Comunicare inter-cluster criptată: Submariner cu WireGuard sau IPsec garantează confidențialitatea datelor în tranzit între clustere
- Politici unificate cu OPA: Utilizați un registru centralizat OPA/Gatekeeper pentru a asigura politici de securitate coerente în toate clusterele
- Jurnal de audit centralizat: Agregați jurnalele de audit API din toate clusterele într-un SIEM central
- Guvernare GDPR: Testați în mod regulat dacă datele UE rămân în clustere UE, utilizând Politica de rețea și afinitatea nodurilor
- Certificate de rotație automată: Cu certificat-manager pe fiecare cluster, automatizați rotația certificatelor TLS
Concluzii: Calea Kubernetes la scară
Acesta este ultimul articol din seria Kubernetes at Scale. În 12 articole vă avem acoperit gama completă de operațiuni Kubernetes pentru întreprinderi: de la rețele avansate cu Cilium eBPF, către stocare cu drivere StatefulSet și CSI, către operatori pentru sarcini de lucru cu stare, la autoscaling cu Karpenter, la service mesh cu Istio, la securitate cu RBAC și OPA, până la multi-cloud cu Submariner și Federation.
Multi-cloud Kubernetes nu este o destinație, ci o călătorie: începeți cu două clustere (poate producție + DR), instrumente precum Submariner și ArgoCD ApplicationSet sunt adăugate, de ex se scala treptat. Cheia este să construiți pe o bază solidă - o rețea sigură, GitOps pentru consistența stării, observabilitate unificată - înainte de adăugare complexitate multi-cluster.
Întreaga serie Kubernetes la scară
- 01 - Kubernetes Networking: CNI, Cilium cu eBPF și Network Policy
- 02 - Stocare persistentă: CSI, PV, StorageClass și StatefulSet
- 03 - Operatori Kubernetes: CRD, Controller Pattern și Operator SDK
- 04 - Autoscaling: HPA, VPA, KEDA și Karpenter
- 05 - Service Mesh: Istio vs Linkerd, mTLS și gestionarea traficului
- 06 - Securitate: RBAC, Pod Security Standards și OPA Gatekeeper
- 07 - Multi-Tenancy: Namespace, Resource Quota și HNC
- 08 - Sarcini de lucru AI și GPU: pluginuri pentru dispozitive și locuri de muncă de instruire
- 09 - FinOps: dimensionare drepturi, instanțe spot și reducere a costurilor
- 10 - GitOps cu ArgoCD: implementare declarativă și lansare progresivă
- 11 - Observabilitate: Prometheus, Grafana și OpenTelemetry
- 12 - Multi-Cloud: Federație, Submariner și Management Unificat (acest articol)
Serii înrudite
- Terraform și infrastructura ca cod — furnizarea multi-cloud a clusterelor Kubernetes
- Edge Computing și Serverless — edge cluster ca o extensie a multi-cloud
- DevSecOps — politică ca cod și securitate uniformă în clustere multi-cloud







