Best practice per gli upgrade dei cluster Google Distributed Cloud

Questo documento descrive le best practice e le considerazioni per eseguire l'upgrade di Google Distributed Cloud. Scopri come prepararti agli upgrade dei cluster e le best practice da seguire prima dell'upgrade. Queste best practice contribuiscono a ridurre i rischi associati agli upgrade dei cluster.

Se hai più ambienti, ad esempio test, sviluppo e produzione, ti consigliamo di iniziare con l'ambiente meno critico, ad esempio test, e di verificare la funzionalità di upgrade. Dopo aver verificato che l'upgrade sia andato a buon fine, passa all'ambiente successivo. Ripeti questa procedura fino a quando non esegui l'upgrade degli ambienti di produzione. Questo approccio ti consente di passare da un punto critico all'altro e di verificare che l'upgrade e i tuoi carichi di lavoro funzionino correttamente.

Elenco di controllo per l'upgrade

Per semplificare il più possibile la procedura di upgrade, esamina e completa i seguenti controlli prima di iniziare l'upgrade dei cluster:

Pianifica l'upgrade

Gli aggiornamenti possono causare interruzioni. Prima di iniziare l'upgrade, pianifica attentamente per assicurarti che l'ambiente e le applicazioni siano pronti. Potresti anche dover pianificare l'upgrade dopo l'orario di apertura normale, quando il traffico è minimo.

Stimare l'impegno in termini di tempo e pianificare un periodo di manutenzione

Per impostazione predefinita, l'upgrade di tutti i pool di nodi viene eseguito in parallelo. Tuttavia, all'interno di ogni pool di nodi, l'upgrade dei nodi viene eseguito in sequenza perché ogni nodo deve essere svuotato e ricreato. Pertanto, il tempo totale di un upgrade dipende dal numero di nodi nel pool di nodi più grande. Per calcolare una stima approssimativa del tempo di upgrade, moltiplica 15 minuti per il numero di nodi nel pool di nodi più grande. Ad esempio, se hai 10 nodi nel pool più grande, il tempo totale di upgrade sarà di circa 15 * 10 = 150 minuti o 2,5 ore.

Di seguito sono riportati diversi modi per ridurre il tempo di upgrade e semplificare la pianificazione e la programmazione degli upgrade:

  • Nella versione 1.28 e successive, puoi accelerare un upgrade impostando il valore di maxSurge per i singoli pool di nodi. Quando esegui l'upgrade delle note con maxSurge, l'upgrade di più nodi avviene nello stesso tempo necessario per l'upgrade di un singolo nodo.

  • Se i tuoi cluster sono alla versione 1.16 o successiva, puoi saltare una versione minore durante l'upgrade dei node pool. L'esecuzione di un upgrade con salto di versione dimezza il tempo necessario per eseguire l'upgrade sequenziale dei pool di nodi di due versioni. Inoltre, gli upgrade che ignorano le versioni ti consentono di aumentare il tempo tra gli upgrade necessari per continuare a utilizzare una versione supportata. La riduzione del numero di upgrade riduce le interruzioni del workload e i tempi di verifica. Per ulteriori informazioni, consulta Ignorare una versione durante l'upgrade dei pool di nodi.

  • Puoi eseguire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi. Questa flessibilità può aiutarti a pianificare più periodi di manutenzione brevi anziché un unico periodo di manutenzione lungo per eseguire l'upgrade dell'intero cluster. Per maggiori dettagli, vedi Eseguire l'upgrade dei pool di nodi.

Esegui il backup del cluster utente e di quello di amministrazione

Prima di iniziare un upgrade, esegui il backup dei cluster utente e di amministrazione.

Un backup del cluster utente è uno snapshot dello spazio dati etcd del cluster utente. L'etcd store contiene tutti gli oggetti Kubernetes e personalizzati necessari per gestire lo stato del cluster. Lo snapshot contiene i dati necessari per ricreare i componenti e i carichi di lavoro del cluster. Per ulteriori informazioni, scopri come eseguire il backup di un cluster di utenti.

