Quando esegui l'upgrade di GKE su Bare Metal, il processo di upgrade prevede più passaggi e componenti. Per monitorare lo stato dell'upgrade o diagnosticare e risolvere i problemi, è utile sapere che cosa succede quando esegui il comando bmctl upgrade cluster. Questo documento descrive in dettaglio i componenti
e le fasi dell'upgrade di un cluster.
Panoramica
Il processo di upgrade sposta il tuo cluster GKE su Bare Metal dalla versione attuale a una versione superiore.
Queste informazioni sulla versione sono archiviate nelle seguenti località come parte della risorsa personalizzata del cluster nel cluster di amministrazione:
status.anthosBareMetalVersion: definisce la versione corrente del cluster.spec.anthosBareMetalVersion: definisce la versione di destinazione e viene impostata all'avvio del processo di upgrade.
Un'operazione di upgrade riuscita riconcilia status.anthosBareMetalVersion
con spec.anthosBareMetalVersion in modo che entrambi mostrino la versione di destinazione.
Disallineamento delle versioni
Il disallineamento delle versioni è la differenza tra le versioni di un cluster di amministrazione e dei relativi cluster utente gestiti. I cluster GKE su Bare Metal seguono lo stesso stile di Kubernetes: il cluster di amministrazione può avere al massimo una versione secondaria prima dei relativi cluster gestiti.
Regole per le versioni per gli upgrade
Quando scarichi e installi una nuova versione di bmctl, puoi eseguire l'upgrade dei cluster di amministrazione, ibridi, autonomi e utente creati o di cui è stato eseguito l'upgrade con una versione precedente di bmctl. Non è possibile eseguire il downgrade dei cluster a una versione precedente.
Puoi eseguire l'upgrade di un cluster solo a una versione corrispondente
alla versione di bmctl che stai utilizzando. Ciò significa che se utilizzi la versione 1.16.8 di bmctl, puoi eseguire l'upgrade di un cluster solo alla versione 1.16.8.
Upgrade della versione delle patch
Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione patch successiva. In altre parole,
puoi eseguire l'upgrade di un cluster di versione 1.16.X
alla versione
1.16.Y, purché
Y sia superiore a
X. Ad esempio, puoi eseguire l'upgrade da
1.15.0 a 1.15.1 e puoi eseguire l'upgrade da
1.15.1 a 1.15.3. Ti consigliamo di eseguire l'upgrade alla versione più recente della patch quando possibile per assicurarti che i tuoi cluster dispongano delle correzioni di sicurezza più recenti.
Upgrade della versione secondaria
Puoi eseguire l'upgrade dei cluster da una versione secondaria alla successiva, indipendentemente dalla versione della patch. In altre parole, 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 è la prossima
versione secondaria disponibile. In questo caso, le versioni della patch, X e
Y, non influiscono sulla logica di upgrade. Ad
esempio, puoi eseguire l'upgrade da 1.15.3 a 1.16.8.
Non puoi saltare le versioni secondarie durante l'upgrade dei cluster. Se tenti di eseguire l'upgrade a una versione secondaria superiore a quella del cluster di due o più versioni secondarie, bmctl genera un errore. Ad esempio, non puoi eseguire l'upgrade di un cluster di versione 1.14.0 alla versione 1.16.0.
Un cluster di amministrazione può gestire i cluster utente che si trovano nella versione secondaria uguale o precedente. I cluster utente gestiti non possono essere inferiori di più di una versione secondaria rispetto al cluster di amministrazione. Di conseguenza, 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.
Gli esempi nelle seguenti istruzioni per l'upgrade mostrano il processo di upgrade dalla versione 1.15.2 a GKE su Bare Metal 1.16.8.
Regole di controllo delle versioni dei pool di nodi
Quando esegui l'upgrade dei pool di nodi in modo selettivo, si applicano le seguenti regole di versione:
La versione del cluster deve essere superiore o uguale alla versione del pool di nodi worker.
Il disallineamento massimo tra la versione del cluster e la versione del pool di nodi worker è di una versione secondaria.
I pool di nodi worker non possono essere a una versione rilasciata dopo la versione del cluster.
Ad esempio, con un cluster alla versione 1.15.4, che non era disponibile quando è stata rilasciata la versione 1.16.0, non puoi eseguire l'upgrade alla versione 1.16.0 e lasciare un pool di nodi worker alla versione 1.15.4. Allo stesso modo, se hai eseguito l'upgrade alla versione 1.16.0, ma hai scelto di lasciare un pool di nodi worker alla versione 1.15.2, non puoi eseguire l'upgrade del pool di nodi worker alla versione 1.15.4 in un secondo momento.
La seguente tabella elenca le versioni del pool di nodi supportate consentite per una versione specifica del cluster:
| Versione cluster (piano di controllo) | Versioni di pool di nodi worker supportate | |||
|---|---|---|---|---|
| 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 |
|
|
||
Esegui l'upgrade dei componenti
L'upgrade dei componenti viene eseguito a livello di nodo e di cluster. A livello di cluster, viene eseguito l'upgrade dei seguenti componenti:
- Componenti del cluster per networking, osservabilità e archiviazione.
- Per cluster amministrativi, ibridi e autonomi, i controller del ciclo di vita.
- L'elemento
gke-connect-agent.
I nodi in un cluster vengono eseguiti come uno dei seguenti ruoli, con upgrade di componenti diversi in base al ruolo del nodo:
| Ruolo del nodo | Funzione | Componenti da aggiornare |
|---|---|---|
| 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 e i 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-operatorComponenti 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 KeepaDuration che gestiscono il traffico a kube-apiserver ed eseguono speaker MetalLB per rivendicare gli indirizzi IP virtuali |
Pod statici del bilanciatore del carico del piano di controllo (HAProxy, KeepaDuration)
Speaker MetalLB |
Aspettativa di tempo di riposo
La seguente tabella descrive i tempi di inattività previsti e il potenziale impatto quando esegui l'upgrade dei cluster. Questa tabella presuppone la presenza di più nodi cluster e di un piano di controllo ad alta disponibilità. Se esegui un cluster autonomo o non hai un piano di controllo ad alta disponibilità, è previsto tempi di inattività aggiuntivi. Se non diversamente specificato, questo tempo di inattività si applica agli upgrade dei cluster di amministrazione e utente:
| Componenti | Aspettative relative al tempo di riposo | Quando si verifica il tempo di riposo |
|---|---|---|
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 (solo cluster di amministrazione) |
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 |
Utente svuotato ed eseguito l'upgrade. 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. |
| Interfaccia di rete del container (CNI) | Nessun tempo di inattività per le route di networking esistenti. Deployment di DaemonSet 2:2 senza tempi di inattività. Svuotamento dell'operatore ed è stato eseguito l'upgrade. Tempo di riposo inferiore a 5 minuti. |
Al termine dell'upgrade dei nodi del piano di controllo. |
| MetalLB (solo cluster utente) | Utente svuotato ed eseguito l'upgrade. 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 DNS gestore della scalabilità automatica (solo cluster utente) | CoreDNS ha più repliche con il gestore della scalabilità automatica. Solitamente senza tempi di inattività. | Al termine dell'upgrade dei nodi del piano di controllo. |
| Provisioning del volume locale | Nessun tempo di inattività per i volumi permanenti (PV) di cui è stato eseguito il provisioning esistente.
L'operatore potrebbe avere un tempo di inattività di 5 minuti. |
Al termine dell'upgrade dei nodi del piano di controllo. |
| Istio / Ingress | Viene svuotato ed eseguito l'upgrade dell'operatore Istio. Tempo di inattività di circa 5 minuti. Il traffico in entrata configurato esistente continua a funzionare. |
Al termine dell'upgrade dei nodi del piano di controllo. |
| Altri operatori di sistema | 5 minuti di tempo di inattività in caso di svuotamento e 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 comprendere il potenziale impatto. |
Quando viene eseguito l'upgrade dei nodi worker. |
Dettagli dell'upgrade del cluster utente
Questa sezione descrive in dettaglio l'ordine degli upgrade dei componenti e le informazioni sullo stato per l'upgrade di un cluster utente. La sezione seguente 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 diagramma precedente descrive in dettaglio i passaggi che si verificano durante un upgrade:
- Il comando
bmctl upgrade clustercrea una risorsa personalizzataPreflightCheck. - Questo controllo preflight esegue controlli aggiuntivi come quelli di upgrade del cluster, di integrità della rete e dei nodi.
- I risultati di questi controlli aggiuntivi vengono combinati per segnalare la capacità del cluster di eseguire correttamente l'upgrade alla versione di destinazione.
Se i controlli preflight hanno esito positivo e non sono presenti problemi che bloccano la migrazione, l'upgrade dei componenti nel cluster viene eseguito in un ordine specificato, come mostrato nel diagramma seguente:
Nel diagramma precedente, l'upgrade dei componenti viene eseguito nel seguente modo:
- L'upgrade inizia aggiornando il campo
spec.anthosBareMetalVersion. - È stato eseguito l'upgrade dei bilanciatori del carico del piano di controllo.
- Viene eseguito l'upgrade del pool di nodi del piano di controllo.
- Parallelamente, viene eseguito l'upgrade di GKE Connect, dei componenti aggiuntivi del cluster e del pool di nodi del bilanciatore del carico.
- Una volta completato l'upgrade del pool di nodi del bilanciatore del carico, viene eseguito l'upgrade dei pool di nodi worker.
Una volta eseguito l'upgrade di tutti i componenti, vengono eseguiti i controlli di integrità del cluster.
I controlli di integrità continuano a essere eseguiti finché non vengono superati tutti i controlli.
Una volta superati tutti i controlli di integrità, l'upgrade è terminato.
Ogni componente ha un proprio campo di stato all'interno della risorsa personalizzata Cluster. 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 al cluster. Questo campo è disponibile solo per cluster di amministrazione, autonomi o ibridi. |
| 2 | status.anthosBareMetalManifestsVersion |
Versione del cluster dall'ultimo manifest applicato. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
Lo stato viene copiato dallo stato del pool di nodi del bilanciatore del carico del piano di controllo. Questo campo è vuoto se non viene specificato alcun bilanciatore del carico del piano di controllo separato in Cluster.Spec. |
| 3 | status.anthosBareMetalVersions |
Una mappa aggregata della versione della versione ai numeri di nodi. |
| 4 | status.anthosBareMetalVersion |
Stato finale della versione aggiornata. |
Dettagli dell'upgrade dei cluster amministrativi, ibridi e autonomi
A partire dalla versione 1.15.0 di bmctl, il comportamento predefinito per l'upgrade dei cluster autogestiti (amministratori, ibridi o autonomi) è un upgrade in loco.
Ciò significa che quando esegui l'upgrade di un cluster alla versione 1.15.0 o successiva, l'upgrade utilizza controller del ciclo di vita, anziché un cluster di bootstrap, per gestire l'intero processo di upgrade. Questa modifica semplifica il processo e riduce i requisiti
di risorse, rendendo gli upgrade dei cluster più affidabili e scalabili.
Sebbene non sia consigliato utilizzare un cluster di bootstrap per l'upgrade, l'opzione è ancora disponibile. Per utilizzare un cluster di bootstrap quando esegui l'upgrade, esegui il comando bmctl upgrade con il flag --use-bootstrap=true.
Le fasi dell'upgrade sono diverse a seconda del metodo utilizzato.
Upgrade in loco
Il processo predefinito di upgrade in loco per i cluster autogestiti è simile al processo di upgrade dei cluster utente. Tuttavia, quando utilizzi il processo di upgrade in loco, viene eseguito il deployment di una nuova versione di preflightcheck-operator prima dell'esecuzione del controllo preflight del cluster e dei controlli di integrità:
Come per l'upgrade del cluster utente, il processo di upgrade inizia aggiornando il campo Cluster.spec.anthosBareMetalVersion alla versione di destinazione. Vengono eseguiti due passaggi aggiuntivi prima che i componenti vengano aggiornati, come mostrato nel seguente schema: lifecycle-controller-manager esegue automaticamente l'upgrade alla versione di destinazione, quindi esegue il deployment della versione di destinazione di anthos-cluster-operator. Questa azione
anthos-cluster-operator esegue i restanti passaggi del processo di upgrade:
Se l'operazione riesce, l'anthos-cluster-operator riconcilia la versione di destinazione da
spec.anthosBareMetalVersion a status.anthosBareMetalVersion.
Esegui l'upgrade con un cluster di bootstrap
Il processo di upgrade di un cluster amministratore, ibrido o autonomo è simile a quello di un cluster utente discusso 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, amministratore o autonomo durante un upgrade.
Il processo per trasferire la proprietà della gestione del cluster al cluster di bootstrap è chiamato pivot. Il resto dell'upgrade segue la stessa procedura dell'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 cluster di bootstrap.
Se necessario, puoi accedere al cluster di bootstrap per facilitare il monitoraggio e il debug del processo di upgrade. È possibile accedere al cluster di bootstrap tramite bmctl-workspace/.kindkubeconfig.
Per trasferire di nuovo la proprietà gestita del cluster dopo il completamento dell'upgrade, il cluster esegue il pivot delle risorse dal cluster di bootstrap al cluster di cui è stato eseguito l'upgrade. Non devi eseguire passaggi manuali per eseguire il pivot del cluster durante il processo di upgrade. Il cluster di bootstrap viene eliminato dopo il completamento dell'upgrade del cluster.
Svuotamento dei nodi
Gli upgrade dei cluster GKE su Bare Metal potrebbero causare l'interruzione delle applicazioni durante lo svuotamento dei nodi. Questo processo di svuotamento provoca l'arresto e il riavvio di tutti i pod in esecuzione su un nodo sui nodi rimanenti nel cluster.
Gli oggetti Deployment possono essere usati per tollerare questo tipo di interruzione. Un oggetto Deployment può specificare più repliche per l'esecuzione di un'applicazione o un servizio. Un'applicazione con più repliche dovrebbe subire interruzioni minime o nulle durante gli upgrade.
Budget di interruzione dei pod (PDB)
Puoi utilizzare i budget per l'interruzione dei pod (PDB) per garantire che un numero definito di repliche venga sempre eseguito nel cluster in condizioni di esecuzione normali. I PDB consentono di limitare l'interruzione di un carico di lavoro quando è necessario ripianificare i pod.
Tuttavia, GKE su Bare Metal non rispetta i PDB quando i nodi vengono svuotati durante un upgrade.
Invece, il processo di svuotamento dei nodi è il modo migliore. Alcuni pod potrebbero bloccarsi in uno stato Terminating e rifiutarsi di liberare il nodo. L'upgrade continua, anche con i pod bloccati, quando il processo di svuotamento su un nodo richiede più di 20 minuti.
Passaggi successivi
- Consulta le best practice per gli upgrade di GKE su Bare Metal
- Esegui l'upgrade dei cluster
- Risolvere i problemi di upgrade del cluster