Questa pagina descrive le opzioni ad alta disponibilità in GKE su VMware.
Funzionalità di base
GKE su VMware include un cluster di amministrazione e uno o più cluster utente.
Il cluster di amministrazione gestisce il ciclo di vita dei cluster utente, inclusi creazione, aggiornamenti, upgrade ed eliminazione dei cluster utente. Nel cluster di amministrazione, il master di amministrazione gestisce i nodi worker di amministrazione, che includono i master degli utenti (nodi che eseguono il piano di controllo dei cluster utente gestiti) e i nodi aggiuntivi (nodi che eseguono i componenti aggiuntivi che supportano la funzionalità del cluster di amministrazione).
Per ogni cluster utente, il cluster di amministrazione ha un nodo non ad alta disponibilità o tre nodi ad alta disponibilità che eseguono il piano di controllo. Il piano di controllo include il server API Kubernetes, lo scheduler Kubernetes, il gestore dei controller Kubernetes e diversi controller critici per il cluster utente.
La disponibilità del piano di controllo del cluster utente è fondamentale per le operazioni dei carichi di lavoro, come la creazione, lo scale up e lo scale down e la terminazione. In altre parole, un'interruzione del piano di controllo non interferisce con i carichi di lavoro in esecuzione, ma i carichi di lavoro esistenti perdono le funzionalità di gestione del server API Kubernetes se il relativo piano di controllo è assente.
Il deployment di carichi di lavoro e servizi containerizzati viene eseguito nei nodi worker del cluster utente. Ogni singolo nodo worker non deve essere critico per la disponibilità dell'applicazione purché il deployment dell'applicazione sia stato eseguito con pod ridondanti pianificati su più nodi worker.
Abilitazione dell'alta disponibilità
vSphere e GKE su VMware forniscono una serie di funzionalità che contribuiscono all'alta disponibilità (HA).
vSphere HA e vMotion
Ti consigliamo di abilitare le due funzionalità seguenti nel cluster vCenter che ospita i tuoi cluster GKE su VMware:
Queste funzionalità migliorano la disponibilità e il ripristino in caso di guasto di un host ESXi.
vCenter HA utilizza più host ESXi configurati come cluster per fornire un ripristino rapido
da interruzioni e un'alta disponibilità a costi contenuti per le applicazioni
in esecuzione su macchine virtuali. Ti consigliamo di eseguire il provisioning del cluster vCenter con host aggiuntivi e di abilitare il monitoraggio dell'host ad alta disponibilità vSphere con Host Failure Response impostato su Restart VMs. Le VM possono quindi essere riavviate automaticamente su altri host disponibili in caso di errore di un host ESXi.
vMotion consente la migrazione live senza tempo di inattività delle VM da un host ESXi a un altro. Per la manutenzione pianificata dell'host, puoi utilizzare la migrazione live di vMotion per evitare completamente i tempi di inattività delle applicazioni e garantire la continuità aziendale.
Cluster di amministrazione
GKE su VMware supporta la creazione di cluster di amministrazione ad alta disponibilità (HA). Un cluster di amministrazione ad alta disponibilità ha tre nodi che eseguono i componenti del piano di controllo. Per informazioni su requisiti e limitazioni, consulta Cluster di amministrazione ad alta disponibilità.
Tieni presente che la mancata disponibilità del piano di controllo del cluster di amministrazione non influisce sulle funzionalità dei cluster utente esistenti o sui carichi di lavoro in esecuzione nei cluster utente.
In un cluster di amministrazione sono presenti due nodi aggiuntivi. Se uno non è attivo, l'altro
può comunque gestire le operazioni del cluster di amministrazione. Per la ridondanza, GKE su VMware distribuisce servizi aggiuntivi critici, come kube-dns, su entrambi i nodi dei componenti aggiuntivi.
Se imposti antiAffinityGroups.enabled su true nel file di configurazione del cluster di amministrazione, GKE su VMware crea automaticamente regole di anti-affinità vSphere DRS per i nodi dei componenti aggiuntivi, in modo che siano distribuiti tra due host fisici per l'alta disponibilità.
Cluster utente
Puoi abilitare l'alta disponibilità per un cluster utente impostando masterNode.replicas su 3 nel file di configurazione del cluster utente. Se nel cluster utente è abilitato Controlplane V2 (opzione consigliata), i tre nodi del piano di controllo vengono eseguiti nel cluster utente.
I cluster utente kubeception legacy ad alta disponibilità eseguono i tre nodi del piano di controllo nel cluster di amministrazione. Anche ogni nodo del piano di controllo
esegue una replica etcd. Il cluster utente continua a funzionare
purché sia in esecuzione un piano di controllo e un quorum etcd. Un quorum etcd
richiede che due delle tre repliche etcd funzionino.
Se imposti antiAffinityGroups.enabled su true nel file di configurazione del cluster di amministrazione, GKE su VMware crea automaticamente regole di anti-affinità vSphere DRS per i tre nodi che eseguono il piano di controllo del cluster utente.
Questo fa sì che le VM siano distribuite tra tre host fisici.
GKE su VMware crea anche regole di anti-affinità vSphere DRS per i nodi worker nel cluster utente, in modo che i nodi siano distribuiti in almeno tre host fisici. Vengono utilizzate più regole di anti-affinità DRS per pool di nodi del cluster utente in base al numero di nodi. Ciò garantisce che i nodi worker possano trovare gli host su cui eseguire l'esecuzione, anche quando il numero di host è inferiore al numero di VM nel pool di nodi del cluster utente. Ti consigliamo di includere host fisici aggiuntivi nel tuo cluster vCenter. Inoltre, configura il DRS in modo che sia completamente automatizzato in modo che, nel caso in cui un host diventi non disponibile, possa riavviare automaticamente le VM su altri host disponibili senza violare le regole di anti-affinità delle VM.
GKE su VMware mantiene un'etichetta speciale del nodo,
onprem.gke.io/failure-domain-name, il cui valore è impostato sul nome host ESXi
sottostante. Le applicazioni utente che vogliono una disponibilità elevata possono configurare regole podAntiAffinity con questa etichetta topologyKey per garantire che i relativi pod dell'applicazione siano distribuiti su diverse VM e host fisici.
Puoi anche configurare più pool di nodi per un cluster utente con datastore diversi ed etichette speciali dei nodi. Allo stesso modo, puoi configurare le regole podAntiAffinity con questa etichetta nodo speciale come topologyKey per ottenere una disponibilità maggiore in caso di errori del datastore.
Per avere l'alta disponibilità per i carichi di lavoro degli utenti, assicurati che il cluster utente abbia un numero sufficiente di repliche in nodePools.replicas, così da garantire il numero desiderato di nodi worker del cluster utente in esecuzione.
Puoi utilizzare datastore separati per i cluster di amministrazione e i cluster utente per isolare i relativi errori.
Bilanciatore del carico
Esistono due tipi di bilanciatori del carico che puoi utilizzare per l'alta disponibilità.
Bilanciatore del carico MetalLB in bundle
Per il bilanciatore del carico MetalLB in bundle, puoi ottenere l'alta disponibilità avendo più di un nodo con enableLoadBalancer: true.
MetalLB distribuisce i servizi sui nodi del bilanciatore del carico, ma per un singolo servizio esiste un solo nodo leader che gestisce tutto il traffico per quel servizio.
Durante l'upgrade del cluster, si verifica un certo tempo di inattività quando viene eseguito l'upgrade dei nodi del bilanciatore del carico. La durata dell'interruzione del failover di MetalLB aumenta all'aumentare del numero di nodi del bilanciatore del carico. Con meno di 5 nodi, l'interruzione avviene entro 10 secondi.
Bilanciatore del carico Seesaw in bundle
Per il bilanciatore del carico di Seesaw in bundle, puoi abilitare l'alta disponibilità impostando loadBalancer.seesaw.enableHA su true nel file di configurazione del cluster.
Devi inoltre abilitare una combinazione di apprendimento MAC, trasmissioni forgiate e modalità promiscuo sul gruppo di porte del bilanciatore del carico.
Con l'alta disponibilità, vengono configurati due bilanciatori del carico in modalità attivo-passivo. Se il bilanciatore del carico attivo presenta un problema, il traffico ha esito negativo per il bilanciatore del carico passivo.
Durante l'upgrade di un bilanciatore del carico si verifica un tempo di inattività. Se l'alta disponibilità è abilitata per il bilanciatore del carico, il tempo di inattività massimo è di due secondi.
Bilanciatore del carico F5 BIG-IP integrato
La piattaforma F5 BIG-IP offre vari servizi per migliorare la sicurezza, la disponibilità e le prestazioni delle tue applicazioni. Per GKE su VMware, BIG-IP fornisce accesso esterno e servizi di bilanciamento del carico L3/4.
Per maggiori informazioni, consulta Alta disponibilità di BIG-IP.
Utilizzo di più cluster per il ripristino di emergenza
Il deployment di applicazioni in più cluster su più piattaforme vCenter o GKE Enterprise può fornire una disponibilità globale più elevata e limitare la portata dell'attacco durante le interruzioni.
Questa configurazione utilizza il cluster GKE Enterprise esistente nel data center secondario per il ripristino di emergenza anziché la configurazione di un nuovo cluster. Di seguito è riportato un riepilogo generale per raggiungere questo obiettivo:
Crea un altro cluster di amministrazione e un altro cluster utente nel data center secondario. In questa architettura multi-cluster, gli utenti devono avere due cluster di amministrazione in ciascun data center e ogni cluster di amministrazione esegue un cluster utente.
Il cluster utente secondario ha un numero minimo di nodi worker (tre) ed è in modalità hot standby (sempre in esecuzione).
I deployment delle applicazioni possono essere replicati nei due vCenter utilizzando Config Sync. In alternativa, l'approccio preferito consiste nell'utilizzare una toolchain DevOps (CI/CD, Spinnaker) esistente.
In caso di emergenza, il cluster utente può essere ridimensionato in base al numero di nodi.
Inoltre, è necessaria uno switch DNS per instradare il traffico tra i cluster al data center secondario.