Con Google Distributed Cloud versione 1.8 e successive, puoi configurare il backup automatico con clusterBackup.datastore nel file di configurazione del cluster di amministrazione. Per attivare questa funzionalità in un cluster esistente, modifica il file di configurazione del cluster di amministrazione e aggiungi il campo clusterBackup.datastore, quindi esegui gkectl update admin.

Una volta attivato clusterBackup.datastore, il cluster di amministrazione viene sottoposto automaticamente a backup in etcd nel datastore vSphere configurato. Questa procedura di backup si ripete ogni volta che viene apportata una modifica al cluster di amministrazione. Quando avvii un upgrade del cluster, prima dell'upgrade viene eseguita un'attività di backup.

Per ripristinare un cluster di amministrazione dal relativo backup in caso di problemi, consulta Eseguire il backup e il ripristino di un cluster di amministrazione con gkectl.

Esamina l'utilizzo di PodDisruptionBudgets

In Kubernetes, i PodDisruptionBudgets (PDB) possono contribuire a evitare i tempi di riposo o le interruzioni indesiderate delle applicazioni. I PDB ordinano allo scheduler di mantenere sempre in esecuzione un certo numero di pod, anche se altri pod potrebbero non funzionare correttamente. Questo comportamento è un modo utile per garantire la disponibilità dell'applicazione.

  1. Per controllare quali PDB sono configurati nel cluster, utilizza il comando kubectl get pdb:

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Sostituisci KUBECONFIG con il nome del file kubeconfig.

    L'esempio di output seguente mostra i PDB denominati istio-ingress, istiod e kube-dns:

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

Nella tabella precedente, ogni PDB specifica che deve essere sempre disponibile almeno un pod. Questa disponibilità diventa fondamentale durante gli upgrade quando i nodi vengono svuotati.

Controlla se sono presenti PDB che non possono essere soddisfatte. Ad esempio, puoi impostare una disponibilità minima di 1 se il deployment contiene una sola replica. In questo esempio, l'operazione di svuotamento viene interrotta perché il PDB non può essere soddisfatto dal controller delle risorse.

Per assicurarti che i PDB non interferiscano con la procedura di upgrade, controlla tutti i PDB di un determinato cluster prima di iniziare l'upgrade. Potresti dover collaborare con i team di sviluppo e i proprietari di applicazioni per modificare o disattivare temporaneamente i PDB durante l'upgrade di un cluster.

Google Distributed Cloud esegue un controllo preflight durante la procedura di upgrade per avvisare sui PDB. Tuttavia, devi anche verificare manualmente i PDB per garantire un'esperienza di upgrade senza problemi. Per scoprire di più sui PDB, consulta Specificare un budget di interruzione per l'applicazione.

Esamina gli indirizzi IP disponibili

Durante gli upgrade dei cluster si applicano le seguenti considerazioni relative agli indirizzi IP:

  • La procedura di upgrade del cluster crea un nuovo nodo e ne scarica le risorse prima di eliminare il vecchio nodo. Ti consigliamo di avere sempre N+1 indirizzi IP per il cluster di amministrazione o utente, dove N è il numero di nodi nel cluster.
  • Quando utilizzi indirizzi IP statici, gli indirizzi IP richiesti devono essere elencati nei file di blocco IP.
  • Se utilizzi DHCP, assicurati che le nuove VM possano ottenere lease IP aggiuntivi nella subnet desiderata durante un upgrade.
    • Se devi aggiungere indirizzi IP, aggiorna il file di blocco IP, quindi esegui il comandogkectl update. Per ulteriori informazioni, consulta Pianificare gli indirizzi IP.
  • Se utilizzi indirizzi IP statici e vuoi velocizzare il processo di upgrade del cluster utente, elenca un numero di indirizzi IP sufficiente nel file del blocco IP in modo che ogni pool di nodi possa avere un indirizzo IP aggiuntivo disponibile. Questo approccio consente di accelerare la procedura di aggiunta e rimozione delle VM in quanto viene eseguita su base per pool di nodi.
    • Sebbene questo approccio sia una buona opzione per velocizzare gli upgrade dei cluster utente, prima di procedere, tieni conto della disponibilità delle risorse e delle prestazioni del tuo ambiente vSphere.
  • Se esiste un solo IP di riserva per l'intero cluster di utenti, questa limitazione rallenta la procedura di upgrade a una sola VM alla volta, anche se vengono utilizzati più pool di nodi.

