12 - Kubernetes Multi-Cloud: Federation, Submariner e Gestione Unificata

Kubernetes Multi-Cloud: Federation, Submariner e Gestione Unificata

Il 76% delle organizzazioni enterprise usa piu di un cloud provider (Flexera State of the Cloud 2026). Alcuni per evitare il vendor lock-in, altri per rispettare requisiti di sovranita dei dati (GDPR: dati europei in Europa), altri ancora per disaster recovery geografica. Il risultato e la stessa sfida: come gestire piu cluster Kubernetes distribuiti su cloud diversi come se fossero un'unica piattaforma?

In questo articolo esploreremo le strategie e gli strumenti per la multi-cloud Kubernetes federation: da Submariner per il networking inter-cluster (permettere ai Pod su AWS di parlare con Pod su GCP), ad Admiralty/Liqo per il scheduling cross-cluster, fino a Fleet Manager e ArgoCD ApplicationSet per la gestione dichiarativa di decine di cluster da un unico punto di controllo.

Modelli di Architettura Multi-Cluster

Non esiste un unico approccio al multi-cluster. La scelta dipende dagli obiettivi:

Submariner: Networking Cross-Cluster

Il problema fondamentale del multi-cluster e che ogni cluster ha il proprio IP range per Pod e Service. I Pod su cluster-A non possono raggiungere Pod su cluster-B perche le reti sono isolate. Submariner risolve questo creando una rete overlay sicura tra cluster tramite tunnel IPsec o WireGuard.

Installazione 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 e ServiceImport: Service Discovery Multi-Cluster

Dopo che Submariner connette le reti, usi la Multi-Cluster Services (MCS) API per esportare Service da un cluster e importarli in un altro:

# 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 per Deploy Multi-Cluster

Con ArgoCD ApplicationSet e il Cluster Generator, puoi deployare la stessa applicazione su tutti i cluster registrati in ArgoCD con un unico 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 Fleet: Gestione di 1000+ Cluster

Rancher Fleet (parte del progetto Rancher) e progettato per gestire migliaia di cluster con un unico piano di controllo GitOps. E particolarmente utile per edge computing (cluster IoT) e per organizzazioni con cluster per ogni cliente:

# 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: Service Mesh Unificato

Per abilitare il mTLS e il traffic management tra servizi su cluster diversi, Istio supporta la modalita multi-cluster con una mesh condivisa:

# 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

Global Load Balancing con Cloudflare e 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 e Disaster Recovery Multi-Cluster

# 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

Considerazioni di Sicurezza nel Multi-Cloud Kubernetes

Conclusioni: Il Percorso Kubernetes at Scale

Questo e l'ultimo articolo della serie Kubernetes at Scale. In 12 articoli abbiamo coperto l'intera gamma delle operazioni Kubernetes enterprise: dal networking avanzato con Cilium eBPF, allo storage con StatefulSet e CSI drivers, agli Operator per i workload stateful, all'autoscaling con Karpenter, al service mesh con Istio, alla sicurezza con RBAC e OPA, fino al multi-cloud con Submariner e Federation.

Il multi-cloud Kubernetes non e una destinazione ma un viaggio: si inizia con due cluster (magari produzione + DR), si aggiungono tool come Submariner e ArgoCD ApplicationSet, e si scala gradualmente. La chiave e costruire su fondamenta solide - networking sicuro, GitOps per la consistenza dello stato, osservabilita unificata - prima di aggiungere complessita multi-cluster.