Ciclo di vita e fasi degli upgrade dei cluster

Quando esegui l'upgrade di Google Distributed Cloud, il processo di upgrade prevede più passaggi e componenti. Per monitorare lo stato dell'upgrade o diagnosticare e risolvere i problemi problemi, è utile sapere cosa succede quando esegui il comando bmctl upgrade cluster. Questo documento descrive in dettaglio i componenti e le fasi di un cluster upgrade.

Panoramica

Il processo di upgrade sposta il tuo cluster Google Distributed Cloud dall'attuale a una versione successiva.

Le informazioni sulla versione vengono archiviate nelle seguenti posizioni nell'ambito di risorsa personalizzata nel cluster di amministrazione:

  • status.anthosBareMetalVersion: definisce la versione corrente del cluster.

  • spec.anthosBareMetalVersion: definisce la versione di destinazione e viene impostato quando viene avviata l'esecuzione del processo di upgrade.

Le riconciliazioni di un'operazione di upgrade riuscita Da status.anthosBareMetalVersion a spec.anthosBareMetalVersion in modo che vengano visualizzati entrambi la versione di destinazione.

Disallineamento delle versioni del cluster

Il disallineamento delle versioni del cluster è la differenza nelle versioni (ibrido o amministratore) e i relativi cluster utente gestiti. Quando aggiungi o esegui l'upgrade per un cluster utente, vengono applicate le seguenti regole di versione:

1,29

Le regole seguenti si applicano ai cluster utente gestiti da un amministratore della versione 1.29 in un cluster o in un cluster ibrido:

  • Le versioni del cluster utente non possono essere successive a quelle del cluster di gestione (ammin. o ibrida).

  • (1.29 Anteprima) I cluster utente possono essere fino a due versioni secondarie sotto la versione del cluster di gestione. Per Ad esempio, un cluster di amministrazione della versione 1.29 può gestire un cluster utente 1.16. Questa gestione del disallineamento delle versioni n-2 è disponibile come Funzionalità di anteprima per la gestione alla versione 1.29.

  • (1.29 Anteprima) Per un determinato gestore non è necessario che i cluster utente abbiano la stessa versione secondaria e l'altro. Ad esempio, un amministratore della versione 1.29 il cluster può gestire le versioni 1.29, 1.28 e 1.16 cluster. La gestione del disallineamento delle versioni mista è disponibile Funzionalità Anteprima per nella gestione dei cluster alla versione 1.29.

    La gestione dell'inclinazione multipla in Anteprima offre una maggiore flessibilità per pianificare gli upgrade del parco dispositivi. Per Ad esempio, non è necessario eseguire l'upgrade di tutti i cluster utente della versione 1.16. alla versione 1.28 prima di eseguire l'upgrade del cluster di amministrazione alla versione 1,29.

1.28 e precedenti

Le regole seguenti si applicano ai cluster utente gestiti da una versione 1.28 o cluster di amministrazione o cluster ibrido precedente:

  • Le versioni del cluster utente non possono essere successive a quelle del cluster di gestione (ammin. o ibrida).

  • I cluster utente possono essere fino a una versione secondaria al di sotto del livello di gestione della versione del cluster. Ad esempio, un cluster di amministrazione della versione 1.28 non può gestire per un cluster utente alla versione 1.15.

  • Per un determinato cluster di gestione, tutti i cluster utente gestiti devono trovarsi la stessa versione secondaria.

Per informazioni sulle regole di disallineamento delle versioni per i pool di nodi, consulta Regole di controllo delle versioni del pool di nodi.

Regole per le versioni

Se scarichi e installi una nuova versione di bmctl, puoi eseguire l'upgrade del tuo di amministrazione, ibridi, autonomi e utenti creati o sottoposti a upgrade con una versione versione di bmctl. Non è possibile eseguire il downgrade dei cluster a una versione precedente.

Puoi eseguire l'upgrade di un cluster solo a una versione che corrisponde versione di bmctl in uso. Vale a dire che se utilizzi la versione 1.29.300--gke.185 di bmctl, puoi eseguire l'upgrade di un cluster alla versione 1.29.300--gke.185 solo.