Controllare l'utilizzo del cluster

Assicurati che i pod possano essere evacuati quando il nodo viene svuotato e che nel cluster di cui viene eseguito l'upgrade siano presenti risorse sufficienti per gestire l'upgrade. Per controllare l'utilizzo corrente delle risorse del cluster, puoi utilizzare le dashboard personalizzate in Google Cloud Observability o direttamente sul cluster utilizzando comandi come kubectl top nodes.

I comandi eseguiti sul cluster mostrano uno snapshot dell'utilizzo corrente delle risorse del cluster. Le dashboard possono fornire una visione più dettagliata delle risorse consumate nel tempo. Questi dati sull'utilizzo delle risorse possono indicare quando un upgrade causerebbe le interruzioni meno gravi, ad esempio durante i fine settimana o la sera, a seconda del carico di lavoro e dei casi d'uso in esecuzione.

I tempi dell'upgrade del cluster di amministrazione potrebbero essere meno critici rispetto a quelli dei cluster utente, perché in genere un upgrade del cluster di amministrazione non comporta tempi di inattività dell'applicazione. Tuttavia, è comunque importante verificare la presenza di risorse libere in vSphere prima di iniziare l'upgrade di un cluster di amministrazione. Inoltre, l'upgrade del cluster di amministrazione potrebbe comportare alcuni rischi e, pertanto, potrebbe essere consigliato durante periodi di utilizzo meno attivo, quando l'accesso di gestione al cluster è meno critico.

Per ulteriori informazioni, consulta i servizi interessati durante l'upgrade di un cluster.

Controllare l'utilizzo di vSphere

Verifica che le risorse dell'infrastruttura vSphere di base siano sufficienti. Per controllare l'utilizzo di questa risorsa, seleziona un cluster in vCenter e controlla la scheda Riepilogo.

La scheda Riepilogo mostra il consumo complessivo di memoria, CPU e spazio di archiviazione dell'intero cluster. Poiché gli upgrade di Google Distributed Cloud richiedono risorse aggiuntive, devi anche verificare se il cluster è in grado di gestire queste richieste di risorse aggiuntive.

Come regola generale, il cluster vSphere deve essere in grado di supportare le seguenti risorse aggiuntive:

  • +1 VM per l'upgrade del cluster di amministrazione
  • +1 VM per pool di nodi per upgrade del cluster utente

Ad esempio, supponiamo che un cluster utente abbia 3 pool di nodi in cui ogni pool di nodi abbia nodi che utilizzano 8 vCPU e almeno 32 GB di RAM. Poiché l'upgrade avviene in parallelo per i tre pool di nodi per impostazione predefinita, la procedura di upgrade consuma le seguenti risorse aggiuntive per i tre nodi di picco aggiuntivi:

  • 24 vCPU
  • 256 GB di RAM
  • Spazio su disco della VM + 256 GB di vSwap

La procedura di upgrade crea le VM utilizzando l'operazione di clonazione di vSphere. La clonazione di più VM da un modello può sottoporre a stress il sistema di archiviazione sottostante sotto forma di aumento delle operazioni di I/O. L'upgrade può essere notevolmente rallentato se il sottosistema di archiviazione sottostante non è in grado di fornire un rendimento sufficiente durante un upgrade.

Sebbene vSphere sia progettato per l'utilizzo simultaneo delle risorse e disponga di meccanismi per fornire risorse anche in caso di overcommit, ti consigliamo vivamente di non eseguire overcommit della memoria della VM. L'overcommit della memoria può comportare gravi impatti sulle prestazioni che interessano l'intero cluster, poiché vSphere fornisce la "RAM mancante" per lo scambio delle pagine nel datastore. Questo comportamento può portare a problemi durante l'upgrade di un cluster e causare ripercussioni sulle prestazioni di altre VM in esecuzione sul cluster vSphere.

