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

Per semplificare il più possibile la procedura di upgrade, rivedi e completa le seguenti controlli prima di iniziare l'upgrade dei 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

Per impostazione predefinita, viene eseguito l'upgrade di tutti i pool di nodi in parallelo, ma all'interno di ciascun nodo pool, l'upgrade dei nodi viene eseguito in sequenza. Quindi il tempo totale per un upgrade dipende dal numero di nodi nel pool di nodi più grande. Per calcolare un valore approssimativo per il tempo di upgrade, utilizza 15 minuti * il numero di nodi pool di nodi più grande. Ad esempio, se hai 10 nodi nel pool più grande, è di circa 150 minuti.

Nella versione 1.28 e successive, puoi accelerare un upgrade impostando il valore maxSurge per i singoli pool di nodi.

Esegui il backup del cluster utente e di amministrazione

Prima di avviare un upgrade, esegui il backup dei cluster utente e di amministrazione.

Un backup del cluster utente è uno snapshot dell'archivio etcd del cluster utente. etcd contiene tutti gli oggetti Kubernetes e gli oggetti personalizzati necessari per gestire lo stato del cluster. Lo snapshot contiene i dati necessari per ricreare carichi di lavoro e componenti del cluster. Per ulteriori informazioni, scopri come eseguire il backup di un cluster utente.

Con Google Distributed Cloud versione 1.8 e successive, puoi configurare esegui il backup con clusterBackup.datastore nel file di configurazione del cluster di amministrazione. Per attivare questa funzione in una modifica il file di configurazione del cluster di amministrazione e aggiungi clusterBackup.datastore, quindi esegui gkectl update admin.

Dopo aver abilitato clusterBackup.datastore, il cluster di amministrazione viene automaticamente sottoposti a backup in etcd nel datastore vSphere configurato. Questo processo di backup si ripete ogni volta che viene apportata una modifica al cluster di amministrazione. Quando avvii un dell'upgrade del cluster, viene eseguita un'attività di backup prima di eseguire l'upgrade del cluster.

Per ripristinare un cluster di amministrazione dal backup in caso di problemi, vedi Esegui il backup e ripristina un cluster di amministrazione con gkectl.

Rivedi l'utilizzo di PodDisruptionBudgets

In Kubernetes, i valori PodDisruptionBudgets (PDB) possono aiutare a prevenire con tempi di inattività o interruzioni delle applicazioni. I PDB indicano allo scheduler di mantenere sempre di pod in esecuzione mentre altri pod non riescono a funzionare. Questo comportamento è un un modo utile per fornire la disponibilità delle applicazioni.

  1. Per verificare quali PDB sono configurati nel cluster, utilizza kubectl get pdb :

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Sostituisci KUBECONFIG con il nome del tuo file kubeconfig.

    L'output di esempio seguente mostra i PDB denominati istio-ingress, istiod, e kube-dns:

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

Nella tabella precedente, ogni PDB specifica che almeno un pod deve essere sempre disponibili. Questa disponibilità diventa fondamentale durante gli upgrade, quando i nodi svuotato.

Controlla i PDB che non possono essere soddisfatti. Ad esempio, puoi impostare un minimo la disponibilità di 1, quando il deployment ne presenta solo 1 replica. In questo Ad esempio, l'operazione di svuotamento viene interrotta perché non è possibile soddisfare il PDB dal controller di risorse.

Per assicurarti che i PDB non interferiscano con la procedura di upgrade, controlla PDB su un determinato cluster prima di avviare l'upgrade. Potresti dover coordinarsi con i team di sviluppo e i proprietari delle applicazioni per modificare o disabilitare i PDB durante l'upgrade di un cluster.

Google Distributed Cloud esegue un controllo preflight durante il processo di upgrade per avvisare sui PDB. Tuttavia, devi anche verificare manualmente i PDB per garantire un'esperienza di upgrade. Per scoprire di più sui PDB, consulta: Specificare un budget di interruzione per l'applicazione.

Rivedi gli indirizzi IP disponibili