Upgrade delle versioni delle patch

Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione di patch superiore. Vale a dire che puoi eseguire l'upgrade di un 1.29.X dal cluster alla versione 1.29.Y a lungo Y è maggiore di X. Ad esempio, puoi eseguire l'upgrade Da 1.28.0 a 1.28.100 e puoi eseguire l'upgrade da 1.28.100 a 1.28.300. Ti consigliamo di eseguire l'upgrade all'ultima versione della patch quando possibile per assicurarti che i cluster abbiano correzioni di sicurezza più recenti.

Upgrade delle versioni minori

Puoi eseguire l'upgrade dei cluster da una versione secondaria all'altra, indipendentemente versione patch. Vale a dire che puoi eseguire l'upgrade Da 1.N.X a 1.N+1.Y, dove 1.N.X è la versione del tuo cluster e N+1 è il successivo una versione secondaria. Le versioni patch, X e Y, in questo caso non influiscono sulla logica di upgrade. Per Ad esempio, puoi eseguire l'upgrade da 1.28.700-gke.150 a 1.29.300--gke.185.

Non puoi saltare le versioni secondarie durante l'upgrade dei cluster. Se tenti di eseguire l'upgrade a una versione secondaria superiore di due o più versioni secondarie rispetto al cluster dell'app, bmctl emette un errore. Ad esempio, non puoi eseguire l'upgrade di una versione 1.16.0 cluster alla versione 1.29.0.

Un cluster di amministrazione può gestire i cluster utente che si trovano sullo stesso elemento o su una precedente completamente gestita. I cluster utente gestiti non possono avere una versione secondaria inferiore di più di una versione del cluster di amministrazione, quindi prima di eseguire l'upgrade di un cluster di amministrazione a una nuova versione secondaria, assicurati che tutti i cluster utente gestiti abbiano la stessa versione secondaria del cluster di amministrazione.

Regole di controllo delle versioni dei pool di nodi

Quando eseguire l'upgrade dei pool di nodi in modo selettivo, si applicano le seguenti regole di versione:

1,29

  • La versione del cluster deve essere maggiore o uguale al pool di nodi worker completamente gestita.

  • (1.29 GA) Disallineamento massimo delle versioni tra un pool di nodi worker e il è costituito da due versioni secondarie.

  • I pool di nodi worker non possono avere una versione rilasciata cronologicamente successiva alla versione del cluster. La release precedente non include dettagli completi per la release successiva, che è un requisito per la compatibilità.

    Ad esempio, la versione 1.16.6 rilasciata dopo la versione È stato rilasciato il file 1.28.100-gke.146, pertanto non puoi eseguire l'upgrade del cluster dalla versione 1.16.6 alla versione 1.28.100-gke.146 e lasciano un nodo worker nella versione 1.16.6. Analogamente, se esegui l'upgrade del cluster versione 1.28.100-gke.146, ma ha scelto di lasciare un pool di nodi worker in versione 1.16.5, non puoi eseguire l'upgrade del pool di nodi worker alla versione 1.16.6 mentre il cluster è alla versione 1.28.100-gke.146.

1,28

  • La versione del cluster deve essere maggiore o uguale al pool di nodi worker completamente gestita.

  • (1.28 Anteprima) Versione massima il disallineamento tra un pool di nodi worker e il cluster è costituito da due versioni secondarie quando le versioni n-2 disallineano La funzionalità Anteprima è attivata. Se non abilitare questa funzionalità, il disallineamento massimo della versione tra di pool di nodi e il cluster è una versione secondaria.

  • I pool di nodi worker non possono avere una versione rilasciata cronologicamente successiva alla versione del cluster. La release precedente non include dettagli completi per la release successiva, che è un requisito per la compatibilità.

    Ad esempio, la versione 1.16.6 rilasciata dopo la versione È stato rilasciato il file 1.28.100-gke.146, pertanto non puoi eseguire l'upgrade del cluster dalla versione 1.16.6 alla versione 1.28.100-gke.146 e lasciano un nodo worker nella versione 1.16.6. Analogamente, se esegui l'upgrade del cluster versione 1.28.100-gke.146, ma ha scelto di lasciare un pool di nodi worker in versione 1.16.5, non puoi eseguire l'upgrade del pool di nodi worker alla versione 1.16.6 mentre il cluster è alla versione 1.28.100-gke.146.

