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. Scopri come prepararti agli upgrade dei cluster e le best practice 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 l'upgrade è 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 funzionano tutti 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 causare interruzioni. Prima di iniziare l'upgrade, pianifica attentamente per assicurarti che l'ambiente e le applicazioni siano pronti.

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 l'upgrade dei nodi viene eseguito in sequenza. Pertanto, il tempo totale di 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, il tempo di upgrade totale sarà di circa 150 minuti.

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

Esegui il backup del cluster utente e di quello di amministrazione

Prima di iniziare 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'etcd store contiene tutti gli oggetti Kubernetes e 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 di utenti.

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 attivare questa funzione in una modificare il file di configurazione del cluster di amministrazione e aggiungere 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. Questa procedura di backup si ripete ogni volta che viene apportata una modifica al cluster di amministrazione. Quando avvii un upgrade del cluster, prima dell'upgrade viene eseguita un'attività di backup.

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

Rivedi l'utilizzo di PodDisruptionBudgets

In Kubernetes, PodDisruptionBudgets (PDB) può aiutare a prevenire con tempi di inattività o interruzioni delle applicazioni. I PDB ordinano allo scheduler di mantenere sempre in esecuzione un certo numero di pod, anche se altri pod potrebbero non funzionare correttamente. 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 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 vengono svuotati.

Controlla i PDB che non possono essere soddisfatti. Ad esempio, puoi impostare una disponibilità minima di 1 se il deployment contiene una sola replica. In questo esempio, l'operazione di svuotamento viene interrotta perché il PDB non può essere soddisfatto dal controller delle 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 senza problemi. Per scoprire di più sui PDB, consulta: Specificare un budget di interruzione per l'applicazione.

Esamina gli indirizzi IP disponibili

Durante gli upgrade dei cluster si applicano le seguenti considerazioni relative agli indirizzi IP:

  • La procedura di upgrade del cluster crea un nuovo nodo e scarica le risorse prima di eliminare il vecchio nodo. 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 DHCP, assicurati che le nuove VM possano ottenere lease IP aggiuntivi nella subnet desiderata 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 a disposizione un indirizzo IP aggiuntivo. 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, prima di procedere, tieni conto della disponibilità delle risorse e delle prestazioni del tuo ambiente vSphere.
  • Se esiste un solo IP di riserva per l'intero cluster di utenti, questa limitazione rallenta la procedura di upgrade a una sola VM alla volta, anche se vengono utilizzati più pool di nodi.

Controllare l'utilizzo del cluster

Assicurati che i pod possano essere evacuati quando il nodo si svuota e che nel cluster di cui viene eseguito l'upgrade siano presenti risorse 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 consumate nel tempo. Questi dati sull'utilizzo delle risorse possono indicare quando un upgrade causerebbe le interruzioni meno gravi, ad esempio durante i fine settimana o la sera, a seconda del carico di lavoro e dei casi d'uso in esecuzione.

I tempi dell'upgrade del cluster di amministrazione potrebbero essere meno critici rispetto a quelli dei cluster utente, perché in genere un upgrade del cluster di amministrazione non comporta tempi di 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.

Controllare l'utilizzo di vSphere

Verifica che le risorse dell'infrastruttura vSphere di base siano sufficienti. Per controllare questo utilizzo delle risorse, seleziona un cluster in vCenter e controlla la scheda Riepilogo.

La scheda Riepilogo mostra il consumo complessivo di memoria, CPU e spazio di archiviazione dell'intero cluster. Poiché gli upgrade di Google Distributed Cloud richiedono ulteriori 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 le seguenti risorse aggiuntive:

  • +1 VM per upgrade del cluster di amministrazione
  • 1 VM in più 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. La clonazione di più VM da un modello può sottoporre a stress il sistema di archiviazione sottostante sotto forma di aumento delle operazioni di I/O. 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 disponga di meccanismi per fornire risorse anche in caso di overcommit, ti consigliamo vivamente di non eseguire 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 che hanno pod in uno stato bloccato. Se il comando gkectl diagnose mostra un avviso Cluster unhealthy, risolvi i problemi prima di tentare un upgrade. Per ulteriori informazioni, vedi Diagnosticare i problemi del cluster.

  • Lo strumento di pre-upgrade: oltre a controllare lo stato e la configurazione del cluster, lo strumento di pre-upgrade controlla la presenza di potenziali problemi noti che potrebbero verificarsi durante un 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 controlli preflight ma non avvia la procedura di upgrade. Sebbene le versioni precedenti Google Distributed Cloud esegue controlli preflight, non possono essere eseguiti separatamente l'upgrade. Aggiungendo il flag --dry-run, puoi trovare e risolvere eventuali problemi rilevati dai controlli preflight nel cluster utente prima dell'upgrade.