Durante gli upgrade del cluster si applicano le seguenti considerazioni sull'indirizzo IP:

  • Il processo di upgrade del cluster crea un nuovo nodo e svuota le risorse prima il vecchio nodo viene eliminato. Ti consigliamo di avere sempre N+1 indirizzi IP per il cluster di amministrazione o utente, dove N è il numero di nodi nel cluster.
  • Quando utilizzi indirizzi IP statici, questi devono essere elencati in nei file dei blocchi IP.
  • Se utilizzi il protocollo DHCP, assicurati che le nuove VM possano ricevere lease IP aggiuntivi nel durante un upgrade.
    • Se devi aggiungere indirizzi IP, aggiorna il file del blocco IP, quindi esegui Comando gkectl update. Per ulteriori informazioni, vedi Pianifica gli indirizzi IP.
  • Se utilizzi indirizzi IP statici e vuoi velocizzare l'upgrade del cluster utente processo, elenca un numero sufficiente di indirizzi IP nel file dei blocchi IP in modo che ogni pool di nodi può avere un indirizzo IP aggiuntivo disponibile. Questo approccio consente al processo di velocizzare la procedura di aggiunta e rimozione della VM, eseguita su un pool di nodi base.
    • Sebbene questo approccio sia una buona opzione per velocizzare gli upgrade dei cluster utente, considera la disponibilità di risorse e prestazioni di vSphere dell'ambiente di lavoro prima di procedere.
  • Se è presente un solo IP di riserva per l'intero cluster utente, questa limitazione rallenta il processo di upgrade a una sola VM alla volta, anche quando più nodi e i pool di classificazione.

Controlla l'utilizzo del cluster

Assicurati che i pod possano essere evacuati quando il nodo viene svuotato e che risorse nel cluster di cui eseguire l'upgrade sono sufficienti per gestire l'upgrade. A controllare l'utilizzo attuale delle risorse del cluster, puoi usare dashboard personalizzate in Google Cloud Observability o direttamente nel cluster utilizzando comandi come kubectl top nodes.

I comandi che esegui sul cluster mostrano uno snapshot del cluster attuale e l'utilizzo delle risorse. Le dashboard possono fornire una visione più dettagliata delle risorse consumato nel tempo. Questi dati sull'utilizzo delle risorse possono essere utili per indicare quando un upgrade meno interruzioni, ad esempio durante i fine settimana o la sera, a seconda sul carico di lavoro e sui casi d'uso in esecuzione.

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 verificare la presenza di risorse gratuite in vSphere prima di iniziare l'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.

Per ulteriori informazioni, vedi quali servizi sono interessati durante l'upgrade di un cluster.

Controlla l'utilizzo di vSphere

Verifica che ci siano risorse sufficienti nell'infrastruttura vSphere sottostante. Per verificare l'utilizzo delle risorse, seleziona un cluster in vCenter ed esamina il Scheda Riepilogo.

La scheda Riepilogo mostra il consumo complessivo di memoria, CPU e spazio di archiviazione l'intero cluster. Poiché gli upgrade di Google Distributed Cloud richiedono devi anche controllare se il cluster è in grado di gestire queste risorse richieste di risorse.

Come regola generale, il cluster vSphere deve essere in grado di supportare quanto segue risorse aggiuntive:

  • +1 VM per upgrade del cluster di amministrazione
  • +1 VM per pool di nodi per upgrade del cluster utente

Ad esempio, supponiamo che un cluster utente abbia 3 pool di nodi in cui ogni nodo ha nodi che utilizzano 8 vCPU e 32 GB o più di RAM. Poiché l'upgrade avviene in parallelo per i 3 pool di nodi, per impostazione predefinita consuma le seguenti risorse aggiuntive per i tre nodi di picco aggiuntivi:

  • 24 vCPU
  • 256 GB di RAM
  • Spazio su disco VM + 256 GB di v swap

Il processo di upgrade crea delle VM utilizzando l'operazione di clonazione vSphere. Clonazione più VM da un modello possono introdurre stress per l'archiviazione sottostante. sistema operativo sotto forma di operazioni di I/O in crescita. L'upgrade può essere notevolmente rallentato se il sottosistema di archiviazione sottostante non è in grado di fornire delle prestazioni durante un upgrade.

