Casi d'uso di rete tra cluster per Azure Kubernetes Fleet Manager (anteprima)

La rete tra cluster per Azure Kubernetes Fleet Manager (Fleet) è un'offerta gestita basata su Cilium Cluster Mesh che consente di stabilire comunicazioni dirette da pod a pod tra più cluster Servizio Azure Kubernetes (AKS). Creando una rete tra cluster, è possibile abilitare la connettività est-ovest senza la necessità di gateway, ottenendo al tempo stesso l'osservabilità multi-cluster e l'applicazione coerente della sicurezza.

Architettura e funzionalità

In una configurazione di rete tra cluster, una rete virtuale flat consente ai pod in cluster diversi di instradare il traffico direttamente attraverso i limiti del cluster. A ogni cluster vengono in genere assegnate due subnet: una per i nodi e una per i pod. Questa architettura coerente garantisce che la rete pod rimanga piatta nella rete tra cluster, senza l'uso di sovrimpressioni o tunnel.

Diagramma dell'architettura di Azure Kubernetes Fleet Manager che gestisce la connettività east-west tra cluster. I pod in cluster diversi comunicano direttamente tramite gli agenti Cilium attraverso reti virtuali con peering.

I componenti e le funzionalità principali per questo scenario includono:

  • Azure CNI con piano dati Cilium: entrambi i cluster AKS devono usare Azure CNI con Azure CNI basato sul piano dati Cilium.
  • Advanced Container Networking Services (ACNS): acns deve essere abilitato nei cluster per supportare questo scenario.
  • Azure Kubernetes Fleet Manager: Fleet gestisce il ciclo di vita e la configurazione della rete tra cluster tramite risorse come il profilo ClusterMesh.
  • Prestazioni native: il routing IP dei pod avviene tra cluster a prestazioni native tramite routing diretto, eludendo la necessità di qualsiasi gateway o proxy.
  • Applicazione dei criteri di rete unificata: estende l'applicazione dei criteri di rete di livello 3-7 di Cilium a tutti i cluster nella rete tra cluster, garantendo un approccio di sicurezza coerente.
  • Osservabilità multi-cluster: offre una visibilità completa sui flussi di traffico tra i cluster. Questa visibilità consente di monitorare l'integrità delle applicazioni, risolvere i problemi di connettività e analizzare i modelli di traffico nella rete tra cluster.

Casi d'uso

La rete tra cluster consente diversi scenari chiave di più cluster. Le sezioni seguenti descrivono i casi d'uso più comuni per la rete tra cluster con Fleet.

Caso d'uso: Individuazione del servizio trasparente e bilanciamento del carico

Quando si usano servizi Kubernetes standard e li contrassegnano come globali, Cilium individua automaticamente gli endpoint per tali servizi in tutti i cluster nella rete tra cluster. Qualsiasi traffico destinato a un servizio ClusterIP globale viene automaticamente bilanciato tra tutti i cluster che contribuiscono, semplificando la comunicazione tra cluster.

Le applicazioni possono individuare e interagire con i servizi indipendentemente dal cluster in cui risiedono, senza richiedere modifiche a livello di applicazione o registri di servizi esterni.

Caso d'uso: disponibilità elevata e tolleranza di errore

La disponibilità elevata è il caso d'uso più comune per la rete tra cluster. Questo caso d'uso include i cluster Kubernetes operativi in più aree o zone di disponibilità e l'esecuzione di repliche degli stessi servizi in ogni cluster. In caso di errore, le richieste possono essere reindirizzate ad altri cluster nella rete cross-cluster.

Lo scenario di errore descritto in questo caso d'uso non è principalmente l'indisponibilità completa di un'intera area o di un dominio di errore. Uno scenario più probabile è l'indisponibilità temporanea di risorse o errori di configurazione in un cluster, causando l'impossibilità di eseguire o ridimensionare determinati servizi in tale cluster. Con la rete tra cluster, il traffico destinato al servizio interessato viene indirizzato automaticamente agli endpoint integri in altri cluster, mantenendo disponibile l'applicazione.

Diagramma che mostra due cluster AKS distribuiti in aree geografiche diverse. I front-end in ogni cluster indirizzano il traffico verso un servizio degli ordini locale supportato dai pod degli ordini. Quando i pod nel cluster B non sono più integri, il servizio degli ordini nel cluster B esegue il failover verso il servizio degli ordini nel cluster A.

Caso d'uso: Servizi condivisi

Sebbene la tendenza iniziale delle piattaforme basate su Kubernetes fosse quella di creare cluster multi-tenant di grandi dimensioni, è sempre più comune creare singoli cluster per tenant o creare cluster per diverse categorie di servizi, ad esempio diversi livelli di riservatezza della sicurezza.

