Oggi le architetture Kubernetes moderne non si fermano più a un singolo cluster, ma spesso adottano più cluster per rispondere a diverse esigenze, come:

• distribuzione geografica
• alta disponibilità
• separazione degli ambienti (dev, staging, produzione)
• isolamento tra team
• gestione di piattaforme molto grandi

Ma nel momento in cui si passa a una architettura multi-cluster, emerge subito una nuova sfida.

Come facciamo a far comunicare applicazioni distribuite su cluster diversi come se facessero parte dello stesso sistema?

I pod devono poter comunicare tra loro.
I servizi devono essere scoperti globalmente.
Il traffico dovrebbe poter essere bilanciato tra cluster diversi.
E le policy di sicurezza devono continuare a funzionare.

È esattamente questo il problema che Cilium Cluster Mesh cerca di risolvere.

Il problema del Kubernetes multi-cluster

Un singolo cluster Kubernetes fornisce molte funzionalità potenti:

• service discovery
• networking tra pod
• load balancing
• network policy

Il problema è che tutte queste funzionalità sono limitate al cluster.

Se distribuiamo la stessa applicazione su tre cluster, la situazione diventa questa:

Ogni cluster funziona in modo indipendente.

Un frontend nel cluster A non può automaticamente scoprire o raggiungere un backend nel cluster B o C.

I servizi, cosi come le policy sono locali, la rete è locale.

In altre parole: ogni cluster diventa un’isola di rete.

Questo rende molto più complesso costruire:

• servizi multi-region
• sistemi con failover tra cluster
• applicazioni distribuite su larga scala

Ed è qui che entra in gioco Cluster Mesh.

Una breve premessa: cos’è Cilium

Prima di parlare di Cluster Mesh, vale la pena fare un passo indietro e introdurre brevemente Cilium.

In Kubernetes, il networking tra pod non è gestito direttamente dal core del sistema, ma viene delegato a componenti esterni chiamati CNI plugin (Container Network Interface). Questi plugin sono responsabili di fornire funzionalità fondamentali come:

• comunicazione tra pod
• routing del traffico
• gestione degli indirizzi IP
• applicazione delle network policy

Nel corso degli anni sono emersi diversi CNI molto diffusi, come Flannel, Calico, Weave o Canal.

Cilium è uno dei CNI più moderni e innovativi di questo ecosistema. A differenza di molte soluzioni tradizionali basate su iptables, Cilium utilizza eBPF, una tecnologia del kernel Linux che permette di implementare networking, sicurezza e osservabilità in modo molto più efficiente e flessibile.

Grazie a questo approccio, Cilium non si limita a fornire networking tra pod, ma introduce funzionalità avanzate come:

• sicurezza basata su identità dei workload
• osservabilità di rete avanzata
• integrazione con service mesh
• networking multi-cluster

Negli ultimi anni Cilium sta diventando sempre più popolare nell’ecosistema Kubernetes, ed è ormai utilizzato in molte piattaforme cloud e ambienti di produzione.

Si tratta di uno strumento molto ricco e interessante, che meriterebbe un approfondimento dedicato (magari ci dedicheremo un articolo a parte). In questo articolo però ci concentreremo su una delle sue funzionalità più potenti: Cluster Mesh.

Cos’è Cilium Cluster Mesh

Cluster Mesh è una funzionalità di Cilium che permette di collegare più cluster Kubernetes creando un’unica rete logica multi-cluster

L’idea alla base è molto semplice:

• i cluster restano indipendenti
• ma i workload possono scoprirsi e comunicare tra loro

Dal punto di vista delle applicazioni, i pod distribuiti su cluster diversi possono comportarsi come se fossero nello stesso ambiente di rete.

Cosa abilita davvero Cluster Mesh

Comunicazione tra pod di cluster diversi

Con Cluster Mesh, i pod possono comunicare anche se si trovano in cluster differenti. Un pod nel cluster A può raggiungere direttamente un pod nel cluster B.

Questo funziona perché i cluster condividono informazioni su:

• endpoint dei pod
• nodi
• servizi disponibili

Dal punto di vista dell’applicazione, l’infrastruttura semplicemente si espande, invece di diventare più complessa.

Service discovery multi-cluster

Cluster Mesh permette ai cluster di condividere informazioni sui servizi.

Ogni cluster può conoscere:

• quali servizi esistono negli altri cluster
• quali endpoint li compongono
• dove si trovano nella rete

Questo rende possibile avere service discovery distribuito tra cluster.

Global Services e load balancing tra cluster

Una delle funzionalità più interessanti abilitate da Cluster Mesh è la possibilità di distribuire il traffico tra più cluster.

Per capire come funziona, bisogna introdurre prima il concetto di Global Service.

In Kubernetes, un Service è normalmente limitato al cluster in cui è definito. Questo significa che il bilanciamento del traffico avviene solo verso pod presenti nello stesso cluster.

Cilium introduce invece il concetto di Global Service: un Service che può aggregare endpoint provenienti da più cluster della mesh

Quando un Service viene configurato come globale, ogni cluster può vedere non solo i backend locali, ma anche quelli presenti negli altri cluster.

Load balancing tra cluster

Immaginiamo un servizio con backend distribuiti su due cluster.

Senza Cluster Mesh:

Ogni cluster usa solo i propri backend.

Con Cluster Mesh e Global Services invece:

Il servizio può distribuire il traffico verso backend presenti in cluster diversi.

Requisiti per collegare più cluster

Per creare una Cluster Mesh è necessario soddisfare alcuni prerequisiti.

