Best practice per gli upgrade dei cluster Google Distributed Cloud

Questo documento descrive le best practice e le considerazioni per eseguire l'upgrade di Google Distributed Cloud. Imparerai come prepararti per gli upgrade dei cluster e quali best practice 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, ad esempio test, e 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

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

Pianifica l'upgrade

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

Stima l'impegno in termini di tempo e pianifica un periodo di manutenzione

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

Dalla versione 1.28 in poi, puoi accelerare l'upgrade impostando il valore di 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. 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 ulteriori informazioni, scopri come eseguire il backup di un cluster utente.

Con Google Distributed Cloud 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 cluster di amministrazione 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 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 Eseguire il backup e ripristinare un cluster di amministrazione con gkectl.

Rivedi l'utilizzo di PodDisruptionBudgets

In Kubernetes, la funzionalità PodDisruptionBudgets (PDB) consente di evitare interruzioni o tempi di inattività indesiderati delle applicazioni. I PDB indicano allo scheduler di mantenere sempre in esecuzione un certo numero di pod, mentre altri pod potrebbero non funzionare. 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.

    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 deve essere sempre disponibile almeno un pod. Questa disponibilità diventa fondamentale durante gli upgrade, quando i nodi sono scaricati.

Controlla i PDB che non possono essere soddisfatti. Ad esempio, potresti impostare una disponibilità minima pari a 1, quando il deployment presenta solo 1 replica. 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 di 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.

Google Distributed Cloud esegue un controllo preflight durante il processo di upgrade per avvisare i PDB. Tuttavia, per garantire un'esperienza di upgrade senza problemi, devi anche verificare manualmente i PDB. Per scoprire di più sui PDB, consulta la sezione 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 di eliminare il nodo precedente. Ti consigliamo di avere sempre N+1 indirizzi IP per il cluster di amministrazione o per il cluster utente, dove N è il numero di nodi nel cluster.
  • Quando utilizzi indirizzi IP statici, questi devono essere elencati nei file dei blocchi IP.
  • Se utilizzi il protocollo DHCP, durante un upgrade assicurati che le nuove VM possano ricevere lease IP aggiuntivi nella subnet desiderata.
    • Se devi aggiungere indirizzi IP, aggiorna il file dei blocchi IP ed esegui il comando gkectl update. Per ulteriori informazioni, vedi 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 della VM, eseguita su un pool di nodi per singolo pool.
    • Sebbene questo approccio sia una buona opzione per accelerare gli upgrade dei cluster utente, valuta la disponibilità di risorse e prestazioni del tuo ambiente vSphere 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 se vengono utilizzati più pool di nodi.

Controlla l'utilizzo del cluster

Assicurati che i pod possano essere evacuati quando il nodo viene svuotato e che nel cluster di cui viene eseguito l'upgrade siano presenti risorse sufficienti 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 tramite comandi come kubectl top nodes.

I comandi che esegui sul cluster mostrano uno snapshot dell'utilizzo attuale delle risorse cluster. Le dashboard possono fornire una visualizzazione più dettagliata delle risorse utilizzate nel tempo. Questi dati sull'utilizzo delle risorse possono aiutare a indicare quando un upgrade causerebbe la minor interruzione del servizio, 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 dei cluster utente, perché un upgrade del 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 dei rischi e pertanto potrebbe essere consigliato durante i periodi di utilizzo meno attivi, quando l'accesso da parte della gestione al cluster è meno critico.

Per ulteriori informazioni, consulta 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 di questo utilizzo delle risorse, seleziona un cluster in vCenter ed esamina la scheda Riepilogo.

La scheda di riepilogo mostra il consumo complessivo di memoria, CPU e spazio di archiviazione dell'intero cluster. Poiché gli upgrade di Google Distributed Cloud 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 ha nodi che utilizzano 8 vCPU e 32 GB o più di RAM. Poiché l'upgrade avviene in parallelo per i tre pool di nodi per impostazione predefinita, la procedura di upgrade utilizza 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. La clonazione di più VM da un modello può introdurre stress nel sistema di archiviazione sottostante sotto forma di operazioni di I/O crescenti. L'upgrade può essere gravemente rallentato se il sottosistema di archiviazione sottostante non è in grado di fornire prestazioni sufficienti durante un upgrade.

Sebbene vSphere sia progettato per l'utilizzo simultaneo delle 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" per lo scambio di pagine nel datastore. Questo comportamento può causare problemi durante l'upgrade di un cluster e influire sulle prestazioni delle altre VM in esecuzione sul cluster vSphere.