1,16

  • La versione del cluster deve essere maggiore o uguale al pool di nodi worker completamente gestita.

  • Il disallineamento massimo delle versioni tra un pool di nodi worker e il cluster è uno una versione secondaria.

  • I pool di nodi worker non possono avere una versione rilasciata cronologicamente successiva alla versione del cluster. La release precedente non include dettagli completi per la release successiva, che è un requisito per la compatibilità.

    Ad esempio, la versione 1.16.6 rilasciata dopo la versione È stato rilasciato il file 1.28.100-gke.146, pertanto non puoi eseguire l'upgrade del cluster dalla versione 1.16.6 alla versione 1.28.100-gke.146 e lasciano un nodo worker nella versione 1.16.6. Analogamente, se esegui l'upgrade del cluster versione 1.28.100-gke.146, ma ha scelto di lasciare un pool di nodi worker in versione 1.16.5, non puoi eseguire l'upgrade del pool di nodi worker alla versione 1.16.6 mentre il cluster è alla versione 1.28.100-gke.146.

La tabella seguente elenca le versioni del pool di nodi supportate consentite per una specifica versione del cluster:

1,29

Versione del cluster (piano di controllo) Versioni del pool di nodi worker supportate
1.29.300-gke.185
  • 1.29.300-gke.185
  • 1.29.200-gke.243
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.200-gke.243
  • 1.29.200-gke.243
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.100-gke.251
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.0-gke.1449
  • 1.29.0-gke.1449
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0

1,28

Versione del cluster (piano di controllo) Versioni del pool di nodi worker supportate
1.28.700-gke.150
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.600-gke.163
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.500-gke.120
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.400-gke.77
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.300-gke.131
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.200-gke.118
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.100-gke.146
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.0-gke.425
  • 1.28.0-gke.425
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

     

     

     

1,16

Versione del cluster (piano di controllo) Versioni del pool di nodi worker supportate
1.16.11
  • 1.16.11
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.10
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.10
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.9
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.8
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.7
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.6
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.5
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.4
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.3
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.2
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.1
  • 1.16.1
  • 1.16.0
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.0
  • 1.16.0
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

Esegui l'upgrade dei componenti

L'upgrade dei componenti viene eseguito sia a livello di nodo che di cluster. Al a livello di cluster, viene eseguito l'upgrade dei seguenti componenti:

  • Componenti del cluster per networking, osservabilità e archiviazione.
  • Per i cluster di amministrazione, ibridi e autonomi, i controller del ciclo di vita.
  • L'elemento gke-connect-agent.

I nodi in un cluster vengono eseguiti con uno dei seguenti ruoli, con componenti diversi upgrade eseguito in base al ruolo del nodo:

Ruolo del nodo Funzione Componenti di cui eseguire l'upgrade
Worker Esegue carichi di lavoro utente Kubelet, runtime del container (Docker o containerd)
Piano di controllo Esegue il piano di controllo Kubernetes, i controller del ciclo di vita dei cluster Componenti aggiuntivi della piattaforma Google Kubernetes Engine (GKE) Enterprise Pod statici del piano di controllo Kubernetes (kubeapi-server, kube-scheduler, kube-controller-manager e così via)

Controller del ciclo di vita come lifecycle-controllers-manager e anthos-cluster-operator

Componenti aggiuntivi della piattaforma Google Kubernetes Engine (GKE) Enterprise come stackdriver-log-aggregator e gke-connect-agent
Bilanciatore del carico del piano di controllo Esegue HAProxy e KeepaLifetime che gestiscono il traffico kube-apiserver ed esegui speaker MetalLB per richiedere una proprietà IP virtuale indirizzi Pod statici del bilanciatore del carico del piano di controllo (HAProxy, KeepaLive)

Altoparlanti MetalLB

Aspettative relative al tempo di riposo

