Questo documento descrive le best practice e le considerazioni per eseguire l'upgrade di GKE su Bare Metal. Scoprirai come prepararti agli upgrade dei cluster e le best practice da 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, come test, e di 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 tenere traccia dei tuoi progressi. Ogni voce dell'elenco rimanda a una sezione del documento con ulteriori informazioni:
Una volta completati questi controlli, puoi avviare il processo di upgrade. Monitora l'avanzamento fino a quando non viene eseguito l'upgrade di tutti i cluster.
Pianifica l'upgrade
Gli aggiornamenti possono essere fastidiosi. Prima di iniziare l'upgrade, pianifica attentamente che il tuo ambiente e le tue 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 carico di lavoro eseguito 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 simultaneo.
Ad esempio, se hai cinquanta nodi in un cluster, il tempo totale di upgrade sarà di circa cinquecento minuti: 10 minutes * 50 nodes = 500 minutes.
Verifica la compatibilità di altri componenti Anthos
Se il tuo cluster esegue componenti Anthos come Anthos Service Mesh o Config Management, controlla la matrice di compatibilità di Anthos e verifica le versioni supportate con GKE su Bare Metal prima e dopo l'upgrade.
Il controllo della compatibilità si basa sul cluster di amministrazione o utente in cui viene eseguito il deployment di Anthos Service Mesh o Config Management.
Controlla l'utilizzo delle risorse del cluster
Per assicurarti che i pod possano essere evacuati quando il nodo viene svuotato e che ci siano risorse sufficienti nel cluster in fase di upgrade per gestire l'upgrade, controlla l'utilizzo attuale delle risorse del cluster. Per verificare l'utilizzo delle risorse per il tuo cluster, usa le dashboard personalizzate nella suite operativa di Google Cloud.
Puoi utilizzare comandi, come kubectl top nodes, per ottenere l'utilizzo attuale delle risorse del cluster, ma le dashboard possono fornire una visione più dettagliata delle risorse utilizzate nel tempo. Questi dati sull'utilizzo delle risorse possono aiutare a indicare quando un upgrade causerebbe l'interruzione minima, ad esempio durante i fine settimana o la sera, a seconda del carico di lavoro in esecuzione e dei casi d'uso.
I tempi per l'upgrade del cluster di amministrazione potrebbero essere meno critici rispetto ai cluster utente, perché l'upgrade del cluster di amministrazione di solito non introduce tempi di inattività delle applicazioni. È comunque importante verificare la presenza di risorse gratuite prima di iniziare un upgrade del cluster di amministrazione. Inoltre, l'upgrade del cluster di amministrazione potrebbe comportare dei rischi e, di conseguenza, potrebbe essere consigliato durante periodi di utilizzo meno attivi, quando l'accesso per la 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. Controlla il consumo di risorse di questi nodi del piano di controllo per verificare la presenza di 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 "millesima di core", quindi 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 la stessa versione dei cluster utente.
Nel deployment di esempio seguente, i due cluster utente si trovano in 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 |
Viene eseguito il deployment di un set di controller del ciclo di vita nel controller di amministrazione per ogni versione in uso. In questo esempio, ci sono 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. L'attuale consumo totale delle 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 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 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 a 1.13.3, il parco risorse ora viene eseguito tutti nella 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 consuma un totale di 1000 mCPU e 3 GiB di RAM.
Nell'esempio seguente, tutti i cluster utente sono la stessa versione. Se viene eseguito l'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 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 hanno 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 stato Pending. Per risolvere questo 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 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 i diversi scenari di upgrade:
| Cluster | Risorse del cluster di amministrazione richieste |
|---|---|
| Upgrade del cluster utente | Esegui l'upgrade alla stessa versione di 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 in termini 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 RAM di 1000 mCPU e 3 GiB. Le risorse vengono restituite dopo l'uso. |
| Autonoma | Picco di RAM di 200 mCPU e 1 GiB. Le risorse vengono restituite dopo l'uso. |
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 non configurati correttamente o che hanno pod in stato bloccato.
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 hanno esito positivo. È preferibile identificare e risolvere in modo proattivo questi problemi con il comando bmctl check cluster, anziché fare affidamento sui controlli preflight che consentono di proteggere i cluster da eventuali danni.
Esamina i deployment dei carichi di lavoro degli utenti
Esistono due aree da considerare per i carichi di lavoro degli utenti: svuotamento e compatibilità delle API.
Svuotamento dei carichi di lavoro
Il carico di lavoro 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 interruzioni dei servizi in esecuzione nel cluster. Esegui i carichi di lavoro con più repliche. Il numero di replica deve essere superiore al numero di nodi simultanei.
Per evitare che un upgrade si blocchi, il processo di svuotamento dell'upgrade alla versione 1.14 non rispetta i budget di interruzione dei pod (PDB). I carichi di lavoro potrebbero essere eseguiti in uno stato ridotto e la replica di gestione minima sarebbe total
replica number - concurrent upgrade number.
Compatibilità delle API
Per la compatibilità delle API, verifica la compatibilità dell'API Workload 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 di tecnici di Anthos fornisce istruzioni per identificare i carichi di lavoro utilizzando API incompatibili, ad esempio API Kubernetes 1.22 deprecate.
Se utilizzi Anthos Service Mesh, Config Management o altri componenti GKE Enterprise, verifica se la versione installata è compatibile con la nuova versione di GKE su Bare Metal. Per informazioni sulla compatibilità della versione dei componenti GKE Enterprise, vedi Supporto per la versione e l'upgrade di Anthos.
Controlla l'utilizzo dei webhook
Verifica 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 un blocco dell'upgrade o richiedere molto tempo. Ti consigliamo di disattivare temporaneamente questi webhook o di utilizzare un deployment ad alta disponibilità.
Esamina l'utilizzo delle funzionalità in anteprima
Le funzionalità di anteprima sono soggette a modifica e sono fornite solo a scopo di test e valutazione. Non utilizzare le funzionalità in anteprima nei cluster di produzione. Non garantiamo che sia possibile eseguire l'upgrade dei cluster che utilizzano funzionalità in anteprima. In alcuni casi, blocchiamo esplicitamente gli upgrade per i cluster che utilizzano le 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 abilitare SELinux per proteggere i tuoi container, devi assicurarti che
SELinux sia abilitato in modalità Enforced su tutti i computer host. A partire da GKE su Bare Metal 1.9.0 o versioni successive, puoi abilitare o disabilitare SELinux prima o dopo la creazione o l'upgrade del cluster. SELinux è abilitato per impostazione predefinita su Red Hat Enterprise Linux (RHEL) e CentOS. Se SELinux è disabilitato sui computer host o se hai dubbi, consulta Protezione dei container utilizzando SELinux per istruzioni su come abilitarlo.
GKE su Bare Metal supporta SELinux solo nei sistemi RHEL e CentOS.
Non modificare la configurazione della densità dei pod
GKE su Bare Metal 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 iniziare un upgrade, assicurati che non siano in manutenzione i nodi del piano di controllo e del bilanciatore del carico. 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
- Esegui l'upgrade di Anthos clusters on bare metal
- Scopri di più sul ciclo di vita e sulle fasi degli upgrade
- Risolvere i problemi di upgrade dei cluster