Se le risorse disponibili sono già scarse, spegni le VM non necessarie per soddisfare questi requisiti aggiuntivi ed evitare un potenziale peggioramento delle 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 garantisce che tutti i cluster siano in stato integro. Il comando esegue controlli avanzati, ad esempio per identificare i nodi che non sono configurati correttamente o i cui pod sono bloccati. Se il comando gkectl diagnose mostra un avviso Cluster unhealthy, correggi i problemi prima di tentare un upgrade. Per ulteriori informazioni, consulta Diagnostica dei problemi relativi ai cluster.

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

Inoltre, quando esegui l'upgrade dei cluster utente alla versione 1.29 e successive, ti consigliamo di eseguire il comando gkectl upgrade cluster con il flag --dry-run. Il flag --dry-run esegue i controlli preflight, ma non avvia il processo di upgrade. Anche se le versioni precedenti di Google Distributed Cloud eseguono controlli preflight, non possono essere eseguite separatamente dall'upgrade. Aggiungendo il flag --dry-run, puoi trovare e risolvere eventuali problemi rilevati dai controlli preflight nel tuo 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 causare interruzioni delle applicazioni. Lo svuotamento dei nodi comporta l'arresto e il riavvio di tutti i pod in esecuzione sui nodi rimanenti nel cluster.

Se possibile, le applicazioni dovrebbero usare i deployment. Con questo approccio, le applicazioni sono progettate per gestire le interruzioni. L'impatto dovrebbe essere minimo sui 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 di repliche continui a essere 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 ripianificati per qualche motivo, ad esempio upgrade o manutenzione sui nodi del cluster, e sono importanti verificare prima di un upgrade.

Utilizza una coppia di bilanciatori del carico ad alta disponibilità

Se utilizzi Seesaw come bilanciatore del carico in 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 ad 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), ti consigliamo di utilizzare sempre una coppia ad alta disponibilità davanti al cluster di amministrazione. Per saperne 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 è configurato per essere ad alta disponibilità. Questa serie di best practice presuppone che un cluster utente ad alta disponibilità utilizzi una coppia

Se utilizzi MetalLB come bilanciatore del carico in bundle, non è richiesta alcuna configurazione pre-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, ovvero 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 di quali cluster utente è stato eseguito l'upgrade e registra il relativo numero di versione. Se decidi di eseguire l'upgrade separatamente del piano di controllo e dei pool di nodi, 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 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 dell'interfaccia a riga di comando gcloud, 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 del progetto host del parco risorse.

    La configurazione di --location=- consente di elencare tutti i cluster in tutte le regioni. Se devi ridurre l'ambito dell'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 del cluster:

Puoi utilizzare kubectl per ottenere la versione dei nodi del cluster, ma kubectl restituisce la versione di Kubernetes. Per ottenere la versione Google Distributed Cloud 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 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 maggiori informazioni, consulta 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 crei un cluster utente, potrebbe contenere sia nodi worker sia 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 del piano di controllo di un cluster utente separatamente dai pool di nodi che eseguono i carichi di lavoro.

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

La procedura di upgrade di Google Distributed Cloud comporta 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 quindi 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 per il carico di lavoro, questa procedura potrebbe influire sulla disponibilità di un'applicazione. Per evitare di sovraccaricare le capacità delle risorse del cluster, Google Distributed Cloud 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 API Kubernetes Non interessato Non interessato Non interessato
Carichi di lavoro utente Non interessato Non interessato Non interessato
PodDisruptionBudget* 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: è visibile un'interruzione del servizio durante l'upgrade fino al termine dell'upgrade.
  • Non interessato: un'interruzione del servizio potrebbe verificarsi per un periodo di tempo molto breve, 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 dell'utente. Durante un upgrade, questi nodi del piano di controllo vengono svuotati e quindi aggiornati di conseguenza.

Negli ambienti con piani di controllo ad alta disponibilità (HA), 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. Per i cluster utente che utilizzano Controlplane V2, l'upgrade del solo piano di controllo non interrompe i carichi di lavoro dell'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à, 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 riusciranno 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 seguente tabella descrive l'impatto di un upgrade del cluster di amministrazione in loco:

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
Ripristino automatico Interessato Interessato Non interessato
Scalabilità automatica dei nodi Interessato Interessato Non interessato
Scalabilità automatica pod orizzontale Interessato Interessato Non interessato
  • Interessato: è visibile un'interruzione del servizio durante l'upgrade fino al termine dell'upgrade.
  • Non interessato: un'interruzione del servizio potrebbe verificarsi per un periodo di tempo molto breve, ma è quasi impercettibile.

Passaggi successivi