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. Imparerai come prepararti per gli upgrade dei cluster e quali best practice seguire prima dell'upgrade. Queste best practice aiutano a ridurre i rischi associati agli upgrade dei cluster.

Se disponi di più ambienti, ad esempio test, sviluppo e produzione, ti consigliamo di iniziare con l'ambiente meno critico, ad esempio test, e verificare la funzionalità di upgrade. Dopo aver verificato che l'upgrade sia riuscito, passa all'ambiente successivo. Ripeti questo processo fino a quando non esegui l'upgrade degli ambienti di produzione. Questo approccio ti consente di passare da un punto critico all'altro e verificare che l'upgrade e i carichi di lavoro vengano tutti eseguiti correttamente.

Elenco di controllo per l'upgrade

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

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

Pianifica l'upgrade

Gli aggiornamenti possono essere invasivi. Prima di avviare l'upgrade, pianifica con attenzione 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 l'upgrade di un cluster varia in base al numero di nodi e alla densità dei carichi di lavoro eseguiti su di essi. Per completare correttamente l'upgrade del cluster, utilizza un periodo di manutenzione con tempo sufficiente.

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

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

Verificare la compatibilità di altri componenti di GKE Enterprise

Se il cluster esegue componenti GKE Enterprise come Anthos Service Mesh, Config Sync, Policy Controller o Config Controller, consulta il supporto per la versione e l'upgrade di GKE Enterprise 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 Anthos Service Mesh, Config Sync, Policy Controller o Config 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, usa 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 utilizzate nel tempo. Questi dati sull'utilizzo delle risorse possono essere utili per indicare quando un upgrade potrebbe causare le interruzioni minime, ad esempio durante i fine settimana o la sera, a seconda del carico di lavoro in esecuzione e dei casi d'uso.

La tempistica per l'upgrade del cluster di amministrazione potrebbe essere meno critica rispetto a quella dei cluster utente, perché un upgrade del cluster di amministrazione di solito non introduce tempi di inattività delle applicazioni. Tuttavia, è comunque importante verificare le risorse disponibili prima di iniziare l'upgrade del cluster di amministrazione. Inoltre, l'upgrade del cluster di amministrazione potrebbe comportare dei rischi e pertanto potrebbe essere consigliato durante i periodi di utilizzo meno attivi, quando l'accesso da parte della gestione al cluster è meno critico.

Risorse del piano di controllo del cluster di amministrazione

Tutti i controller e i job di upgrade vengono eseguiti nei nodi del piano di controllo del cluster di amministrazione. Verifica il consumo delle risorse di questi nodi del piano di controllo per verificare se ci sono risorse di calcolo disponibili. Il processo di upgrade richiede in genere 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" è l'acronimo di "milionesimo di un core", quindi 1000 millicore equivale a un core su ciascun nodo per ogni set di controller del ciclo di vita. Per ridurre le risorse di calcolo aggiuntive necessarie durante un upgrade, prova a mantenere i cluster utente alla stessa versione.

Nel deployment di esempio seguente, 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

Per ogni versione in uso viene eseguito il deployment di un set di controller del ciclo di vita nel controller di amministrazione. In questo esempio, sono presenti tre insiemi di controller del ciclo di vita: 1.13.3, 1.13.0 e 1.13.2. Ogni set di controller del ciclo di vita utilizza un totale di 1000 mCPU e 3 GiB di RAM. L'attuale consumo di risorse totale di questi controller del ciclo di vita è di 3000 mCPU e 9 GiB di RAM.

Se viene eseguito l'upgrade del cluster utente 2 a 1.13.3, ora esistono 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

Ora i controller del ciclo di vita consumano 2000 mCPU totali e 6 GiB di RAM.

Se viene eseguito l'upgrade del cluster utente 1 a 1.13.3, il parco risorse ora viene eseguito sulla 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 corrispondono alla stessa versione. In caso di upgrade del cluster di amministrazione, vengono utilizzati solo due set di controller del ciclo di vita, in modo da ridurre il consumo di risorse di calcolo:

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 di nuovo un totale di 2000 mCPU e 6 GiB di RAM finché non viene eseguito l'upgrade di tutti i cluster utente alla stessa versione del cluster di amministrazione.