Sebbene vSphere sia progettato per l'utilizzo simultaneo delle risorse e abbia meccanismi per forniscono risorse, anche in caso di overcommit, consigliamo vivamente di non l'overcommit della memoria della VM. L'overcommit della memoria può provocare sulle prestazioni, che interessano l'intero cluster, poiché vSphere fornisce "RAM mancante" dallo scambio delle pagine al datastore. Questo comportamento può portare a problemi durante l'upgrade di un cluster, con un conseguente impatto sulle prestazioni di altre VM in esecuzione sul cluster vSphere.

Se le risorse disponibili sono già scarse, spegni le VM non necessarie per a soddisfare questi requisiti aggiuntivi e impedire un potenziale miglioramento del rendimento.

Controlla l'integrità e la configurazione del cluster

Esegui i seguenti strumenti su tutti i cluster prima dell'upgrade:

  • Il comando gkectl diagnose: gkectl diagnose garantisce che tutti i cluster siano integro. Il comando esegue controlli avanzati, ad esempio per identificare i nodi che non sono configurati correttamente o hanno pod in stato bloccato. Se il comando gkectl diagnose mostra un avviso Cluster unhealthy, correggi il prima di tentare l'upgrade. Per ulteriori informazioni, vedi Diagnosticare i problemi del cluster.

  • Lo strumento prima dell'upgrade: inoltre per controllare l'integrità e la configurazione del cluster. lo strumento pre-upgrade verifica per individuare potenziali problemi noti che potrebbero verificarsi durante l'upgrade di un cluster.

Inoltre, quando esegui l'upgrade dei cluster utente alla versione 1.29 e successive, ti consigliamo di eseguire il comando gkectl upgrade cluster Flag --dry-run. Il flag --dry-run viene eseguito controlli preflight ma non avvia il processo di upgrade. Sebbene le versioni precedenti Google Distributed Cloud esegue controlli preflight, non possono essere eseguiti separatamente l'upgrade. Se aggiungi il flag --dry-run, puoi trovare e risolvere eventuali problemi che i controlli preflight rilevano con il cluster utente prima dell'upgrade.

Usa i deployment per ridurre al minimo le interruzioni delle applicazioni

Poiché i nodi devono essere svuotati durante gli aggiornamenti, gli upgrade dei cluster possono le interruzioni delle applicazioni. Lo svuotamento dei nodi significa che tutti i pod in esecuzione potrebbe essere arrestato e riavviato sui nodi rimanenti nel cluster.

Se possibile, le applicazioni dovrebbero usare i deployment. Con questo approccio, sono progettate per gestire le interruzioni. L'impatto dovrebbe essere minimo ai deployment con più repliche. Puoi comunque eseguire l'upgrade del cluster se le applicazioni non usano i deployment.

Esistono anche delle regole per i deployment per assicurare che un numero prestabilito rimangono sempre in esecuzione. Queste regole sono note come PodDisruptionBudgets (PDB). I PDB consentono di limitare l'interruzione di un carico di lavoro quando i suoi pod devono essere riprogrammati per qualche motivo, ad esempio per eventuali upgrade o manutenzione nodi del cluster ed è importante controllarli prima di un upgrade.

Utilizza una coppia di bilanciatori del carico ad alta disponibilità

Se utilizzi Seesaw come bilanciatore del carico su un cluster, l'upgrade dei bilanciatori del carico viene eseguito automaticamente in un cluster Kubernetes. Questo upgrade può causare un'interruzione del servizio. Per ridurre l'impatto di un e un eventuale errore del bilanciatore del carico, puoi utilizzare un modello (coppia ad alta disponibilità). In questa configurazione, il sistema crea e configura due delle VM dei bilanciatori del carico in modo che possa verificarsi un failover all'altro peer.

Per aumentare la disponibilità del servizio (ovvero il server API Kubernetes), consigliamo di utilizzare sempre una coppia ad alta disponibilità davanti al cluster di amministrazione. Per ulteriori informazioni su Seesaw e sulla sua configurazione ad alta disponibilità, vedi Bilanciamento del carico in bundle con Seesaw.

Per evitare un'interruzione del servizio durante un upgrade con una coppia ad alta disponibilità, il cluster avvia un failover prima di creare la nuova VM del bilanciatore del carico. Se un utente utilizza una sola istanza del bilanciatore del carico, si verifica un'interruzione del servizio fino al completamento dell'upgrade del bilanciatore del carico.

