Best practice per gli upgrade dei cluster GKE su VMware

Questo documento descrive le best practice e le considerazioni per eseguire l'upgrade di GKE su VMware. Imparerai a prepararti per gli upgrade dei cluster e a conoscere 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, come 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 l'esito positivo dell'upgrade, 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 a quello successivo e di verificare che l'upgrade e i tuoi carichi di lavoro vengano eseguiti correttamente.

Elenco di controllo per l'upgrade

Per rendere il processo di upgrade il più agevole possibile, rivedi e completa i seguenti controlli prima di iniziare a eseguire l'upgrade dei cluster:

Pianifica l'upgrade

Gli aggiornamenti possono essere fastidiosi. Prima di avviare l'upgrade, pianifica con attenzione che l'ambiente e le applicazioni siano pronti e preparati.

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

Per impostazione predefinita, viene eseguito l'upgrade di tutti i pool di nodi in parallelo, ma all'interno di ogni pool di nodi viene eseguito l'upgrade dei nodi in sequenza. Quindi il tempo totale per un upgrade dipende dal numero di nodi nel pool di nodi più grande. Per calcolare una stima approssimativa del tempo di upgrade, utilizza 15 minuti * il numero di nodi nel pool di nodi più grande. Ad esempio, se il pool più grande è di 10 nodi, il tempo totale dell'upgrade sarà di circa 150 minuti.

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 di cluster utente è uno snapshot dell'archivio etcd del cluster utente. L'archivio 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 i componenti e i carichi di lavoro del cluster. Per maggiori informazioni, consulta l'articolo su come eseguire il backup di un cluster utente.

Con GKE su VMware versione 1.8 e successive, puoi configurare il backup automatico con clusterBackup.datastore nel file di configurazione del cluster di amministrazione. Per abilitare questa funzionalità in un cluster esistente, modifica il file di configurazione del cluster di amministrazione e aggiungi il campo clusterBackup.datastore, quindi esegui gkectl update admin.

Dopo l'abilitazione di clusterBackup.datastore, viene eseguito automaticamente il backup del tuo cluster di amministrazione in etcd sul datastore vSphere configurato. Questo processo di backup si ripete ogni volta che viene apportata una modifica al cluster di amministrazione. Quando avvii un upgrade del cluster, viene eseguita un'attività di backup prima di eseguire l'upgrade del cluster.

Per ripristinare un cluster di amministrazione dal relativo backup in caso di problemi, vedi Effettuare il backup e il ripristino di un cluster di amministrazione con gkectl.

Esamina l'utilizzo di PodDisruptionBudgets

In Kubernetes, le PodDisruptionBudgets (PDB) possono aiutare a evitare tempi di inattività o interruzioni indesiderate delle applicazioni. I PDB indicano allo scheduler di mantenere sempre un numero di pod in esecuzione, mentre altri pod potrebbero presentare errori. Questo comportamento è un modo utile per garantire la disponibilità delle applicazioni.

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

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Sostituisci KUBECONFIG con il nome del tuo file kubeconfig.

    Il seguente output di esempio mostra 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 deve essere sempre disponibile almeno un pod. Questa disponibilità diventa fondamentale durante gli upgrade quando vengono scaricati i nodi.

Controlla se sono presenti PDB che non possono essere soddisfatti. Ad esempio, puoi impostare una disponibilità minima pari a 1, quando il deployment ne presenta solo una. In questo esempio, l'operazione di svuotamento viene interrotta perché il controller delle risorse non può soddisfare il PDB.

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

GKE su VMware 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 senza problemi. Per scoprire di più sui PDB, consulta Specifica di un budget di interruzione per l'applicazione.

Verifica gli indirizzi IP disponibili

