Questa pagina descrive le opzioni di alta affidabilità 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, inclusi la creazione, gli aggiornamenti, gli upgrade e l'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 degli add-on (nodi che eseguono i componenti degli add-on 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 controller manager 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, un'interruzione del control plane 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 relativo control plane non è presente.
I carichi di lavoro e i servizi containerizzati vengono sottoposti a deployment nei nodi worker del cluster utente. Nessun singolo nodo worker deve essere fondamentale per la disponibilità dell'applicazione, a condizione che l'applicazione venga sottoposta a deployment con pod ridondanti pianificati su più nodi worker.
Abilitazione dell'alta affidabilità
vSphere e Google Distributed Cloud forniscono una serie di funzionalità che contribuiscono all'alta affidabilità.
vSphere HA e vMotion
Ti consigliamo di abilitare le seguenti due funzionalità nel cluster vCenter che ospita i cluster Google Distributed Cloud:
Queste funzionalità 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à economicamente vantaggiosa per le applicazioni in esecuzione nelle macchine virtuali. Ti consigliamo di eseguire il provisioning del cluster vCenter
con host aggiuntivi e
di abilitare il monitoraggio 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 di un host ESXi.
vMotion consente la migrazione live senza tempi di inattività delle VM da un host ESXi a un altro. Per la manutenzione pianificata degli host, puoi utilizzare la migrazione live vMotion 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 l'indisponibilità del piano di controllo del cluster di amministrazione non influisce sulla funzionalità del cluster utente esistente o su eventuali carichi di lavoro in esecuzione nei cluster utente.
In un cluster di amministrazione sono presenti due nodi degli add-on. Se uno non è disponibile, l'altro può comunque gestire le operazioni del cluster di amministrazione. Per la ridondanza, Google Distributed Cloud distribuisce i servizi degli add-on critici, come kube-dns, su entrambi i nodi degli add-on.
Se imposti antiAffinityGroups.enabled su true nel file di configurazione del cluster di amministrazione, Google Distributed Cloud crea automaticamente
regole anti-affinità vSphere DRS
per i nodi degli add-on, in modo che vengano distribuiti su
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 il cluster utente ha
Controlplane V2
abilitato (opzione consigliata), i tre nodi del piano di controllo vengono eseguiti nel cluster utente.
I cluster utente ad alta disponibilità legacy che non hanno Controlplane V2 abilitato 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 finché è in esecuzione un piano di controllo ed è presente un quorum etcd. Un quorum etcd richiede che due delle tre repliche etcd siano funzionanti.
Se imposti antiAffinityGroups.enabled su true nel file di configurazione del cluster di amministrazione, Google Distributed Cloud crea automaticamente regole anti-affinità vSphere DRS per i tre nodi che eseguono il piano di controllo del cluster utente.
In questo modo, le VM vengono distribuite su tre host fisici.
Google Distributed Cloud crea anche regole anti-affinità vSphere DRS per i nodi worker nel cluster utente, in modo che questi nodi vengano distribuiti su almeno tre host fisici. Per ogni node pool del cluster utente vengono utilizzate più regole anti-affinità DRS in base al numero di nodi. In questo modo, i nodi worker possono trovare host su cui eseguire, anche quando il numero di host è inferiore al numero di VM nel node pool 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, se un host non è 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 di nodo speciale, onprem.gke.io/failure-domain-name, il cui valore è impostato sul nome dell'host ESXi sottostante. Le applicazioni utente che richiedono alta affidabilità possono configurare regole podAntiAffinity con questa etichetta come topologyKey per garantire che i pod dell'applicazione siano distribuiti su VM e host fisici diversi.
Puoi anche configurare più node pool per un cluster utente con datastore diversi ed etichette di nodo speciali. Allo stesso modo, puoi configurare regole podAntiAffinity con questa etichetta di nodo speciale come topologyKey per ottenere una maggiore disponibilità in caso di errori del datastore.
Per garantire l'alta disponibilità dei 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 per isolare i relativi errori.
Bilanciatore del carico
Esistono due tipi di bilanciatori del carico che puoi utilizzare per l'alta affidabilità.
Bilanciatore del carico MetalLB in bundle
Per il
bilanciatore del carico MetalLB in bundle,
puoi ottenere l'alta disponibilità utilizzando più nodi con enableLoadBalancer: true.
MetalLB distribuisce i servizi sui nodi del bilanciatore del carico, ma per un singolo servizio è presente un solo nodo leader che gestisce tutto il traffico per quel servizio.
Durante l'upgrade del cluster, si verifica un 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'aumentare del numero di nodi del bilanciatore del carico. Con meno di 5 nodi, l'interruzione è entro 10 secondi.
Bilanciamento del carico manuale
Con il bilanciamento del carico manuale, configuri Google Distributed Cloud in modo che utilizzi un bilanciatore del carico di tua scelta, ad esempio F5 BIG-IP o Citrix. Configuri l'alta affidabilità 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ù server vCenter può fornire una maggiore disponibilità globale e limitare il raggio di impatto durante le interruzioni.
Questa configurazione utilizza il cluster esistente nel data center secondario per il ripristino di emergenza anziché configurare un nuovo cluster. Di seguito è riportato un riepilogo di alto livello per raggiungere questo obiettivo:
Crea un altro cluster di amministrazione e un cluster utente nel data center secondario. In questa architettura multi-cluster, gli utenti devono avere 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 è in standby attivo (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) dell'applicazione esistente.
In caso di emergenza, è possibile ridimensionare il cluster utente in base al numero di nodi.
Inoltre, è necessario un cambio di DNS per instradare il traffico tra i cluster al data center secondario.