Questa pagina descrive le opzioni di alta disponibilità in Google Distributed Cloud (solo software) per VMware.
Funzionalità di base
Un'installazione solo software di Google Distributed Cloud per VMware include un cluster di amministrazione e uno o più cluster utente.
Il cluster di amministrazione gestisce il ciclo di vita dei cluster utente, inclusa la creazione, gli aggiornamenti, gli upgrade e l'eliminazione dei cluster utente. Nel cluster di amministrazione, il master amministrativo gestisce i nodi worker amministrativi, che includono i master utente (nodi che eseguono il piano di controllo dei cluster utente gestiti) e i nodi di componenti 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, l'aumento e la riduzione di scala 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 non è presente.
I carichi di lavoro e i servizi containerizzati vengono di cui vengono eseguiti i deployment nei nodi worker del cluster utente. Nessun singolo nodo worker deve essere critico per la disponibilità dell'applicazione se l'applicazione viene dispiattata con pod ridondanti pianificati su più nodi worker.
Attivazione dell'alta disponibilità
vSphere e Google Distributed Cloud offrono una serie di funzionalità che contribuiscono all'alta disponibilità (HA).
vSphere HA e vMotion
Ti consigliamo di attivare le due funzionalità seguenti nel cluster vCenter che ospita i tuoi cluster Google Distributed Cloud:
Queste funzionalità migliorano la disponibilità e il recupero in caso di errore di un host ESXi.
vCenter HA utilizza più host ESXi configurati come cluster per fornire un rapido recupero dalle interruzioni e un'alta disponibilità conveniente per le applicazioni in esecuzione in macchine virtuali. Ti consigliamo di eseguire il provisioning del cluster vCenter con host aggiuntivi e di abilitare il monitoraggio degli host vSphere HA con Host Failure Response impostato 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 riposo. Per la manutenzione pianificata dell'host, puoi utilizzare la migrazione live vMotion per evitare completamente il tempo di riposo dell'applicazione e garantire la continuità aziendale.
Cluster di amministrazione
Google Distributed Cloud supporta la creazione di cluster di amministrazione ad alta disponibilità (HA). Un cluster di amministrazione HA ha tre nodi che eseguono i componenti del piano di controllo. Per informazioni su requisiti e limitazioni, consulta Cluster amministrativo ad alta disponibilità.
Tieni presente che la mancata disponibilità del control plane del cluster di amministrazione non influisce sulla funzionalità dei cluster utente esistenti o su eventuali workload in esecuzione nei cluster utente.
In un cluster di amministrazione sono presenti due nodi aggiuntivi. Se uno è inattivo, l'altro può comunque eseguire le operazioni del cluster di amministrazione. Per garantire la ridondanza,
Google Distributed Cloud distribuisce i servizi aggiuntivi critici, come kube-dns,
su entrambi i nodi aggiuntivi.
Se imposti antiAffinityGroups.enabled su true nel file di configurazione del cluster amministrativo, Google Distributed Cloud crea automaticamente regole anti-affinità vSphere DRS per i nodi del componente aggiuntivo, in modo che vengano distribuiti su due host fisici per l'HA.
Cluster utente
Puoi attivare l'HA per un cluster utente impostando masterNode.replicas su 3 nel
file di configurazione del cluster utente. Se nel cluster utente è attivo il control plane v2 (opzione consigliata), i tre nodi del control plane vengono eseguiti nel cluster utente.
I cluster utente kubeception ad alta disponibilità legacy eseguono i tre nodi del control plane nel cluster di amministrazione. Ogni nodo del piano di controllo esegue anche una replica di etcd. Il cluster utente continua a funzionare
se è in esecuzione un piano di controllo e un quorum etcd. Un quorum di etcd richiede che due delle tre repliche di etcd siano in funzione.
Se imposti antiAffinityGroups.enabled su true nel file di configurazione del cluster di amministrazione, Google Distributed Cloud crea automaticamente regole anti-affinità DRS vSphere per i tre nodi che eseguono il control plane del cluster utente.
Di conseguenza, le VM vengono distribuite su tre host fisici.
Google Distributed Cloud crea anche regole anti-affinità DRS vSphere per i nodi worker del cluster utente, in modo che questi nodi vengano distribuiti su almeno tre host fisici. Vengono utilizzate più regole di anti-affinità DRS per ogni node pool del cluster utente in base al numero di nodi. In questo modo, i nodi worker possono trovare host su cui eseguire i job, anche se 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 anche 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 anti-affinità delle VM.
Google Distributed Cloud gestisce un'etichetta del nodo speciale,onprem.gke.io/failure-domain-name, il cui valore è impostato sul nome dell'host ESXi sottostante. Le applicazioni utente che richiedono un'alta disponibilità possono configurare regole podAntiAffinity con questa etichetta come topologyKey per assicurarsi che i pod delle applicazioni siano distribuiti su diverse VM e host fisici.
Puoi anche configurare più pool di nodi per un cluster di utenti con diversi
datastore ed etichette dei nodi speciali. Analogamente, puoi configurare regole podAntiAffinity
con l'etichetta del nodo speciale come topologyKey per ottenere una maggiore
disponibilità in caso di errori del datastore.
Per avere l'HA per i workload utente, assicurati che il cluster utente abbia un numero sufficiente di repliche inferiore a 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 per 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'HA disponendo di 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 verificano dei tempi di inattività quando viene eseguito 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 è inferiore a 10 secondi.
Bilanciamento del carico manuale
Con il bilanciamento del carico manuale, configuri Google Distributed Cloud in modo da utilizzare un bilanciatore del carico a tua scelta, ad esempio F5 BIG-IP o Citrix. La configurazione dell'alta disponibilità avviene sul bilanciatore del carico, non in Google Distributed Cloud.
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 l'area di impatto durante le interruzioni del servizio.
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, è necessario che gli utenti dispongano di due cluster di amministrazione in ogni data center e che ogni cluster di amministrazione esegua un cluster utente.
Il cluster utente secondario ha un numero minimo di nodi worker (tre) ed è in hot standby (sempre in esecuzione).
I deployment delle applicazioni possono essere replicati nei due vCenter utilizzando Config Sync oppure l'approccio preferito è utilizzare una toolchain DevOps (CI/CD, Spinnaker) per le applicazioni esistente.
In caso di incidente, il cluster utente può essere ridimensionato in base al numero di nodi.
Inoltre, è necessario uno switchover DNS per indirizzare il traffico tra i cluster al data center secondario.