Durante gli upgrade del cluster si applicano le seguenti considerazioni sugli indirizzi IP:

  • Il processo di upgrade del cluster crea un nuovo nodo e svuota le risorse prima di eliminare il nodo precedente. Ti consigliamo di avere sempre N+1 indirizzi IP per il cluster di amministrazione o utente, dove N è il numero di nodi nel cluster.
  • Se utilizzi indirizzi IP statici, gli indirizzi IP richiesti devono essere elencati nei file di blocchi IP.
  • Se utilizzi il protocollo DHCP, assicurati che le nuove VM possano ottenere altri lease IP nella subnet desiderata durante un upgrade.
    • Se devi aggiungere indirizzi IP, aggiorna il file dei blocchi IP, quindi esegui il comando gkectl update. Per maggiori informazioni, consulta Pianificare gli indirizzi IP.
  • Se utilizzi indirizzi IP statici e vuoi velocizzare il processo di upgrade del cluster utente, elenca un numero sufficiente di indirizzi IP nel file dei blocchi IP in modo che ogni pool di nodi possa avere un indirizzo IP aggiuntivo disponibile. Questo approccio consente al processo di accelerare la procedura di aggiunta e rimozione delle VM mentre viene eseguita in base al pool di nodi.
    • Sebbene questo approccio sia una buona opzione per velocizzare gli upgrade dei cluster utente, prima di procedere considera la disponibilità di risorse e prestazioni del tuo ambiente vSphere.
  • Se è presente un solo IP di riserva per l'intero cluster utente, questo limite rallenta il processo di upgrade a una sola VM alla volta, anche quando vengono utilizzati più pool di nodi.

Controlla l'utilizzo del cluster

Assicurati che i pod possano essere evacuati quando il nodo si svuota e che ci siano risorse sufficienti nel cluster per cui eseguire l'upgrade per gestire l'upgrade. Per verificare l'utilizzo attuale delle risorse del cluster, puoi utilizzare 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 dell'utilizzo attuale delle risorse del cluster. Le dashboard possono fornire una visione più dettagliata delle risorse utilizzate nel tempo. Questi dati sull'utilizzo delle risorse possono essere utili per 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.

Le tempistiche per l'upgrade del cluster di amministrazione potrebbero essere meno critiche rispetto ai cluster utente, perché l'upgrade di un cluster di amministrazione di solito non introduce tempi di inattività delle applicazioni. Tuttavia, è comunque importante verificare la presenza di risorse gratuite in vSphere prima di iniziare un upgrade del cluster di amministrazione. Inoltre, l'upgrade del cluster di amministrazione potrebbe comportare rischi e pertanto potrebbe essere consigliato durante periodi di utilizzo meno attivi, quando l'accesso per la gestione al cluster è meno critico.

Per maggiori informazioni, consulta Quali servizi sono interessati durante un upgrade del 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 la scheda Riepilogo.

La scheda Riepilogo mostra il consumo complessivo di memoria, CPU e spazio di archiviazione dell'intero cluster. Poiché gli upgrade di GKE su VMware richiedono risorse aggiuntive, devi anche verificare se il cluster è in grado di gestire queste richieste di risorse aggiuntive.

Come regola generale, il cluster vSphere deve essere in grado di supportare le seguenti 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 pool di nodi contiene nodi che utilizzano 8 vCPU e almeno 32 GB di RAM. Poiché l'upgrade avviene in parallelo per i tre pool di nodi per impostazione predefinita, la procedura di upgrade 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 vExchange

Il processo di upgrade crea delle VM utilizzando l'operazione di clone vSphere. La clonazione di più VM da un modello può causare stress al sistema di archiviazione sotto forma di operazioni I/O in aumento. L'upgrade può subire gravi rallentamenti se il sottosistema di archiviazione sottostante non è in grado di fornire prestazioni sufficienti durante un upgrade.

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

Se le risorse disponibili sono già scarse, spegni le VM non necessarie per soddisfare questi requisiti aggiuntivi e prevenire potenziali danni alle prestazioni.

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 assicura che tutti i cluster siano integri. Il comando esegue controlli avanzati, ad esempio per identificare i nodi non configurati correttamente o che contengono pod in stato bloccato.

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

