Questo documento descrive le best practice e le considerazioni per l'upgrade Google Distributed Cloud. Imparerai a prepararti per gli upgrade dei cluster e 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 verifica la funzionalità di upgrade. Dopo aver verificato che è stato eseguito correttamente, passa all'ambiente successivo. Ripeti il processo 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 correttamente.
Elenco di controllo per l'upgrade
Ti consigliamo di seguire tutte le best practice riportate in questo documento. Utilizza la seguente elenco di controllo per aiutarti a tenere traccia dei tuoi progressi. Collega ogni elemento dell'elenco a una sezione di questo documento contenente ulteriori informazioni:
Una volta completati questi controlli, puoi avviare il processo di upgrade. Monitora il l'avanzamento finché non viene eseguito correttamente l'upgrade di tutti i cluster.
Pianifica l'upgrade
Gli aggiornamenti possono essere invasivi. Prima di iniziare l'upgrade, pianifica con attenzione assicurati 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 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 per l'upgrade, utilizza 10 minutes * the number of
nodes
per l'upgrade simultaneo di un singolo nodo.
Ad esempio, se hai 50 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, verifica Supporto per la versione e l'upgrade di GKE Enterprise e verificare le versioni supportate con Google Distributed Cloud prima e dopo il 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
garantire che i pod possano essere evacuati quando il nodo viene svuotato e che risorse nel cluster da aggiornare per gestire l'upgrade, controlla l'utilizzo attuale delle risorse del cluster. Per verificare l'utilizzo delle risorse puoi usare le dashboard personalizzate di 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.
La tempistica per l'upgrade del cluster di amministrazione potrebbe essere meno critica rispetto a quella per l'upgrade di cluster utente, perché l'upgrade di un cluster di amministrazione di solito non introduce dell'inattività dell'applicazione. Tuttavia, è comunque importante controllare prima di iniziare l'upgrade di un 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 nel piano di controllo del cluster di amministrazione nodi. Verifica se il consumo di risorse di questi nodi del piano di controllo è disponibile di risorse di computing. Il processo di upgrade in genere 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" è 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 necessarie durante un upgrade, prova a di mantenere la stessa versione dei cluster utente.
Nel deployment di esempio seguente, i due cluster utente si trovano a posizioni 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
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
per un totale di 1000 mCPU e 3 GiB di RAM. Il consumo totale attuale di risorse
sono 3000 mCPU e 9 GiB di RAM.
Se viene eseguito l'upgrade del cluster utente 2 a 1.13.3
, ora esistono due insiemi di ciclo di vita
controller: 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 con lo stesso
Versione: 1.13.3
:
Cluster di amministrazione | Cluster utente 1 | Cluster utente 2 |
---|---|---|
1.13.3 | 1.13.3 | 1.13.3 |
Ora c'è un solo set di controller del ciclo di vita, che consuma in totale 1000 mCPU e 3 GiB di RAM.
Nell'esempio seguente, tutti i cluster utente corrispondono alla 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 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 6 GiB di RAM fino all'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
eseguire 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
dei cluster utente alla stessa versione per consolidare le versioni
ridurre il numero di controller del ciclo di vita in uso. Se l'upgrade è già stato eseguito
bloccato, puoi utilizzare anche kubectl edit deployment
per modificare
per ridurre le richieste di CPU e RAM in modo che rientrino nel cluster di amministrazione
dal piano di controllo.
La tabella seguente descrive in dettaglio i requisiti delle risorse di computing per i 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 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, è consigliabile archiviare il file di backup. 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
nel cluster. Il comando esegue controlli avanzati, ad esempio per identificare i nodi che
non sono configurati correttamente o hanno pod in stato bloccato.
Quando esegui il comando bmctl upgrade cluster
per eseguire l'upgrade dei cluster,
vengono eseguiti controlli preflight. Se questi controlli non vengono eseguiti, il processo di upgrade si interrompe
riuscito. È meglio identificare e risolvere in modo proattivo questi problemi
bmctl check cluster
, anziché fare affidamento sui controlli preflight
servono a 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 degli utenti: drenaggio e API. compatibilità.
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 un singola replica o tutte le repliche si trovano sullo stesso nodo, lo svuotamento dei carichi di lavoro causare interruzioni nei servizi in esecuzione nel cluster. Esegui i tuoi carichi di lavoro con con più repliche. Il numero di replica deve essere superiore al nodo simultaneo numero.
Per evitare un blocco dell'upgrade, il processo di svuotamento dell'upgrade
1.29 non rispetta i budget di interruzione dei pod (PDB). Carichi di lavoro
potrebbe essere eseguito in uno stato ridotto e la replica con meno operazioni sarà 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 carico di lavoro a una versione compatibile. Ove possibile, il team tecnico di GKE Enterprise fornisce istruzioni per identificare i carichi di lavoro che utilizzano API incompatibili, come le API Kubernetes sono state rimosse.
Se utilizzi Cloud Service Mesh, Config Sync Policy Controller, Config Controller o altri servizi GKE Enterprise componenti, verifica se la versione installata è compatibile con la nuova versione Google Distributed Cloud. Per la compatibilità della versione dei componenti GKE Enterprise le informazioni, vedi Supporto per la versione e l'upgrade di GKE Enterprise.
Controlla l'utilizzo dei webhook
Controlla se nel cluster sono presenti webhook, in particolare le risorse dei pod per il 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 disattivarli temporaneamente o usare un deployment ad alta disponibilità.
Esaminare l'utilizzo delle funzionalità in anteprima
Le funzionalità di anteprima sono soggetti a modifiche e sono forniti solo a scopo di test e valutazione. Non utilizzare le funzionalità in anteprima sui cluster di produzione. Non garantiamo che puoi eseguire l'upgrade dei cluster che usano le funzionalità di anteprima. In alcuni casi, abbiamo esplicitamente bloccare gli upgrade per i cluster che usano le funzionalità in anteprima.
Per informazioni sull'interruzione delle modifiche relative all'upgrade, consulta 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 da
Google Distributed Cloud versione 1.9.0 o successiva, puoi abilitare o disabilitare SELinux
prima o dopo la creazione o gli upgrade del cluster. SELinux è abilitato da
come predefinita su Red Hat Enterprise Linux (RHEL). Se SELinux è disabilitato su
dalle tue 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 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
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 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 Google Distributed Cloud
- Scopri di più sulle ciclo di vita e fasi degli upgrade
- Risolvere i problemi di upgrade del cluster