In questa pagina vengono descritte le opzioni per l'alta disponibilità in Google Distributed Cloud (software solo) per VMware.
Funzionalità di base
Un'installazione solo software di Google Distributed Cloud for VMware include un amministratore 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, l'amministratore Il master gestisce i nodi worker dell'amministratore, che includono i master degli utenti (nodi in esecuzione il piano di controllo dei cluster utente gestiti) e i nodi aggiuntivi (nodi in esecuzione 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 l'API Kubernetes server, lo scheduler Kubernetes, il gestore dei controller Kubernetes e diversi e i 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, un l'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 dell'API Kubernetes se il piano di controllo corrispondente è assente.
Il deployment dei carichi di lavoro e dei servizi containerizzati viene eseguito nel worker del cluster utente nodi. Nessun singolo nodo worker deve essere fondamentale 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).
HA e vMotion vSphere
Ti consigliamo di attivare 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 rapido recupero dalle interruzioni e un'alta disponibilità conveniente per le applicazioni in esecuzione in macchine virtuali. Ti consigliamo di eseguire il provisioning di vCenter
con altri host e
abilita il monitoraggio host ad alta disponibilità di vSphere
con Host Failure Response impostato su Restart VMs. Le VM possono quindi essere
riavviato 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 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, vedi Cluster di amministrazione ad alta disponibilità.
Tieni presente che la mancata disponibilità del piano di controllo del cluster di amministrazione influisce sulle funzionalità del cluster utente esistente o su qualsiasi carico di lavoro in esecuzione cluster.
In un cluster di amministrazione sono presenti due nodi aggiuntivi. Se una non è attiva, l'altra
possono comunque gestire 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 cluster di amministrazione
di configurazione del deployment, Google Distributed Cloud crea automaticamente
DRS vSphere
regole di anti-affinità per i nodi dei componenti aggiuntivi, che ne causano la diffusione
due host fisici per l'alta disponibilità.
Cluster utente
Puoi abilitare l'alta disponibilità per un cluster utente impostando masterNode.replicas su 3 in
il 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
purché ci sia un piano di controllo in esecuzione e un quorum etcd. Un etcd
il quorum 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 anti-affinità DRS vSphere per i tre nodi che eseguono il control plane del cluster utente.
Di conseguenza, queste VM vengono distribuite su tre host fisici.
Google Distributed Cloud crea anche regole di anti-affinità vSphere DRS per nodi worker nel cluster utente, con la conseguente distribuzione dei nodi almeno tre host fisici. Vengono utilizzate più regole di anti-affinità DRS per ogni pool di nodi 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 in modo che nel caso in cui un host non sia più disponibile, DRS può riavvia le VM su altri host disponibili senza violare le VM regole di anti-affinità.
Google Distributed Cloud gestisce un'etichetta speciale per i nodi,
onprem.gke.io/failure-domain-name, il cui valore è impostato sull'ESXi sottostante
nome host. Le applicazioni utente che richiedono un'alta disponibilità possono configurare le 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 utente con diverse
datastore ed etichette di 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 carichi di lavoro degli utenti, 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 i cluster utente per isolare i loro 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 verifica un breve tempo 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. Configuri l'alta disponibilità sul tuo carico non in Google Distributed Cloud.
Utilizzo di più cluster per il ripristino di emergenza
Deployment di applicazioni in più cluster su più vCenter Le piattaforme GKE Enterprise possono fornire una maggiore disponibilità globale per limitare la portata dell'attacco durante le interruzioni.
Questa configurazione utilizza il cluster GKE Enterprise esistente di un data center secondario per il ripristino di emergenza anziché 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 è hot standby (sempre in esecuzione).
I deployment delle applicazioni possono essere replicati tra i due vCenter utilizzando Config Sync o l'approccio preferito è utilizzare una toolchain DevOps (CI/CD, Spinnaker) per applicazioni esistente.
In caso di emergenza, il cluster utente può essere ridimensionato al numero nodi.
Inoltre, è necessario un cambio DNS per instradare il traffico tra automaticamente al data center secondario.