Sebbene il comando gkectl upgrade esegua i controlli preflight e arresti il processo di upgrade se questi non hanno esito positivo, i controlli preflight hanno lo scopo di proteggere i cluster da eventuali danni. Ti consigliamo di utilizzare gli strumenti per identificare e risolvere i problemi prima dell'upgrade, anziché fare affidamento sui controlli preflight.

Se il comando gkectl diagnose mostra un avviso Cluster unhealthy, risolvi i problemi prima di tentare un upgrade.

Per ulteriori informazioni, consulta Diagnostica dei problemi del cluster.

Usa i deployment per ridurre al minimo l'interruzione delle applicazioni

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

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

Esistono anche regole per i deployment, che assicurano che un determinato numero di repliche continui a essere in esecuzione. Queste regole sono note come PodDisruptionBudgets (PDB). I PDB consentono di limitare l'interruzione a un carico di lavoro quando per qualche motivo i relativi pod devono essere ripianificati, ad esempio upgrade o manutenzione sui nodi cluster, ed è importante controllare prima di un upgrade.

Usa 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 quando esegui l'upgrade del cluster. Questo upgrade può causare un'interruzione del servizio. Per ridurre l'impatto di un upgrade e di un eventuale errore del bilanciatore del carico, puoi utilizzare una coppia di alta disponibilità (coppia ad alta disponibilità). In questa configurazione, il sistema crea e configura due VM del bilanciatore del carico, in modo che possa verificarsi un failover all'altro peer.

Per aumentare la disponibilità del servizio (ovvero per il server API Kubernetes), consigliamo di utilizzare sempre una coppia ad alta disponibilità davanti al cluster di amministrazione. Per scoprire di più su Seesaw e sulla sua configurazione ad alta disponibilità, consulta 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 cluster utente utilizza solo una singola 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 anche il cluster utente stesso è configurato per l'alta disponibilità. Questa serie di best practice presuppone che un cluster utente ad alta disponibilità utilizzi una coppia di bilanciatori del carico ad alta disponibilità.

Se GKE su VMware versione 1.11 o 1.12 utilizza MetalLB come bilanciatore del carico in bundle, non è richiesta alcuna configurazione prima dell'upgrade. L'upgrade del bilanciatore del carico viene eseguito durante il processo di upgrade del cluster.

Decidi come eseguire l'upgrade di ogni cluster utente

Dalla versione 1.14 in poi, puoi scegliere di eseguire l'upgrade di un cluster utente nel suo complesso (puoi eseguire l'upgrade del piano di controllo e di tutti i pool di nodi nel cluster) oppure puoi eseguire l'upgrade del piano di controllo del cluster utente e lasciare i pool di nodi alla versione attuale. Per informazioni sul motivo per cui potresti voler eseguire l'upgrade del piano di controllo separatamente, consulta Upgrade dei cluster utente.

In un ambiente multi-cluster, tieni traccia dei cluster utente di cui è stato eseguito l'upgrade e registra il numero di versione. Se decidi di eseguire l'upgrade del piano di controllo e dei pool di nodi separatamente, registra la versione del piano di controllo e ogni pool di nodi in ogni cluster.

Controlla le versioni dei cluster utente e di amministrazione

Gkectl

  • Per controllare la versione dei cluster utente:

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file 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 registrati nell'API GKE On-Prem, puoi utilizzare gcloud CLI per ottenere le versioni dei cluster utente, i pool di nodi sul cluster utente e i cluster di amministrazione.

  1. Assicurati di avere la versione più recente di gcloud CLI. Aggiorna i componenti di gcloud CLI, se necessario:

    gcloud components update

  2. Esegui questi comandi per controllare le versioni:

  • Per controllare 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.

    Quando imposti --location=-, significa che vengono elencati tutti i cluster in tutte le regioni. Se devi ridurre l'elenco, imposta --location sulla regione specificata 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 cluster:

Puoi utilizzare kubectl per ottenere la versione dei nodi cluster, ma kubectl restituisce la versione di Kubernetes. Per ottenere la versione di GKE su VMware corrispondente a una versione di Kubernetes, consulta Cronologia delle versioni.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

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