Pod CIDR non sovrapposti

Ogni cluster deve utilizzare range IP diversi per i pod.

Ad esempio:

Cluster 1 → 11.0.0.0/8
Cluster 2 → 12.0.0.0/8

Questo è necessario per evitare conflitti di routing.

Connettività tra i nodi

I nodi dei cluster devono potersi raggiungere tramite rete.

Cluster Mesh non crea la connettività di base, ma la utilizza.

Identità univoca del cluster

Ogni cluster deve avere:

• un cluster name
• un cluster ID

Questo permette ai componenti di Cilium di distinguere l’origine del traffico.

Come i cluster condividono le informazioni

Quando Cluster Mesh viene abilitato, Cilium crea un componente chiamato Cluster Mesh API Server

Questo componente osserva lo stato del cluster e raccoglie informazioni su:

• servizi
• endpoint
• nodi
• identità dei workload

Queste informazioni vengono poi rese disponibili agli altri cluster della mesh.

Grazie a questo meccanismo, ogni cluster può avere una visione degli altri cluster.

Il problema di scalabilità del modello iniziale

Il primo modello di Cluster Mesh funzionava bene in ambienti piccoli.

Ma quando il numero di cluster e nodi cresceva, emergeva un problema.

Immaginiamo:

• 3 cluster
• 100 nodi per cluster
• 1 Cilium agent per nodo

Abbiamo quindi 300 agent.

Nel modello iniziale, ogni agent doveva sincronizzarsi con gli altri cluster per ottenere informazioni su servizi, endpoint e identità.

Questo generava un numero enorme di connessioni di sincronizzazione, con conseguenze come:

• maggiore carico su etcd
• aumento della latenza
• problemi di scalabilità

Serviva un approccio diverso.

La soluzione: KV Store Mesh

Per risolvere il problema è stato introdotto KV Store Mesh. L’idea è spostare la sincronizzazione dai singoli agent ai cluster stessi.

Prima:

Dopo:

agent → cluster locale

cluster datastore ↔ altri cluster datastore

Gli agent parlano solo con il proprio datastore locale, mentre la sincronizzazione avviene tra i datastore dei cluster

Questo riduce drasticamente:

• il numero di connessioni
• il traffico di sincronizzazione
• il carico su etcd

Il risultato è una architettura molto più scalabile.

Sicurezza tra cluster

In un ambiente multi-cluster è fondamentale che le policy di sicurezza possano distinguere l’origine del traffico tra cluster diversi.

Il sistema di networking Cilium permette di applicare policy di rete consapevoli del cluster di origine utilizzando l’etichetta:

io.cilium.k8s.policy.cluster

Questa etichetta identifica da quale cluster proviene il traffico e può essere utilizzata all’interno delle CiliumNetworkPolicy per controllare la comunicazione tra workload distribuiti su cluster differenti.

Un aspetto importante delle policy in Cluster Mesh è che non sono globali:
una policy si applica solo al cluster in cui viene creata. Se si desidera applicare la stessa regola su più cluster, la policy deve essere distribuita manualmente su ciascun cluster.

Esempio 1 – Consentire traffico solo dal frontend

Nel seguente esempio viene definita una policy che consente traffico verso il backend solo dai pod con label app=frontend.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend
spec:
  endpointSelector:
    matchLabels:
      app: my-app
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend

In questo modo:

• i pod frontend possono comunicare con il backend
• tutti gli altri pod vengono bloccati automaticamente

Questo comportamento deriva dal modello default deny di Cilium: quando una policy seleziona un endpoint, tutto il traffico non esplicitamente consentito viene negato.

Esempio 2 – Consentire traffico solo dal frontend di un cluster specifico

È possibile rendere la policy ancora più restrittiva filtrando anche il cluster di origine del traffico.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-from-cluster-one
spec:
  endpointSelector:
    matchLabels:
      app: my-app
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
        io.cilium.k8s.policy.cluster: cluster-one

Con questa configurazione:

• il frontend nel cluster-one può comunicare con il backend
• il frontend presente in altri cluster viene bloccato

Questo consente di applicare controlli di sicurezza granulari in scenari multi-cluster.

Controllo della sicurezza tra cluster

L’utilizzo dell’etichetta io.cilium.k8s.policy.cluster permette quindi di definire policy che tengono conto del cluster di origine del traffico.

Questo rende possibile:

• limitare quali cluster possono comunicare con un determinato servizio
• isolare ambienti diversi (ad esempio produzione e staging)
• implementare modelli di sicurezza zero-trust anche in architetture multi-cluster.

Perché Cluster Mesh è importante

Cluster Mesh non è solo una funzionalità di networking.

È un vero abilitatore architetturale.

Permette di costruire piattaforme Kubernetes distribuite in cui:

• le applicazioni possono scalare su più cluster
• il traffico può essere distribuito tra regioni
• il failover può avvenire automaticamente
• la sicurezza rimane coerente

Il tutto mantenendo i cluster indipendenti dal punto di vista operativo.

Conclusione

Con la crescita delle piattaforme Kubernetes, le architetture multi-cluster stanno diventando sempre più comuni.

Cilium Cluster Mesh offre un modo elegante per collegare questi cluster mantenendo una rete coerente tra workload distribuiti.

Grazie a funzionalità come Global Services e KV Store Mesh, più cluster Kubernetes possono essere trattati come un unico ambiente logico distribuito.

Ed è proprio questo il tipo di infrastruttura di cui le piattaforme cloud-native moderne hanno sempre più bisogno.