Se i nodi del piano di controllo non hanno risorse di calcolo aggiuntive durante l'upgrade, potresti vedere pod come anthos-cluster-operator, capi-controller-manager, cap-controller-manager o cap-kubeadm-bootstraper in 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 utilizzare kubectl edit deployment anche per modificare i deployment in attesa per ridurre le richieste di CPU e RAM in modo che rientrino nel piano di controllo del cluster di amministrazione.

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

Cluster Risorse del cluster di amministrazione necessarie
Upgrade del cluster utente Esegui l'upgrade alla stessa versione degli altri cluster: N/D

Esegui l'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 per le 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'utilizzo.
Autonoma Picco di 200 mCPU e 1 GiB di RAM. Le risorse vengono restituite dopo l'utilizzo.

Esegui il backup dei cluster

Prima di avviare 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 verificare 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 i cui pod sono 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 in modo proattivo questi problemi con il comando bmctl check cluster, anziché fare affidamento sui controlli preflight disponibili per proteggere i cluster da eventuali danni.

Esamina i deployment dei carichi di lavoro degli utenti

Ci sono due aree da considerare per i carichi di lavoro utente: drenaggio e compatibilità API.

Svuotamento del carico di lavoro

Il carico di lavoro dell'utente su un nodo viene svuotato durante un upgrade. Se il carico di lavoro ha una singola replica o tutte le repliche si trovano sullo stesso nodo, lo svuotamento dei carichi di lavoro potrebbe causare un'interruzione dei servizi in esecuzione nel cluster. Esegui i carichi di lavoro con più repliche. Il numero di replica deve essere superiore al numero di nodo simultaneo.

Per evitare un upgrade bloccato, il processo di svuotamento dell'upgrade fino a 1,29 non rispetta i budget di interruzione dei pod (PDB). I carichi di lavoro potrebbero essere eseguiti in uno stato ridotto e la replica con minor erogazione sarà total replica number - concurrent upgrade number.

Compatibilità delle API

Per la compatibilità delle API, verifica la compatibilità dell'API del carico di lavoro con la versione secondaria più recente di Kubernetes quando esegui un upgrade della versione secondaria. Se necessario, esegui l'upgrade del carico di lavoro a una versione compatibile. Ove possibile, il team tecnico di GKE Enterprise fornisce istruzioni per identificare i carichi di lavoro utilizzando API incompatibili, come le API Kubernetes rimosse.

Se utilizzi Anthos Service Mesh, Config Sync, Policy Controller, Config Controller o altri componenti GKE Enterprise, verifica che la versione installata sia compatibile con la nuova versione di Google Distributed Cloud. Per informazioni sulla compatibilità della versione del componente GKE Enterprise, consulta Supporto per la versione e l'upgrade di GKE Enterprise.

Controlla l'utilizzo dei webhook

Controlla se il cluster ha webhook, in particolare le risorse dei 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, causando il blocco dell'upgrade o tempi lunghi. Ti consigliamo di disabilitare temporaneamente questi webhook o di utilizzare un deployment ad alta disponibilità.

Esaminare l'utilizzo delle funzionalità in anteprima

Le funzionalità di anteprima sono soggette a modifiche e vengono fornite solo a scopo di test e valutazione. Non utilizzare le funzionalità in anteprima sui cluster di produzione. Non garantiamo che sia possibile eseguire l'upgrade dei cluster che utilizzano le funzionalità in anteprima. In alcuni casi, blocchiamo esplicitamente gli upgrade per i cluster che usano le funzionalità in anteprima.

Per informazioni sull'interruzione delle modifiche relative all'upgrade, consulta le note di rilascio.

Controllare lo stato di SELinux

Se vuoi abilitare SELinux per proteggere i container, devi assicurarti che SELinux sia abilitato in modalità Enforced su tutte le macchine host. A partire dalla versione 1.9.0 di Google Distributed Cloud o successive, puoi abilitare o disabilitare SELinux prima o dopo la creazione del cluster o gli upgrade del cluster. SELinux è abilitato per impostazione predefinita su Red Hat Enterprise Linux (RHEL). Se SELinux è disabilitato sulle tue macchine host o se hai dubbi, 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 provare a modificare la configurazione della densità dei pod durante un upgrade.

Assicurati che i nodi del piano di controllo e del bilanciatore del carico non siano in modalità di manutenzione

Prima di avviare un upgrade, assicurati che i nodi del piano di controllo 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 piano di controllo e del bilanciatore del carico siano sufficientemente disponibili.

Passaggi successivi