Se le risorse disponibili sono già scarse, arresta le VM non necessarie per contribuire a soddisfare questi requisiti aggiuntivi e a evitare un potenziale calo delle prestazioni.

Controlla l'integrità e la configurazione del cluster

Esegui i seguenti strumenti su tutti i cluster prima dell'upgrade:

  • Il comando gkectl diagnose: gkectl diagnose garantisce che tutti i cluster siano in stato integro. Il comando esegue controlli avanzati, ad esempio per identificare i nodi che non sono configurati correttamente o che hanno pod in uno stato bloccato. Se il comando gkectl diagnose mostra un avviso Cluster unhealthy, risolvi i problemi prima di tentare un upgrade. Per ulteriori informazioni, consulta Diagnostica i problemi del cluster.

  • Lo strumento di pre-upgrade: oltre a controllare l'integrità e la configurazione del cluster, lo strumento di pre-upgrade controlla la presenza di potenziali problemi noti che potrebbero verificarsi durante un upgrade del cluster.

Inoltre, quando esegui l'upgrade dei cluster utente alla versione 1.29 e successive, ti consigliamo di eseguire il comando gkectl upgrade cluster con il flag --dry-run. Il flag --dry-run esegue controlli preflight ma non avvia la procedura di upgrade. Sebbene le versioni precedenti di Google Distributed Cloud eseguino i controlli preliminari, non possono essere eseguite separatamente dall'upgrade. Aggiungendo il flag --dry-run, puoi trovare e risolvere eventuali problemi rilevati dai controlli preflight nel cluster utente prima dell'upgrade.

Utilizza i deployment per ridurre al minimo le interruzioni delle applicazioni

Poiché i nodi devono essere svuotati durante gli aggiornamenti, gli upgrade del cluster possono causare interruzioni delle applicazioni. Lo svuotamento dei nodi significa che tutti i pod in esecuzione devono essere arrestati e riavviati sui nodi rimanenti del cluster.

Se possibile, le applicazioni devono utilizzare i deployment. Con questo approccio, le applicazioni sono progettate per gestire le interruzioni. L'impatto dovrebbe essere minimo per i deployment con più repliche. Puoi comunque eseguire l'upgrade del cluster se le applicazioni non utilizzano i deployment.

Esistono anche regole per i deployment che assicurano che un numero predefinito di repliche rimanga sempre in esecuzione. Queste regole sono note come PodDisruptionBudgets (PDB). I PDB ti consentono di limitare l'interruzione di un carico di lavoro quando i relativi pod devono essere riprogrammati per qualche motivo, ad esempio per upgrade o manutenzione dei nodi del cluster, e sono importanti da controllare prima di un upgrade.

Utilizza una coppia di bilanciatori del carico ad alta disponibilità

Se utilizzi Seesaw come bilanciatore del carico in un cluster, l'upgrade dei bilanciatori del carico viene eseguito automaticamente quando esegui l'upgrade del cluster. Questo upgrade può causare un'interruzione del servizio. Per ridurre l'impatto di un upgrade e di un eventuale errore del bilanciatore del carico, puoi utilizzare una coppia ad alta disponibilità (coppia HA). In questa configurazione, il sistema crea e configura due VM bilanciatore del carico in modo che possa verificarsi un failover all'altro peer.

Per aumentare la disponibilità del servizio (ovvero del server API Kubernetes), consigliamo di utilizzare sempre una coppia HA davanti al cluster di amministrazione. Per scoprire di più su Seesaw e sulla sua configurazione HA, consulta la documentazione della versione 1.16 Bilanciamento del carico in bundle con Seesaw.

Per evitare un'interruzione del servizio durante un upgrade con una coppia HA, il cluster avvia un failover prima di creare la nuova VM bilanciatore del carico. Se un cluster di utenti utilizza una sola istanza di bilanciatore del carico, si verifica un'interruzione del servizio fino al completamento dell'upgrade del bilanciatore del carico.

