Best practice per gli upgrade dei cluster Google Distributed Cloud

Le best practice per l'upgrade strutturato di Google Distributed Cloud ti consentono di ridurre al minimo le interruzioni del servizio e i rischi operativi. La convalida pre-upgrade aiuta a garantire che i cluster e i workload rimangano stabili durante ogni transizione di versione.

Per gli ambienti che comprendono i livelli di test, sviluppo e produzione, esegui gli upgrade in sequenza, iniziando dal livello meno critico. La verifica dello stato del cluster e del comportamento del workload in ogni fase ti aiuta a identificare potenziali problemi prima di aggiornare i sistemi di produzione.

Elenco di controllo per l'upgrade

Ti consigliamo di seguire tutte le best practice descritte in questo documento. Utilizza il seguente elenco di controllo per monitorare i tuoi progressi. Ogni elemento dell'elenco rimanda a una sezione di questo documento con ulteriori informazioni:

Una volta completati questi controlli, puoi avviare il processo di upgrade. Monitora l'avanzamento finché non viene eseguito l'upgrade di tutti i cluster.

Pianifica l'upgrade

Gli aggiornamenti possono essere fastidiosi. Prima di iniziare l'upgrade, pianifica attentamente per assicurarti che l'ambiente e le applicazioni siano pronti e preparati.

Stima l'impegno in termini di tempo e pianifica un periodo di manutenzione

Il tempo necessario per eseguire l'upgrade di un cluster varia in base al numero di nodi e alla densità del workload in esecuzione su di essi. Per completare correttamente un upgrade del cluster, utilizza un periodo di manutenzione con tempo sufficiente.

Per calcolare una stima approssimativa dell'upgrade, utilizza 10 minutes * the number of nodes per l'upgrade di un singolo nodo contemporaneo.

Ad esempio, se hai 50 nodi in un cluster, il tempo di upgrade totale sarà di circa 500 minuti: 10 minutes * 50 nodes = 500 minutes.

Verifica la compatibilità di altri prodotti Google Cloud

Se il tuo cluster esegue Cloud Service Mesh, Config Sync o Policy Controller, controlla Supporto delle versioni e degli upgrade e verifica le versioni supportate con Google Distributed Cloud prima e dopo l'upgrade.

Il controllo di compatibilità si basa sul cluster di amministrazione o utente in cui è stato eseguito il deployment di Cloud Service Mesh, Config Sync o Policy Controller.

Controlla l'utilizzo delle risorse del cluster

Per assicurarti 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, controlla l'utilizzo attuale delle risorse del cluster. Per controllare l'utilizzo delle risorse per il tuo cluster, utilizza le dashboard personalizzate in Google Cloud Observability.

Puoi utilizzare comandi come kubectl top nodes per ottenere l'utilizzo attuale delle risorse del cluster, ma le dashboard possono fornire una visualizzazione più dettagliata delle risorse consumate nel tempo. Questi dati sull'utilizzo delle risorse possono aiutare a indicare quando un upgrade causerebbe il minor numero di interruzioni, ad esempio durante i fine settimana o la sera, a seconda del workload in esecuzione e dei casi d'uso.

La tempistica dell'upgrade del cluster di amministrazione potrebbe essere meno critica rispetto a quella dei cluster utente, perché l'upgrade di un cluster di amministrazione di solito non comporta tempi di inattività dell'applicazione. Tuttavia, è comunque importante verificare la disponibilità delle risorse 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 i periodi di utilizzo meno attivi, quando l'accesso di gestione al cluster è meno critico.

Risorse del control plane del cluster di amministrazione

Tutti i controller e i job di upgrade vengono eseguiti nei nodi del control plane del cluster di amministrazione. Controlla il consumo di risorse di questi nodi del control plane per verificare le risorse di computing disponibili. In genere, il processo di upgrade richiede 1000 millicore di CPU (1000 mCPU) e 2-3 GiB di RAM per ogni set di controller del ciclo di vita. Tieni presente che l'unità CPU "mCPU" sta per "millesimo di core", quindi 1000 millicore equivalgono a un core su ogni nodo per ogni set di controller del ciclo di vita. Per ridurre le risorse di computing aggiuntive necessarie durante un upgrade, prova a mantenere i cluster utente nella stessa versione.

