In questa pagina vengono descritte le opzioni per l'alta disponibilità in Google Distributed Cloud.
Funzionalità di base
GKE on VMware include un cluster di amministrazione e uno o più cluster utente.
Il cluster di amministrazione gestisce il ciclo di vita dei cluster utente, tra cui 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 utente (nodi che eseguono il piano di controllo dei cluster utente gestiti) e i nodi aggiuntivi (nodi che eseguono i componenti aggiuntivi che supportano le 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 dei carichi di lavoro. In altre parole, l'interruzione di un piano di controllo non interferisce con i carichi di lavoro in esecuzione, ma i carichi di lavoro esistenti perdono le funzionalità di gestione dal server API Kubernetes se il piano di controllo non è presente.
Il deployment dei carichi di lavoro e dei servizi containerizzati viene eseguito nei nodi worker del cluster utente. Ogni singolo nodo worker non dovrebbe essere critico per la disponibilità dell'applicazione purché il deployment dell'applicazione venga eseguito con pod ridondanti pianificati su più nodi worker.
Abilitazione dell'alta disponibilità
vSphere e Google Distributed Cloud forniscono una serie di funzionalità che contribuiscono all'alta disponibilità.
HA e vMotion vSphere
Ti consigliamo di abilitare le due funzionalità seguenti nel cluster vCenter che ospita i tuoi cluster Google Distributed Cloud:
Queste funzioni migliorano la disponibilità e il ripristino in caso di errore di un host ESXi.
vCenter HA utilizza più host ESXi configurati come cluster per fornire un ripristino rapido dalle interruzioni e un'alta disponibilità economica 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 host vSphere HA
impostando Host Failure Response su Restart VMs. Le VM possono quindi essere riavviate automaticamente su altri host disponibili in caso di errore dell'host ESXi.
vMotion consente la migrazione live delle VM da un host ESXi a un altro senza tempi di inattività. Per la manutenzione pianificata dell'host, puoi utilizzare vMotion migrazione live per evitare completamente i tempi di inattività delle applicazioni e garantire la continuità aziendale.
Cluster di amministrazione
Google Distributed Cloud supporta la creazione di cluster di amministrazione ad alta disponibilità. 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à del cluster utente esistente o su eventuali carichi di lavoro in esecuzione nei cluster utente.
Esistono due nodi dei componenti aggiuntivi in un cluster di amministrazione. Se uno non è attivo, l'altro può ancora
gestire le operazioni del cluster di amministrazione. Per la ridondanza,
Google Distributed Cloud 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, Google Distributed Cloud crea automaticamente regole di anti-affinità per vSphere DRS per i nodi dei componenti aggiuntivi, in modo che vengano 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. Ogni nodo del piano di controllo
esegue anche una replica etcd. Il cluster utente continua a funzionare purché sia in esecuzione un piano di controllo e sia presente il 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, Google Distributed Cloud 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 vengano distribuite tra tre host fisici.
Google Distributed Cloud crea anche regole di anti-affinità vSphere DRS per i nodi worker nel cluster utente, in modo che i nodi siano distribuiti su 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. In questo modo, i nodi worker possono trovare gli host su cui eseguire, 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 cluster vCenter. Configura inoltre DRS in modo che sia completamente automatizzato in modo che, nel caso in cui un host non sia disponibile, DRS possa riavviare automaticamente le VM su altri host disponibili senza violare le regole di anti-affinità delle VM.
Google Distributed Cloud 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 le regole podAntiAffinity con questa etichetta come topologyKey per garantire che i pod delle applicazioni siano distribuiti su diverse VM e host fisici.
Puoi anche configurare più pool di nodi per un cluster utente con datastore ed etichette dei nodi speciali. Allo stesso modo, puoi configurare regole podAntiAffinity
con quell'etichetta nodo speciale come topologyKey per ottenere una maggiore
disponibilità in caso di errori del datastore.
Per avere l'alta disponibilità per i carichi di lavoro utente, assicurati che il cluster utente abbia un numero sufficiente di repliche in nodePools.replicas, in modo 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 al fine di isolare gli 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à avere 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 tempo di inattività durante l'upgrade dei nodi del bilanciatore del carico. La durata dell'interruzione del failover di MetalLB aumenta con l'aumento 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 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 contraffatte e modalità promiscuo sul gruppo di porte del bilanciatore del carico.
Con l'alta disponibilità, vengono configurati due bilanciatori del carico in modalità attiva-passiva. Se si verifica un problema con il bilanciatore del carico attivo, il traffico viene inviato al 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 aiutarti a migliorare sicurezza, disponibilità e prestazioni delle tue applicazioni. Per Google Distributed Cloud, BIG-IP fornisce accesso esterno e servizi di bilanciamento del carico L3/4.
Utilizzo di più cluster per il ripristino di emergenza
Il deployment di applicazioni in più cluster su più vCenter o piattaforme GKE Enterprise può fornire una maggiore disponibilità globale 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é configurare 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 disporre di due cluster di amministrazione in ogni data center e ogni cluster di amministrazione esegue un cluster utente.
Il cluster utente secondario ha un numero minimo di nodi worker (tre) ed è un hot standby (sempre in esecuzione).
I deployment delle applicazioni possono essere replicati tra i due vCenter utilizzando Config Sync, oppure l'approccio preferito è l'utilizzo di una catena di strumenti DevOps (CI/CD, Spinnaker) esistente.
In caso di emergenza, il cluster utente può essere ridimensionato in base al numero di nodi.
Inoltre, è necessario un cambio DNS per instradare il traffico tra i cluster al data center secondario.