Tuttavia, alcuni servizi, ad esempio la gestione dei segreti, la registrazione, il monitoraggio o il DNS, sono spesso ancora condivisi tra tutti i cluster. La centralizzazione di questi servizi in un cluster "servizio" condiviso evita il sovraccarico operativo di gestirli in ogni cluster tenant.

La motivazione principale di questo modello è l'isolamento tra i cluster tenant. Per mantenere questo obiettivo, i cluster tenant sono connessi solo al cluster di servizi condivisi e non sono connessi ad altri cluster tenant.

Diagramma che mostra due cluster tenant di AKS con applicazioni che chiamano un client dei segreti. Entrambi i cluster tenant instradano il traffico verso un cluster di servizi condivisi che ospita il servizio dei segreti supportato dai pod vault-1 e vault-2. I cluster tenant si connettono solo al cluster di servizi condivisi, non tra di loro.

Caso d'uso: separazione con stato e senza stato

È possibile isolare la complessità operativa dei servizi con stato, ad esempio database e archiviazione, in cluster dedicati. Questa separazione mantiene i cluster di applicazioni senza stato agili e facili da migrare. Migliora anche la sicurezza, semplifica la gestione del ciclo di vita del cluster e consente di ridimensionare i carichi di lavoro senza stato indipendentemente da quelli con stato.

Diagramma che mostra due cluster AKS senza stato, ciascuno con instradamento in ingresso verso un frontend e un client datastore. Entrambi i cluster senza stato si connettono a un cluster stateful dedicato che ospita il servizio datastore supportato dai pod data-1, data-2 e data-n.

Caso d'uso: sicurezza e applicazione di criteri multi-cluster

La rete tra cluster estende l'applicazione dei criteri di rete di livello 3-7 di Cilium in tutti i cluster nella rete tra cluster. Questa imposizione unificata garantisce un comportamento di sicurezza coerente e semplifica la gestione dei criteri evitando la necessità di replicare manualmente i criteri in ogni ambiente. I criteri applicati a un cluster vengono rispettati anche negli altri cluster, garantendo una sicurezza unificata e basata sulle identità in tutta la flotta.

Caso d'uso: osservabilità multi-cluster

La rete tra cluster offre visibilità end-to-end sul traffico che scorre tra i servizi tra cluster. Aggregando i dati di flusso da ogni cluster nella rete tra cluster, è possibile visualizzare il traffico east-west, monitorare l'integrità delle applicazioni tra aree, risolvere i problemi di connettività tra cluster e analizzare i modelli di traffico per la pianificazione della capacità.

Con i log di rete dei contenitori, gli operatori ottengono una visualizzazione unificata della comunicazione da pod a pod indipendentemente dal cluster in cui risiede l'origine o la destinazione, senza instrumentare le applicazioni.

Servizi globali

Per abilitare il flusso di traffico tra cluster, è necessario configurare i servizi Kubernetes come servizi globali. In una rete tra cluster un servizio globale è un servizio Kubernetes standard condiviso tra più cluster. Quando si contrassegna un servizio come globale, Cilium individua automaticamente gli endpoint per tale servizio in tutti i cluster all'interno della rete tra cluster ed esegue il bilanciamento del carico tra di essi.

Dopo che un servizio è contrassegnato come globale, tutti i criteri applicati in un cluster vengono rispettati in tutti gli altri cluster nella rete tra cluster, fornendo un comportamento di sicurezza coerente. Questa configurazione consente di:

  • Transparent Service Discovery: le applicazioni possono individuare e interagire con i servizi indipendentemente dal cluster in cui risiedono.
  • Disponibilità elevata: se un servizio in un cluster diventa non disponibile, il traffico viene spostato automaticamente in un'istanza integra in un altro cluster.

Cilium gestisce questa individuazione controllando i servizi con l'annotazione io.cilium/global-service: "true" . Per questi servizi, tutti gli endpoint con lo stesso nome e lo stesso spazio dei nomi nei cluster vengono uniti in un unico servizio globale. Qualsiasi traffico destinato a tale servizio ClusterIP viene quindi sottoposto a bilanciamento del carico in tutti i cluster che contribuiscono.

Limitations

  • Un cluster membro può partecipare a una sola rete tra cluster alla volta.
  • Una singola rete tra cluster supporta fino a 255 cluster membri.
  • Le configurazioni multi-cluster di Cilium autogestite non sono supportate insieme alla rete cross-cluster gestita da Fleet.
  • I comandi dell'interfaccia della riga di comando di Cilium che modificano la mesh, ad esempio cilium clustermesh connect o cilium upgrade, non sono supportati perché Fleet gestisce queste operazioni.
  • La connettività tra cluster è limitata ai cluster all'interno dello stesso dominio di instradamento piatto raggiungibile. Non supporta la connettività mesh tra reti virtuali non filtrate.

Passaggi successivi

  • Last updated on