Nel seguente deployment di esempio, i due cluster utente hanno versioni diverse rispetto al cluster di amministrazione:

Cluster di amministrazione Cluster utente 1 Cluster utente 2
1.13.3 1.13.0 1.13.2

Nel controller di amministrazione viene eseguito il deployment di un insieme di controller del ciclo di vita per ogni versione in uso. In questo esempio, sono presenti tre set di controller del ciclo di vita: 1.13.3, 1.13.0 e 1.13.2. Ogni set di controller del ciclo di vita consuma un totale di 1000 mCPU e 3 GiB di RAM. Il consumo totale attuale di risorse di questi controller del ciclo di vita è di 3000 mCPU e 9 GiB di RAM.

Se viene eseguito l'upgrade del cluster utente 2 alla versione 1.13.3, ora sono presenti due set di controller del ciclo di vita: 1.13.3 e 1.13.0:

Cluster di amministrazione Cluster utente 1 Cluster utente 2
1.13.3 1.13.0 1.13.3

I controller del ciclo di vita ora consumano un totale di 2000 mCPU e 6 GiB di RAM.

Se viene eseguito l'upgrade del cluster utente 1 alla versione 1.13.3, tutti i cluster del parco risorse vengono eseguiti con la stessa versione: 1.13.3:

Cluster di amministrazione Cluster utente 1 Cluster utente 2
1.13.3 1.13.3 1.13.3

Ora esiste un solo set di controller del ciclo di vita, che consumano un totale di 1000 mCPU e 3 GiB di RAM.

Nell'esempio seguente, tutti i cluster utente hanno la stessa versione. Se viene eseguito l'upgrade del cluster di amministrazione, vengono utilizzati solo due set di controller del ciclo di vita, quindi il consumo di risorse di computing è ridotto:

Cluster di amministrazione Cluster utente 1 Cluster utente 2
1.14.0 1.13.3 1.13.3

In questo esempio, i controller del ciclo di vita consumano nuovamente un totale di 2000 mCPU e 6 GiB di RAM fino a quando non viene eseguito l'upgrade di tutti i cluster utente alla stessa versione del cluster di amministrazione.

Se i nodi del control plane non dispongono di risorse di computing aggiuntive durante l'upgrade, potresti vedere pod come anthos-cluster-operator, capi-controller-manager, cap-controller-manager o cap-kubeadm-bootstraper in uno stato Pending. Per risolvere il problema, esegui l'upgrade di alcuni cluster utente alla stessa versione per consolidare le versioni e ridurre il numero di controller del ciclo di vita in uso. Se l'upgrade è già bloccato, puoi anche utilizzare kubectl edit deployment per modificare i deployment in attesa in modo da ridurre le richieste di CPU e RAM in modo che rientrino nel control plane del cluster di amministrazione.

La tabella seguente descrive i requisiti delle risorse di computing per i diversi scenari di upgrade:

Cluster Risorse del cluster di amministrazione richieste
Upgrade del cluster utente Upgrade alla stessa versione di altri cluster: N/A

Upgrade a una versione diversa di altri cluster di amministrazione o utente: 1000 mCPU e 3 GiB di RAM

I cluster utente in un cluster ibrido hanno gli stessi requisiti di risorse.
Upgrade del cluster di amministrazione (con cluster utente) 1000 mCPU e 3 GiB di RAM
Upgrade del cluster ibrido (senza cluster utente) Picco di 1000 mCPU e 3 GiB di RAM. Le risorse vengono restituite dopo l'uso.
Autonoma Picco di 200 mCPU e 1 GiB di RAM. Le risorse vengono restituite dopo l'uso.

Esegui il backup dei cluster

Prima di iniziare un upgrade, esegui il backup dei cluster utilizzando il comando bmctl backup cluster.

Poiché il file di backup contiene informazioni sensibili, archivialo in modo sicuro.

Verifica che i cluster siano configurati e funzionino correttamente

Per controllare l'integrità di un cluster prima di un upgrade, esegui bmctl check cluster sul cluster. Il comando esegue controlli avanzati, ad esempio per identificare i nodi che non sono configurati correttamente o che hanno pod bloccati.