La tabella seguente descrive in dettaglio il tempo di inattività previsto e l'impatto potenziale quando eseguire l'upgrade dei cluster. Questa tabella presuppone che tu abbia più nodi cluster e un'alta disponibilità dal piano di controllo. Se esegui un cluster autonomo o non hai un controllo ad alta disponibilità il piano tariffario, sono previsti tempi di inattività aggiuntivi. Se non indicato, il tempo di inattività si applica a entrambi upgrade dei cluster di amministrazione e degli utenti:

Componenti Aspettative relative al tempo di riposo Quando si verifica un tempo di inattività
Server API del piano di controllo Kubernetes (kube-apiserver), etcd e scheduler Zero tempi di inattività N/D
Controller del ciclo di vita e job ansible-runner (amministratore ) Zero tempi di inattività N/D
Piano di controllo Kubernetes loadbalancer-haproxy e keepalived Tempo di inattività temporaneo (meno di 1-2 minuti) quando il bilanciatore del carico reindirizza il traffico. Inizio del processo di upgrade.
Osservabilità pipeline-stackdriver e metrics-server Operatore svuotato e aggiornato. Il tempo di riposo dovrebbe essere inferiore a 5 minuti.

I DaemonSet continuano a funzionare senza tempi di inattività.		 Al termine dell'upgrade dei nodi del piano di controllo.
Container Network Interface (CNI) Nessun tempo di inattività per le route di rete esistenti.

Deployment di DaemonSet 2 a due senza tempi di inattività.

È stato eseguito lo svuotamento e l'upgrade dell'operatore. Tempo di riposo inferiore a 5 minuti.		 Al termine dell'upgrade dei nodi del piano di controllo.
MetalLB (solo cluster utente) Operatore svuotato e aggiornato. Il tempo di riposo è inferiore a 5 minuti.

Nessun tempo di inattività per il servizio esistente		 Al termine dell'upgrade dei nodi del piano di controllo.
CoreDNS e gestore della scalabilità automatica DNS (solo cluster utente) CoreDNS ha più repliche con il gestore della scalabilità automatica. Di solito no o un tempo di inattività. Al termine dell'upgrade dei nodi del piano di controllo.
Provisioner volume locale Nessun tempo di inattività per i volumi permanenti di cui è stato eseguito il provisioning (PV) esistenti.

L'operatore potrebbe avere un tempo di riposo di 5 minuti.		 Al termine dell'upgrade dei nodi del piano di controllo.
Istio / in entrata È stato eseguito lo svuotamento e l'upgrade dell'operatore Istio. Circa 5 minuti di o un tempo di inattività.

Il traffico in entrata configurato esistente continuerà a funzionare.		 Al termine dell'upgrade dei nodi del piano di controllo.
Altri operatori di sistema Tempo di inattività di 5 minuti dopo lo svuotamento e l'upgrade. Al termine dell'upgrade dei nodi del piano di controllo.
Carichi di lavoro utente Dipende dalla configurazione, ad esempio dalla disponibilità elevata.

Esamina i deployment dei tuoi carichi di lavoro per comprenderne il potenziale impatto.		 Quando viene eseguito l'upgrade dei nodi worker.

Dettagli dell'upgrade del cluster utente

Questa sezione descrive l'ordine degli upgrade dei componenti e le informazioni sullo stato per di un cluster utente. La seguente sezione descrive le deviazioni da questo flusso per gli upgrade di cluster amministrativi, ibridi o autonomi.

Il seguente diagramma mostra il processo di controllo preflight per l'upgrade di un cluster utente:

Il controllo preflight del cluster esegue ulteriori controlli di integrità sul cluster prima dell'inizio del processo di upgrade.

Il diagramma precedente descrive i passaggi che vengono eseguiti durante un upgrade:

  • Il comando bmctl upgrade cluster crea un file PreflightCheck personalizzato risorsa.
  • Questo controllo preflight esegue controlli aggiuntivi, come i controlli di upgrade del cluster, di integrità di rete e di integrità dei nodi.
  • I risultati di questi controlli aggiuntivi si combinano per indicare la capacità di del cluster per eseguire correttamente l'upgrade alla versione di destinazione.