Ti consigliamo di utilizzare una coppia di bilanciatori del carico ad alta disponibilità se il cluster utente stesso è configurata anche per l'alta disponibilità. Questa serie di best practice presuppone che un cluster utente ad alta disponibilità usa una coppia di bilanciatori del carico ad alta disponibilità.

Se utilizzi MetalLB come di un bilanciatore del carico in bundle, non è richiesta nessuna configurazione prima dell'upgrade. Il bilanciatore del carico durante il processo di upgrade del cluster.

Decidi come eseguire l'upgrade di ogni cluster utente

Nella versione 1.14 e successive, puoi scegliere di eseguire l'upgrade di un cluster utente nel suo complesso (ossia puoi eseguire l'upgrade del piano di controllo e di tutti i pool di nodi nel cluster), oppure eseguire l'upgrade del piano di controllo del cluster utente e lasciare i pool di nodi in la versione corrente. Per informazioni sul motivo per cui potresti voler eseguire l'upgrade separatamente dal piano di controllo, vedi Upgrade dei cluster utente.

In un ambiente multi-cluster, tieni traccia dei cluster utente che sono stati upgrade eseguito e di registrare il numero di versione. Se decidi di eseguire l'upgrade dal piano di controllo e dai pool di nodi separatamente, registra la versione del piano di controllo e ogni pool di nodi in ogni cluster.

Controlla le versioni del cluster di amministrazione e utente

Gkectl

  • Per verificare la versione dei cluster utente:

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del kubeconfig per il cluster di amministrazione.

  • Per controllare la versione dei cluster di amministrazione:

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Interfaccia a riga di comando gcloud

Per i cluster che sono registrate nell'API GKE On-Prem, puoi usa gcloud CLI per ottenere le versioni dei cluster utente e dei pool di nodi sul cluster utente e sui cluster di amministrazione.

  1. Assicurati di avere l'ultima versione di gcloud CLI. Aggiorna i componenti della gcloud CLI, se necessario:

    gcloud components update

  2. Esegui questi comandi per verificare le versioni:

  • Per verificare la versione dei cluster utente:

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    Sostituisci PROJECT_ID, l'ID progetto del tuo progetto host del parco risorse.

    L'impostazione di --location=- consente di elencare tutti i cluster in regioni. Se devi ridurre l'ambito dell'elenco, imposta --location sulla regione che hai specificato al momento della registrazione del cluster.

    L'output del comando include la versione del cluster.

  • Per controllare la versione dei cluster di amministrazione:

    gcloud container vmware admin-clusters list \
    --project=PROJECT_ID \
    --location=-

Controlla la versione dei nodi del cluster:

Puoi usare kubectl per ottenere la versione dei nodi del cluster, ma kubectl restituisce la versione di Kubernetes. per ottenere il set di dati Google Distributed Cloud corrispondente per una versione Kubernetes, consulta Controllo delle versioni.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del kubeconfig per il cluster utente.

Controlla se i certificati CA devono essere ruotati

Durante un upgrade, i certificati foglia vengono ruotati, ma non i certificati CA. È necessario ruotare manualmente i certificati CA almeno una volta ogni cinque anni. Per ulteriori informazioni, vedi Ruota le autorità di certificazione del cluster utente e Ruota i certificati CA del cluster di amministrazione.

Differenze tra i tipi di cluster

Esistono due diversi tipi di cluster:

  • Cluster utente
  • Cluster di amministrazione

A seconda di come crei un cluster utente, questo potrebbe contenere sia nodi worker e nodi del piano di controllo (Controlplane V2) o solo nodi worker (kubeception). Con kubeception, il piano di controllo per un cluster utente viene eseguito su uno o più nodi in un cluster di amministrazione. In entrambi i casi, nella versione 1.14 e successive, puoi eseguire l'upgrade di un del tuo cluster utente separatamente dai pool di nodi che eseguono carichi di lavoro con scale out impegnativi.

Effetti diversi degli upgrade dei cluster utente e dei cluster di amministrazione