Quando esegui il comando bmctl upgrade cluster per eseguire l'upgrade dei cluster, vengono eseguiti alcuni controlli preflight. Il processo di upgrade si interrompe se questi controlli non vanno a buon fine. È meglio identificare e risolvere questi problemi in modo proattivo con il comando bmctl check cluster, anziché fare affidamento sui controlli preflight, che servono a proteggere i cluster da eventuali danni.

Esamina i deployment dei workload degli utenti

Ci sono due aree da considerare per i workload degli utenti: svuotamento e compatibilità API.

Draining del workload

Durante un upgrade, il workload utente su un nodo viene svuotato. Se il workload ha una singola replica o se tutte le repliche si trovano sullo stesso nodo, lo svuotamento del workload potrebbe causare interruzioni dei servizi in esecuzione nel cluster. Esegui i tuoi workload con più repliche. Il numero di repliche deve essere superiore al numero di nodi simultanei.

Per evitare un upgrade bloccato, il processo di svuotamento dell'upgrade alla versione 1.36 non rispetta i budget di interruzione dei pod (PDB). I workload potrebbero essere eseguiti in uno stato di degrado e la replica con il minor numero di servizi sarebbe total replica number - concurrent upgrade number.

Compatibilità API

Per la compatibilità delle API, verifica la compatibilità delle API del workload con la versione secondaria più recente di Kubernetes quando esegui l'upgrade di una versione secondaria. Se necessario, esegui l'upgrade del workload a una versione compatibile. Ove possibile, il team di progettazione di GKE fornisce istruzioni per identificare i workload che utilizzano API incompatibili, come le API Kubernetes rimosse.

Se utilizzi Cloud Service Mesh, Config Sync, Policy Controller, verifica se la versione installata è compatibile con la nuova versione di Google Distributed Cloud. Per informazioni sulla compatibilità delle versioni, consulta Supporto per versioni e upgrade.

Controlla l'utilizzo dei webhook

Controlla se il cluster ha webhook, in particolare risorse pod per scopi di controllo come Policy Controller. Il processo di svuotamento durante l'upgrade del cluster potrebbe interrompere il servizio webhook di Policy Controller, il che può causare il blocco o il prolungamento dell'upgrade. Ti consigliamo di disattivare temporaneamente questi webhook o di utilizzare un deployment ad alta affidabilità (HA).

Esamina l'utilizzo delle funzionalità in anteprima

Le funzionalità in anteprima sono soggette a modifiche e vengono fornite solo a scopo di test e valutazione. Non utilizzare le funzionalità in anteprima nei cluster di produzione. Non garantiamo che i cluster che utilizzano le funzionalità in anteprima possano essere sottoposti ad upgrade. In alcuni casi, blocchiamo esplicitamente gli upgrade per i cluster che utilizzano funzionalità in anteprima.

Per informazioni sulle modifiche che provocano un errore relative all'upgrade, consulta le note di rilascio.

Controlla lo stato di SELinux

Se vuoi attivare SELinux per proteggere i container, devi assicurarti che SELinux sia attivato in modalità Enforced su tutte le macchine host. A partire dalla versione 1.9.0 o successive di Google Distributed Cloud, puoi attivare o disattivare SELinux prima o dopo la creazione o l'upgrade del cluster. SELinux è abilitato per impostazione predefinita su Red Hat Enterprise Linux (RHEL). Se SELinux è disattivato sulle tue macchine host o se non hai la certezza che sia attivo, consulta Protezione dei container con SELinux per istruzioni su come attivarlo.

Google Distributed Cloud supporta SELinux solo nei sistemi RHEL.

Non modificare la configurazione della densità dei pod

Google Distributed Cloud supporta la configurazione di un massimo di 250 pod per nodo con nodeConfig.PodDensity.MaxPodsPerNode. Puoi configurare la densità dei pod solo durante la creazione del cluster. Non puoi aggiornare le impostazioni di densità dei pod per i cluster esistenti. Non tentare di modificare la configurazione della densità dei pod durante un upgrade.

Assicurati che i nodi del control plane e del bilanciatore del carico non siano in modalità di manutenzione

Prima di avviare un upgrade, assicurati che i nodi del control plane e del bilanciatore del carico non siano in manutenzione. Se un nodo è in modalità di manutenzione, l'upgrade viene messo in pausa per garantire che i pool di nodi del control plane e del bilanciatore del carico siano sufficientemente disponibili.

Passaggi successivi