Ti consigliamo di avere una coppia di bilanciatori del carico ad alta disponibilità se anche il cluster di utenti è configurato per essere ad alta disponibilità. Questa serie di best practice presuppone che un cluster di utenti HA utilizzi una coppia di bilanciatori del carico HA.

Se utilizzi MetalLB come bilanciatore del carico in bundle, non è necessaria alcuna configurazione precedente all'upgrade. Il bilanciatore del carico viene sottoposto a upgrade durante il processo di upgrade del cluster.

Decidere come eseguire l'upgrade di ciascun cluster utente

Nella versione 1.14 e successive, puoi scegliere di eseguire l'upgrade di un cluster utente nel suo complesso (ovvero puoi eseguire l'upgrade del piano di controllo e di tutti i pool di nodi del cluster), oppure puoi eseguire l'upgrade del piano di controllo del cluster utente e lasciare i pool di nodi nella versione corrente. Per informazioni sul motivo per cui potresti voler eseguire l'upgrade del control plane separatamente, consulta Upgrade dei cluster utente.

In un ambiente multi-cluster, tieni traccia dei cluster utente di cui è stato eseguito l'upgrade e registra il relativo numero di versione. Se decidi di eseguire l'upgrade del control plane e dei pool di nodi separatamente, registra la versione del control plane e di ogni pool di nodi in ogni cluster.

Controllare le versioni dei cluster utente e di amministrazione

gkectl

  • Per controllare la versione dei cluster di utenti:

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig per il tuo cluster di amministrazione.

  • Per controllare la versione dei cluster di amministrazione:

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Interfaccia a riga di comando gcloud

Per i cluster registrati nell'API GKE On-Prem, puoi utilizzare la gcloud CLI per ottenere le versioni dei cluster utente, dei pool di nodi sul cluster utente e dei cluster di amministrazione.

  1. Assicurati di avere la versione più recente della CLI gcloud. Aggiorna i componenti dell'interfaccia a riga di comando gcloud, se necessario:

    gcloud components update

  2. Esegui i seguenti comandi per controllare le versioni:

  • Per controllare la versione dei cluster di utenti:

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    Sostituisci PROJECT_ID con l'ID del progetto host del tuo parco veicoli.

    Se imposti --location=-, vengono elencati tutti i cluster in tutte le regioni. Se devi restringere l'ambito dell'elenco, imposta --location sulla regione specificata quando hai registrato il cluster.

    L'output del comando include la versione del cluster.

  • Per controllare la versione dei cluster di amministrazione:

    gcloud container vmware admin-clusters list \
    --project=PROJECT_ID \
    --location=-

Controlla la versione dei nodi del cluster:

Puoi utilizzare kubectl per ottenere la versione dei nodi del cluster, ma kubectl restituisce la versione di Kubernetes. Per ottenere la versione corrispondente di Google Distributed Cloud per una versione di Kubernetes, consulta Versionamento.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig per il cluster di utenti.

Controlla se è necessario ruotare i certificati CA

Durante un upgrade, i certificati finali vengono ruotati, ma non i certificati CA. Devi ruotare manualmente i certificati CA almeno una volta ogni cinque anni. Per ulteriori informazioni, consulta Rotazione delle autorità di certificazione dei cluster utente e Rotazione dei certificati CA del cluster di amministrazione.

Differenze tra i tipi di cluster

Esistono due tipi diversi di cluster:

  • Cluster utente
  • Cluster di amministrazione

A seconda di come crei un cluster utente, questo potrebbe contenere sia i nodi worker sia i nodi del control plane (Controlplane V2) o solo i nodi worker (kubeception). Con kubeception, il control plane per un cluster utente viene eseguito su uno o più nodi in un cluster di amministrazione. In entrambi i casi, nella versione 1.14 e successive, puoi eseguire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi che eseguono i tuoi carichi di lavoro.

Effetti diversi degli upgrade del cluster utente rispetto a quelli del cluster di amministrazione