Se i controlli preflight hanno esito positivo e non ci sono problemi di blocco, di componenti del cluster vengono aggiornati in un ordine specificato, come mostrato nell' diagramma seguente:

Viene eseguito l'upgrade dei bilanciatori del carico e del pool di nodi del piano di controllo, quindi dell'upgrade e poi di GKE Connect, dei componenti aggiuntivi del cluster, del pool di nodi del bilanciatore del carico e dei pool di nodi worker.

Nel diagramma precedente, l'upgrade dei componenti viene eseguito nel seguente modo:

  1. L'upgrade inizia aggiornando spec.anthosBareMetalVersion .
  2. Viene eseguito l'upgrade dei bilanciatori del carico del piano di controllo.
  3. È stato eseguito l'upgrade del pool di nodi del piano di controllo.
  4. In parallelo, viene eseguito l'upgrade di GKE Connect, dei componenti aggiuntivi dei cluster e viene eseguito l'upgrade del pool di nodi del bilanciatore del carico.
    1. Una volta eseguito l'upgrade del pool di nodi del bilanciatore del carico, il worker viene eseguito l'upgrade dei pool di nodi.

  5. Al termine dell'upgrade di tutti i componenti, vengono eseguiti i controlli di integrità del cluster.

    I controlli di integrità continuano a essere eseguiti fino al superamento di tutti i controlli.

  6. Una volta superati tutti i controlli di integrità, l'upgrade è completato.

Ogni componente ha il proprio campo di stato all'interno della risorsa personalizzata Cluster. Tu puoi controllare lo stato in questi campi per comprendere l'avanzamento dell'upgrade:

Sequenza Nome campo Significato
1 status.controlPlaneNodepoolStatus Lo stato viene copiato dallo stato del pool di nodi del piano di controllo. Il campo include le versioni dei nodi dei pool di nodi del piano di controllo
2 status.anthosBareMetalLifecycleControllersManifestsVersion Versione di lifecycles-controllers-manager applicata a in un cluster Kubernetes. Questo campo è disponibile solo per amministratori, utenti autonomi o ibridi cluster.
2 status.anthosBareMetalManifestsVersion Versione del cluster dall'ultimo manifest applicato.
2 status.controlPlaneLoadBalancerNodepoolStatus Lo stato viene copiato dal pool di nodi del bilanciatore del carico del piano di controllo . Questo campo è vuoto se non è presente alcun bilanciatore del carico del piano di controllo separato specificato in Cluster.Spec.
3 status.anthosBareMetalVersions Una mappa aggregata delle versioni in base ai numeri di nodo.
4 status.anthosBareMetalVersion Stato finale della versione aggiornata.

Dettagli sull'upgrade di cluster amministratore, ibrido e autonomo

A partire da bmctl versione 1.15.0, il comportamento predefinito dell'upgrade per I cluster autogestiti (amministratori, ibridi o autonomi) sono un upgrade in loco. Questo significa che quando esegui l'upgrade di un cluster alla versione 1.15.0 o successiva, utilizza controller del ciclo di vita, invece di un cluster di bootstrap, per gestire l'intero processo di upgrade. Questa modifica semplifica il processo e riduce rendendo più affidabili e scalabili gli upgrade dei cluster.

Anche se l'utilizzo di un cluster di bootstrap per l'upgrade non è consigliato, l'opzione è ancora disponibile. Per utilizzare un cluster di bootstrap durante l'upgrade, esegui Comando bmctl upgrade con il flag --use-bootstrap=true. Le fasi dell'upgrade sono diverse a seconda del metodo scelto per gli utilizzi odierni.

Upgrade in loco

Il processo di upgrade in loco predefinito per i cluster autogestiti è simile a il processo di upgrade del cluster utente. Tuttavia, quando utilizzi l'upgrade in loco viene eseguito il deployment di una nuova versione di preflightcheck-operator prima vengono eseguiti controlli preflight e controlli di integrità del cluster:

Viene eseguito il deployment di una nuova versione dell'operatore preflightcheck prima che il controllo preflight del cluster esegua ulteriori controlli di integrità sul cluster.