La procedura di upgrade di Google Distributed Cloud implica un processo di svuotamento dei nodi che rimuove tutti i pod da un nodo. Il processo crea una nuova VM per ogni svuotamento e lo aggiunge al cluster. I nodi worker svuotati vengono quindi rimosso dall'inventario di VMware. Durante questo processo, qualsiasi carico di lavoro in esecuzione questi nodi vengono arrestati e riavviati su altri nodi disponibili nel cluster.

A seconda dell'architettura scelta per il carico di lavoro, questa procedura potrebbe un impatto sulla disponibilità di un'applicazione. Per evitare un carico eccessivo sulla capacità delle risorse di un cluster, Google Distributed Cloud esegue l'upgrade di un nodo nel tempo.

Interruzione del cluster utente

La tabella seguente descrive l'impatto di un cluster utente in loco upgrade:

Funzione Cluster di amministrazione Cluster utente non ad alta disponibilità Cluster utente ad alta disponibilità
Accesso API Kubernetes Non interessato Non interessato Non interessato
Carichi di lavoro utente Non interessato Non interessato Non interessato
PodDisruptionBudgets* Non interessato Non interessato Non interessato
Nodo del piano di controllo Non interessato Interessato Non interessato
Gestore della scalabilità automatica dei pod (VMware) Non interessato Non interessato Non interessato
Riparazione automatica Non interessato Non interessato Non interessato
Scalabilità automatica dei nodi (VMware) Non interessato Non interessato Non interessato
Scalabilità automatica pod orizzontale Interessato Interessato Non interessato
  • * : i PDB potrebbero causare un errore o l'interruzione dell'upgrade.
  • Interessato: un'interruzione del servizio durante l'upgrade è visibile fino al giorno L'upgrade è terminato.
  • Non interessato: un'interruzione del servizio potrebbe verificarsi per un periodo di tempo molto breve tempo, ma è quasi impercettibile.

I nodi del piano di controllo del cluster utente, se vengono eseguiti sul cluster di amministrazione (kubeception) o il cluster utente stesso (Controlplane V2), non eseguono carichi di lavoro con scale out impegnativi. Durante un upgrade, questi nodi del piano di controllo vengono svuotati e quindi aggiornati di conseguenza.

In ambienti con piani di controllo ad alta disponibilità, eseguire l'upgrade di un utente del piano di controllo del cluster non interrompono i carichi di lavoro degli utenti. In un ambiente ad alta disponibilità, l'upgrade di un cluster di amministrazione non interrompe i carichi di lavoro degli utenti. Per i cluster utente usando il piano di controllo V2, l'upgrade solo del piano di controllo non interrompe carichi di lavoro utente.

Durante un upgrade in un ambiente del piano di controllo non ad alta disponibilità, il piano di controllo non può controllare le azioni di scalabilità, recupero o deployment dei pod. Durante lo Short un'interruzione del piano di controllo durante l'upgrade, i carichi di lavoro o se si trovano in stato di scalabilità, deployment o ripristino. Ciò significa le implementazioni non riusciranno durante un upgrade in un ambiente non ad alta disponibilità.

per migliorare la disponibilità e ridurre le interruzioni dei cluster utente in produzione durante ti consigliamo di usare tre nodi del piano di controllo (alta disponibilità ).

Interruzione del cluster di amministrazione

La tabella seguente descrive l'impatto di un cluster di amministrazione in loco upgrade:

Funzione Cluster di amministrazione Cluster utente non ad alta disponibilità Cluster utente ad alta disponibilità
Accesso API Kubernetes Interessato Interessato Non interessato
Carichi di lavoro utente Non interessato Non interessato Non interessato
Nodo del piano di controllo Interessato Interessato Non interessato
Gestore della scalabilità automatica dei pod Interessato Interessato Non interessato
Autofficina Interessato Interessato Non interessato
Scalabilità automatica dei nodi Interessato Interessato Non interessato
Scalabilità automatica pod orizzontale Interessato Interessato Non interessato
  • Interessato: un'interruzione del servizio durante l'upgrade è visibile fino al giorno L'upgrade è terminato.
  • Non interessato: un'interruzione del servizio potrebbe verificarsi per un periodo di tempo molto breve tempo, ma è quasi impercettibile.

Passaggi successivi