Best practice per gli upgrade dei cluster Google Distributed Cloud

Questo documento descrive le best practice e le considerazioni per l'upgrade Google Distributed Cloud. Scopri come prepararti agli upgrade dei cluster e le best practice da seguire prima dell'upgrade. Queste best practice aiutano a ridurre e 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 è stato eseguito correttamente, passa all'ambiente successivo. Ripeti questa procedura fino a quando non esegui l'upgrade degli ambienti di produzione. Questo approccio ti permette di passare da un punto critico a quello successivo e verifica che l'upgrade e i carichi di lavoro funzionano tutti 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. Collega ogni elemento dell'elenco a una sezione di questo documento contenente ulteriori informazioni:

Al termine di questi controlli, puoi avviare la procedura di upgrade. Monitora il l'avanzamento finché non viene eseguito correttamente l'upgrade di tutti i cluster.

Pianifica l'upgrade

Gli aggiornamenti possono causare interruzioni. Prima di iniziare l'upgrade, pianifica con attenzione assicurati che il tuo ambiente e le tue applicazioni siano pronti e preparati.

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

Il tempo necessario per eseguire l'upgrade di un cluster varia in base al numero dei nodi e la densità dei carichi di lavoro eseguiti su di essi. Per completare correttamente dell'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 disponi di cinquanta nodi in un cluster, il tempo totale di upgrade sarà di circa cinquecento minuti: 10 minutes * 50 nodes = 500 minutes.

Verificare la compatibilità di altri componenti di GKE Enterprise

Se il tuo cluster esegue componenti GKE Enterprise come Cloud Service Mesh, Config Sync, Policy Controller o Config Controller, controlla la versione di GKE Enterprise e l'assistenza per l'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 che Cloud Service Mesh, Config Sync, Policy Controller o Config Controller in cui viene eseguito il deployment.

Controlla l'utilizzo delle risorse del cluster

Per assicurarti che i pod possano essere evacuati quando il nodo si scarica e che nel cluster di cui viene eseguito l'upgrade siano presenti risorse sufficienti per gestire l'upgrade, controlla l'utilizzo corrente 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 il cluster attuale utilizzo delle risorse, ma le dashboard possono fornire una visualizzazione più dettagliata delle risorse consumate nel tempo. Questi dati sull'utilizzo delle risorse possono essere utili per indicare quando l'upgrade causerebbe meno interruzioni, ad esempio durante i fine settimana o la sera, a seconda del carico di lavoro in esecuzione e dei casi d'uso.

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 disponibilità delle risorse prima di iniziare un upgrade del cluster di amministrazione. Inoltre, l'upgrade dell'amministratore potrebbe comportare dei rischi e, di conseguenza, potrebbe essere consigliato in casi periodi di utilizzo attivi in cui 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 amministrativo. Controlla il consumo di risorse di questi nodi del control plane per verificare la disponibilità di risorse di calcolo. La procedura di upgrade richiede in genere 1000 millicore di CPU (1000 mCPU) e 2-3 GB di RAM per ogni set di controller del ciclo di vita. Tieni presente che l'unità CPU "mCPU" è l'acronimo di "milioness of a core", per cui 1000 millicore sono l'equivalente di un core su ciascun nodo per ogni set di controller del ciclo di vita. Per ridurre le risorse di calcolo aggiuntive richieste durante un upgrade, prova a mantenere i cluster utente nella stessa versione.

Nel deployment di esempio seguente, i due cluster utente si trovano a posizioni diverse rispetto al cluster di amministrazione:

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

Nel controller di amministrazione viene implementato un insieme di controller del ciclo di vita per ogni versione in uso. 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 consuma un totale di 1000 mCPU e 3 GB di RAM. Il consumo totale di risorse corrente di questi controller del ciclo di vita è di 3000 mCPU e 9 GB di RAM.

Se viene eseguito l'upgrade del cluster utente 2 a 1.13.3, ora sono disponibili due insiemi di controller del ciclo di vita: 1.13.3 e 1.13.0:

Cluster di amministrazione Cluster di utenti 1 Cluster di utenti 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 alla versione 1.13.3, ora tutto il parco risorse viene eseguito con la stessa versione: 1.13.3.