Come per l'upgrade del cluster utente, il processo di upgrade inizia aggiornando Cluster.spec.anthosBareMetalVersion alla versione di destinazione. Due. ulteriori passaggi eseguiti prima di aggiornare i componenti, come illustrato di seguito diagramma: lifecycle-controller-manager si aggiorna alla versione di destinazione e poi esegue il deployment della versione di destinazione di anthos-cluster-operator. Questo anthos-cluster-operator esegue i passaggi rimanenti del processo di upgrade:

Il deployment di ciclo di vita-controller-manager e anthos-cluster-operator viene eseguito prima dell'upgrade del resto del cluster nello stesso ordine dei componenti del cluster utente.

Se l'operazione riesce, anthos-cluster-operator riconcilia la versione di destinazione da spec.anthosBareMetalVersion a status.anthosBareMetalVersion.

Esegui l'upgrade con un cluster di bootstrap

Il processo per eseguire l'upgrade di un cluster di amministrazione, ibrido o autonomo è simile a un di cui abbiamo parlato nella sezione precedente.

La differenza principale è che il comando bmctl upgrade cluster avvia un processo per creare un cluster di bootstrap. Questo cluster di bootstrap è un cluster temporaneo che gestisce il cluster ibrido, di amministrazione o autonomo durante un upgrade.

Il processo per trasferire la proprietà della gestione del cluster al bootstrap cluster è chiamato pivot. Il resto dell'upgrade segue la stessa procedura eseguire l'upgrade del cluster utente.

Durante il processo di upgrade, le risorse nel cluster di destinazione rimangono inattive. L'avanzamento dell'upgrade si riflette solo nelle risorse del bootstrap in un cluster Kubernetes.

Se necessario, puoi accedere al cluster di bootstrap per monitorare ed eseguire il debug del processo di upgrade. È possibile accedere al cluster di bootstrap bmctl-workspace/.kindkubeconfig.

Per trasferire nuovamente la proprietà della gestione del cluster dopo l'upgrade, completato, il cluster esegue il pivot delle risorse dal cluster di bootstrap con upgrade eseguito. Non devi eseguire alcun passaggio manuale per eseguire il pivot del cluster durante il processo di upgrade. Il cluster di bootstrap viene eliminato dopo il cluster upgrade eseguito correttamente.

Svuotamento dei nodi

Gli upgrade dei cluster Google Distributed Cloud potrebbero causare interruzioni delle applicazioni i nodi vengono svuotati. Questo processo di svuotamento fa sì che tutti i pod in esecuzione su un nodo arresta e riavvia sui nodi rimanenti nel cluster.

I deployment possono essere utilizzati per tollerare queste interruzioni. Un deployment può specificare è necessario eseguire più repliche di un'applicazione o di un servizio. Un'applicazione con più repliche dovrebbero subire interruzioni minime o nulle durante gli upgrade.

PodDisruptionBudgets (PDB)

Quando esegui l'upgrade di un cluster, Google Distributed Cloud utilizza la modalità di manutenzione per lo svuotamento dei nodi.

A partire dalla release 1.29, i nodi vengono svuotati con l'API Eviction, che onora PodDisruptionBudgets (PDB). I PDB possono essere usati per garantire che un di repliche eseguite nel cluster in condizioni di esecuzione normali. I PDB consentono di limitare l'interruzione di un carico di lavoro quando è necessario riprogrammato. Lo svuotamento dei nodi basato su eliminazione è disponibile come GA per la release 1.29.

Nelle release 1.28 e precedenti, Google Distributed Cloud non rispetta i PDB quando i nodi lo svuotamento durante un upgrade. Il processo di svuotamento dei nodi rappresenta invece il miglior tentativo. Alcune I pod potrebbero rimanere bloccati in uno stato Terminating e rifiutarsi di liberare il nodo. La l'upgrade continua, anche con i pod bloccati, quando il processo di svuotamento su un nodo richiede più di 20 minuti.

Per ulteriori informazioni, consulta Eseguire la manutenzione dei nodi .

Passaggi successivi