Controllare se è necessario ruotare i certificati CA

Durante un upgrade, i certificati foglia vengono ruotati, ma i certificati CA no. Devi ruotare manualmente i certificati CA almeno una volta ogni cinque anni. Per maggiori informazioni, vedi Ruotare le autorità di certificazione del cluster utente e Ruotare 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 viene creato, il cluster utente potrebbe contenere nodi worker e del piano di controllo (piano di controllo 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, dalla versione 1.14 in poi, puoi eseguire l'upgrade del piano di controllo di un cluster utente separatamente dai pool di nodi che eseguono i tuoi carichi di lavoro.

Diversi effetti dei cluster utente rispetto agli upgrade del cluster di amministrazione

La procedura di upgrade di GKE su VMware prevede un processo di svuotamento dei nodi che rimuove tutti i pod da un nodo. Il processo crea una nuova VM per ogni nodo worker svuotato e la aggiunge al cluster. I nodi worker svuotati vengono poi rimossi dall'inventario di VMware. Durante questo processo, qualsiasi carico di lavoro in esecuzione su questi nodi viene arrestato e riavviato su altri nodi disponibili nel cluster.

A seconda dell'architettura scelta del carico di lavoro, questa procedura potrebbe avere un impatto sulla disponibilità di un'applicazione. Per evitare un carico eccessivo sulle capacità delle risorse del cluster, GKE su VMware esegue l'upgrade di un nodo alla volta.

Interruzione del cluster utente

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

Funzione Cluster di amministrazione Cluster utente non ad alta disponibilità Cluster utente ad alta disponibilità
Accesso all'API Kubernetes Non interessato Non interessato Non interessato
Carichi di lavoro utente Non interessato Non interessato Non interessato
Budget di PodDisruption* 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 l'arresto o l'interruzione dell'upgrade.
  • Interessato: è evidente un'interruzione del servizio durante l'upgrade fino al suo completamento.
  • Non interessato: un'interruzione del servizio potrebbe verificarsi in un breve periodo di tempo, ma è quasi impercettibile.

I nodi del piano di controllo del cluster utente, indipendentemente dal fatto che vengano eseguiti sul cluster di amministrazione (kubeception) o sul cluster utente stesso (Controlplane V2), non eseguono carichi di lavoro utente. Durante un upgrade, questi nodi del piano di controllo vengono svuotati e poi aggiornati di conseguenza.

In ambienti con piani di controllo ad alta disponibilità, l'upgrade del piano di controllo di un cluster utente non interrompe 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 che utilizzano Controlplane V2, l'upgrade solo del piano di controllo non interrompe i carichi di lavoro degli utenti.

Durante un upgrade in un ambiente del piano di controllo non ad alta disponibilità, il piano non può controllare le azioni di scalabilità, ripristino o deployment dei pod. Durante la breve interruzione del piano di controllo durante l'upgrade, i carichi di lavoro degli utenti possono essere interessati se sono in stato di scalabilità, deployment o ripristino. Ciò significa che le implementazioni non andranno a buon fine durante un upgrade in un ambiente non ad alta disponibilità.

Per migliorare la disponibilità e ridurre le interruzioni dei cluster utente di produzione durante gli upgrade, ti consigliamo di utilizzare tre nodi del piano di controllo (modalità ad alta disponibilità).

Interruzione del cluster di amministrazione

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

Funzione Cluster di amministrazione Cluster utente non ad alta disponibilità Cluster utente ad alta disponibilità
Accesso all'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
Ripristino automatico Interessato Interessato Non interessato
Scalabilità automatica dei nodi Interessato Interessato Non interessato
Scalabilità automatica pod orizzontale Interessato Interessato Non interessato
  • Interessato: è evidente un'interruzione del servizio durante l'upgrade fino al suo completamento.
  • Non interessato: un'interruzione del servizio potrebbe verificarsi in un breve periodo di tempo, ma è quasi impercettibile.

Passaggi successivi