Utilizzare 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 devono essere arrestati e riavviati sui nodi rimanenti del cluster.

Se possibile, le applicazioni devono utilizzare i deployment. Con questo approccio, 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 numero predefinito di repliche rimanga sempre in esecuzione. Queste regole sono note come PodDisruptionBudgets (PDB). I PDB ti consentono di limitare l'interruzione di un carico di lavoro quando i relativi pod devono essere riprogrammati per qualche motivo, ad esempio per upgrade o manutenzione dei nodi del cluster, e sono importanti da controllare 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 upgrade e di un eventuale errore del bilanciatore del carico, puoi utilizzare una coppia ad alta disponibilità. In questa configurazione, il sistema crea e configura due VM bilanciatore del carico in modo che possa verificarsi un failover all'altro peer.

Per aumentare la disponibilità del servizio (ovvero del server API Kubernetes), consigliamo di utilizzare sempre una coppia HA davanti al cluster di amministrazione. Per apprendere 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 cluster di utenti utilizza una sola istanza di bilanciatore del carico, si verifica un'interruzione del servizio fino al completamento dell'upgrade del bilanciatore del carico.

Ti consigliamo di avere una coppia di bilanciatori del carico ad alta disponibilità se anche il cluster di utenti è configurato per essere ad alta disponibilità. Questa serie di best practice presuppone che un cluster di utenti HA utilizzi una coppia di bilanciatori del carico HA.

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

Decidi come eseguire l'upgrade di ciascun cluster utente

Nella versione 1.14 e successive, 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 del cluster), oppure puoi eseguire l'upgrade del piano di controllo del cluster utente e lasciare i pool di nodi nella versione corrente. Per informazioni sul motivo per cui potresti voler eseguire l'upgrade del control plane 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 relativo numero di versione. Se decidi di eseguire l'upgrade del control plane e dei pool di nodi separatamente, registra la versione del control plane e di ogni pool di nodi in ogni cluster.

Controllare le versioni dei cluster utente e di amministrazione

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 registrati nell'API GKE On-Prem, puoi utilizzare il client gcloud per ottenere le versioni dei cluster utente, dei pool di nodi nel cluster utente e dei cluster di amministrazione.

  1. Assicurati di avere la versione più recente della CLI gcloud. Aggiorna i componenti dell'interfaccia a riga di comando gcloud, se necessario:

    gcloud components update

  2. Esegui i seguenti comandi per controllare le versioni:

  • Per controllare la versione dei cluster di utenti:

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

    Sostituisci PROJECT_ID con l'ID del progetto host del tuo parco veicoli.

    L'impostazione di --location=- consente di elencare tutti i cluster in regioni. Se devi restringere l'ambito dell'elenco, imposta --location sulla regione specificata quando hai registrato il 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 control plane 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 del cluster utente rispetto a quelli del 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 nodo worker svuotato e la aggiunge al cluster. I nodi worker svuotati vengono quindi rimosso dall'inventario di VMware. Durante questa procedura, qualsiasi carico di lavoro in esecuzione su questi nodi viene interrotto e riavviato su altri nodi disponibili del 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.

Interruzioni 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 all'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 control plane 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: potrebbe verificarsi un'interruzione del servizio per un breve periodo di tempo, ma è quasi impercettibile.

I nodi del control plane 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 degli utenti. 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 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 all'API Kubernetes Interessato Interessato Non interessato
Carichi di lavoro utente Non interessato Non interessato Non interessato
Nodo del control plane 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