La procedura di upgrade di Google Distributed Cloud prevede un processo di svuotamento dei nodi cherimuove tutti i pod da un nodo. Il processo crea una nuova VM per ogni nodo worker svuotato e la aggiunge al cluster. I nodi worker svuotati vengono quindi rimossi dall'inventario di VMware. Durante questa procedura, qualsiasi carico di lavoro in esecuzione su questi nodi viene interrotto e riavviato su altri nodi disponibili del cluster.

A seconda dell'architettura scelta per il carico di lavoro, questa procedura potrebbe avere un impatto sulla disponibilità di un'applicazione. Per evitare un carico eccessivo sulle funzionalità delle risorse del cluster, Google Distributed Cloud esegue l'upgrade di un nodo alla volta.

Interruzioni del cluster utente

La seguente tabella descrive l'impatto di un upgrade in situ del cluster utente:

Funzione Cluster di amministrazione Cluster utente non ad alta disponibilità Cluster utente ad alta disponibilità
Accesso all'API Kubernetes Non interessato Non interessato Non interessato
Workload utente Non interessato Non interessato Non interessato
PodDisruptionBudgets* Non interessato Non interessato Non interessato
Nodo del control plane Non interessato Interessato Non interessato
Gestore della scalabilità automatica dei pod (VMware) Non interessato Non interessato Non interessato
Riparazione automatica Non interessato Non interessato Non interessato
Scalabilità automatica dei nodi (VMware) Non interessato Non interessato Non interessato
Scalabilità automatica pod orizzontale Interessato Interessato Non interessato
  • * : i PDB potrebbero causare l'interruzione o l'esito negativo dell'upgrade.
  • Affette: si verifica un'interruzione del servizio durante l'upgrade fino al suo completamento.
  • Non interessato: potrebbe verificarsi un'interruzione del servizio per un breve periodo di tempo, ma è quasi impercettibile.

I nodi del control plane del cluster utente, indipendentemente dal fatto che vengano eseguiti sul cluster di amministrazione (kubeception) o sul cluster utente stesso (Controlplane v2), non eseguono carichi di lavoro degli utenti. Durante un upgrade, questi nodi del piano di controllo vengono svuotati e poi aggiornati di conseguenza.

Negli ambienti con piani di controllo ad alta disponibilità (HA), l'upgrade del piano di controllo di un cluster utente non interrompe i carichi di lavoro degli utenti. In un ambiente HA, l'upgrade di un cluster di amministrazione non interrompe i carichi di lavoro degli utenti. Per i cluster utente che utilizzano Controlplane v2, l'upgrade solo del piano di controllo non interrompe i carichi di lavoro degli utenti.

Durante un upgrade in un ambiente del piano di controllo non ad alta disponibilità, il piano di controllo non può controllare le azioni di scalabilità, recupero o deployment dei pod. Durante la breve interruzione del piano di controllo durante l'upgrade, i carichi di lavoro degli utenti possono essere interessati se si trovano in uno stato di scalabilità, di implementazione o di recupero. Ciò significa che gli implementamenti non andranno a buon fine durante un upgrade in un ambiente non ad alta disponibilità.

Per migliorare la disponibilità e ridurre l'interruzione dei cluster utente di produzione durante gli upgrade, ti consigliamo di utilizzare tre nodi del piano di controllo (modalità ad alta disponibilità).

Interruzione del cluster di amministrazione

La tabella seguente descrive l'impatto di un upgrade del cluster amministrativo in situ:

Funzione Cluster di amministrazione Cluster utente non ad alta disponibilità Cluster utente ad alta disponibilità
Accesso all'API Kubernetes Interessato Interessato Non interessato
Workload utente Non interessato Non interessato Non interessato
Nodo del control plane Interessato Interessato Non interessato
Gestore della scalabilità automatica dei pod Interessato Interessato Non interessato
Autofficina Interessato Interessato Non interessato
Scalabilità automatica dei nodi Interessato Interessato Non interessato
Scalabilità automatica pod orizzontale Interessato Interessato Non interessato
  • Affette: si verifica un'interruzione del servizio durante l'upgrade fino al suo completamento.
  • Non interessato: potrebbe verificarsi un'interruzione del servizio per un breve periodo di tempo, ma è quasi impercettibile.

Passaggi successivi