Cluster di amministrazione Cluster di utenti 1 Cluster di utenti 2
1.13.3 1.13.3 1.13.3

Ora esiste un solo insieme di controller del ciclo di vita, che consumano in totale 1000 mCPU e 3 GB di RAM.

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

Cluster di amministrazione Cluster di utenti 1 Cluster di utenti 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 GB 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 piano di controllo non dispongono di risorse di calcolo aggiuntive durante l'upgrade, potresti visualizzare 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 di utenti 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 le implementazioni in attesa in modo da ridurre le richieste di CPU e RAM in modo che rientrino nel piano di controllo del cluster amministrativo.

La tabella seguente illustra i requisiti delle risorse di calcolo per diversi scenari di upgrade:

Cluster Risorse del cluster di amministrazione richieste
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 la stessa risorsa i tuoi requisiti.
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, eseguire il backup dei cluster con il comando bmctl backup cluster.

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

Verificare 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 hanno pod bloccati.

Quando esegui il comando bmctl upgrade cluster per eseguire l'upgrade dei cluster, vengono eseguiti alcuni controlli preflight. Se questi controlli non vengono eseguiti, il processo di upgrade si interrompe riuscito. È meglio identificare e risolvere in modo proattivo questi problemi con il comando bmctl check cluster, anziché fare affidamento sui controlli preliminari che hanno lo scopo di proteggere i cluster da eventuali danni.

Rivedi i deployment dei carichi di lavoro degli utenti

Per i carichi di lavoro degli utenti, sono da considerare due aspetti: svuotamento e compatibilità con le API.

Scarico 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 se tutte le repliche si trovano sullo stesso nodo, lo svuotamento del carico di lavoro potrebbe causare interruzioni dei servizi in esecuzione nel cluster. Esegui i carichi di lavoro con più repliche. Il numero di replica deve essere superiore al nodo simultaneo numero.

Per evitare un upgrade bloccato, il processo di svuotamento dell'upgrade fino alla versione 1.30 non rispetta i budget di interruzione dei pod. I carichi di lavoro potrebbero essere eseguiti in uno stato di degradamento e la replica con il minor numero di pubblicazioni sarebbe total replica number - concurrent upgrade number.

Compatibilità delle API

Per la compatibilità delle API, controlla la compatibilità delle API dei carichi di lavoro con le API secondarie più recenti di Kubernetes durante l'upgrade di una versione secondaria. Se necessario, esegui l'upgrade del workload a una versione compatibile. Ove possibile, il team di ingegneria di GKE Enterprise fornisce istruzioni per identificare i carichi di lavoro che utilizzano API incompatibili, ad esempio le API Kubernetes rimosse.

Se utilizzi Cloud Service Mesh, Config Sync, Policy Controller, Config Controller o altri componenti di GKE Enterprise, controlla se la versione installata è compatibile con la nuova versione di Google Distributed Cloud. Per informazioni sulla compatibilità delle versioni dei componenti GKE Enterprise, consulta Versione di GKE Enterprise e assistenza per l'upgrade.

Controllare l'utilizzo dei webhook

Controlla se il tuo 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, causando così l'upgrade bloccarsi o richiedere molto tempo. Ti consigliamo di disattivare temporaneamente questi webhook o di utilizzare un deployment ad alta disponibilità (HA).

Rivedi l'utilizzo delle funzionalità di anteprima

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

Per informazioni sulle modifiche che causano interruzioni relative all'upgrade, consulta le note di rilascio.

Controllare lo stato di SELinux

Se vuoi abilitare SELinux per proteggere i tuoi container, devi assicurarti SELinux è abilitato in modalità Enforced su tutte le macchine host. A partire dalla release 1.9.0 o successive di Google Distributed Cloud, puoi abilitare o disabilitare SELinux prima o dopo la creazione o gli upgrade dei cluster. SELinux è abilitato da come predefinita su Red Hat Enterprise Linux (RHEL). Se SELinux è disabilitato su dalle macchine host o se non sai con certezza 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 cluster. Non tentare di 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

Assicurati che i nodi del piano di controllo e del bilanciatore del carico non siano in manutenzione prima di iniziare un upgrade. 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