Kubernetes Multi-Cloud: Federatie, Submariner en Unified Management
76% van de zakelijke organisaties maakt gebruik van meer dan één cloudprovider (Flexera State of the Wolk 2026). Sommige om een ‘vendor lock-in’ te voorkomen, andere om aan de eisen te voldoen datasoevereiniteit (AVG: Europese data in Europa), nog andere voor noodherstel geografisch. Het resultaat is dezelfde uitdaging: hoe beheer je meerdere Kubernetes-clusters? verdeeld over verschillende clouds alsof ze één enkel platform zijn?
In dit artikel zullen we strategieën en hulpmiddelen verkennen multi-cloud Kubernetes-federatie: van Onderzeeër voor netwerken intercluster (sta Pods op AWS toe om met Pods op GCP te praten), b.v Admiraliteit/Liqo voor planning tussen clusters, tot Vlootmanager e ArgoCD-toepassingsset voor beheer declaratief voor tientallen clusters vanuit één enkel controlepunt.
Wat je gaat leren
- Multi-clustermodellen: actief-actief, actief-passief, federatief
- Submariner: Cross-cluster overlay-netwerk tussen verschillende clouds
- ServiceExport/ServiceImport met MCS API voor het ontdekken van services in meerdere clusters
- ArgoCD ApplicationSet met clustergeneratoren voor implementatie op N-clusters
- KubeAdmiral/Liqo: Intelligente werklastplanning tussen clusters
- Rancher Fleet: gecentraliseerd beheer van meer dan 1000 clusters
- Istio met meerdere clusters: uniform servicegaas over verschillende clusters
- Beveiligings- en compliance-overwegingen in de K8s multi-cloud
Architectuurmodellen met meerdere clusters
Er bestaat niet één enkele aanpak voor multiclustering. De keuze hangt af van de doelstellingen:
| Model | Beschrijving | Gebruikscasus |
|---|---|---|
| Naaf en spaak | Een hubcluster beheert spaakclusters via ArgoCD/Flux | Gecentraliseerde GitOps, beleidsbeheer |
| Actief-actief | Meerdere actieve clusters, verkeer verdeeld met wereldwijde load balancer | Hoge beschikbaarheid, lage latentie voor wereldwijde gebruikers |
| Actief-Passief (DR) | Primair cluster + cluster voor herstel na noodgevallen | Bedrijfscontinuïteit, RTO/RPO gedefinieerd |
| Rand + Centraal | Centraal cluster + geografische randclusters | IoT, CDN-logica, ultralage latentie |
| Datasoevereiniteit | Cluster per regio (EU, VS, APAC) voor AVG | Naleving van regelgevingsgegevens |
Submariner: cross-clusternetwerken
Het fundamentele probleem van multi-clustering is dat elk cluster zijn eigen IP-bereik heeft Pods en diensten. Pods op cluster A kunnen de Pods op cluster B niet bereiken vanwege de netwerken ze zijn geïsoleerd. Onderzeeër lost dit op door een veilig overlay-netwerk te creëren tussen clusters via IPsec-tunnel of WireGuard.
Installatie van onderzeeërs
# 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 en ServiceImport: Multicluster voor servicedetectie
Nadat Submariner de netwerken heeft verbonden, gebruikt u de Multi-Cluster Services (MCS)-API om Services uit het ene cluster te exporteren en in een ander cluster te importeren:
# 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 voor implementatie van meerdere clusters
Met ArgoCD ApplicationSet en de Cluster Generator kunt u dezelfde applicatie inzetten op alle clusters geregistreerd in ArgoCD met één 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
Rancher-vloot: beheer van meer dan 1000 clusters
Rancher-vloot (onderdeel van het Rancher-project) en ontworpen om te hanteren duizenden clusters met één enkel GitOps-besturingsvlak. En bijzonder nuttig voor edge computing (IoT clusters) en voor organisaties met clusters per klant:
# 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
Om mTLS en verkeersbeheer tussen services op verschillende clusters mogelijk te maken, heeft Istio ondersteunt de multi-clustermodus met een gedeelde mesh:
# 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
Wereldwijde taakverdeling met Cloudflare en 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
}
Back-up en noodherstel met meerdere clusters
# 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
Beveiligingsoverwegingen bij Multi-Cloud Kubernetes
Multicloud-beveiligingschecklist
- Geïsoleerde clusterreferenties: Elk cluster heeft zijn eigen serviceaccount. Deel geen referenties tussen clusters
- Gecodeerde communicatie tussen clusters: Submariner met WireGuard of IPsec garandeert de vertrouwelijkheid van gegevens tijdens de overdracht tussen clusters
- Uniform beleid met OPA: Gebruik een gecentraliseerd OPA/Gatekeeper-register om een consistent beveiligingsbeleid voor alle clusters te garanderen
- Gecentraliseerd auditlogboek: Verzamel API-auditlogboeken van alle clusters in een centrale SIEM
- AVG-beheer: Test regelmatig of EU-gegevens in EU-clusters blijven met behulp van netwerkbeleid en knooppuntaffiniteit
- Automatische rotatiecertificaten: Met cert-manager op elk cluster kunt u de rotatie van TLS-certificaten automatiseren
Conclusies: De Kubernetes op schaalpad
Dit is het laatste artikel in de Kubernetes at Scale-serie. In 12 artikelen hebben wij u gedekt het volledige scala aan zakelijke Kubernetes-bewerkingen: van geavanceerd netwerken met Cilium eBPF, naar opslag met StatefulSet- en CSI-stuurprogramma's, naar operators voor stateful workloads, naar automatisch schalen met Karpenter, naar service mesh met Istio, naar beveiliging met RBAC en OPA, tot multi-cloud met Submariner en Federation.
Multi-cloud Kubernetes is geen bestemming maar een reis: je begint met twee clusters (misschien productie + DR), tools zoals Submariner en ArgoCD ApplicationSet worden toegevoegd, b.v het schaalt geleidelijk. De sleutel is om voort te bouwen op een solide basis: veilig netwerken, GitOps voor statusconsistentie, uniforme observatie – vóór het toevoegen complexiteit van meerdere clusters.
De volledige Kubernetes bij Scale Series
- 01 - Kubernetes-netwerken: CNI, Cilium met eBPF en netwerkbeleid
- 02 - Persistente opslag: CSI, PV, StorageClass en StatefulSet
- 03 - Kubernetes-operators: CRD, controllerpatroon en operator SDK
- 04 - Automatisch schalen: HPA, VPA, KEDA en Karpenter
- 05 - Service Mesh: Istio versus Linkerd, mTLS en verkeersbeheer
- 06 - Beveiliging: RBAC, Pod-beveiligingsnormen en OPA Gatekeeper
- 07 - Multi-tenancy: naamruimte, resourcequota en HNC
- 08 - AI- en GPU-workloads: apparaatplug-ins en trainingstaken
- 09 - FinOps: rightsizing, spotinstances en kostenreductie
- 10 - GitOps met ArgoCD: declaratieve implementatie en progressieve uitrol
- 11 - Waarneembaarheid: Prometheus, Grafana en OpenTelemetry
- 12 - Multi-Cloud: Federatie, Submariner en Unified Management (dit artikel)
Gerelateerde serie
- Terraform en infrastructuur als code — multi-cloud-provisioning van Kubernetes-clusters
- Edge-computing en serverloos — edge cluster als verlengstuk van multi-cloud
- DevSecOps — policy-as-code en uniforme beveiliging in multi-cloudclusters







