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. 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