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 cosa succede quando esegui il comando bmctl upgrade cluster. Questo documento descrive in dettaglio i componenti e le fasi di un upgrade del cluster.
Panoramica
Il processo di upgrade sposta 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 attuale del cluster.spec.anthosBareMetalVersion: definisce la versione desiderata e viene impostato quando inizia l'esecuzione del processo di upgrade.
Un'operazione di upgrade riuscita riconcilia la versione desiderata da
spec.anthosBareMetalVersion a
status.anthosBareMetalVersion.
Disallineamento delle versioni
Il disallineamento delle versioni è la differenza tra le versioni di un cluster di amministrazione e dei relativi cluster utente gestiti. GKE su Bare Metal segue lo stesso stile di Kubernetes: il cluster di amministrazione può avere al massimo una versione secondaria davanti ai suoi cluster gestiti.
Regole per le versioni di upgrade
Quando scarichi e installi una nuova versione di bmctl, puoi eseguire l'upgrade dei cluster di amministrazione, ibridi, autonomi e di amministrazione creati o aggiornati a 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 a quella di bmctl in uso. In altre parole, se utilizzi la versione 1.14.11 di bmctl, puoi eseguire l'upgrade di un cluster solo alla versione 1.14.11.
Applica patch agli upgrade delle versioni
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 versioni 1.14.X alla versione 1.14.Y, a condizione che il valore di Y sia superiore a X. Ad esempio, puoi eseguire l'upgrade da
1.13.0 a 1.13.1 e puoi eseguire l'upgrade da
1.13.1 a 1.13.3. Ti consigliamo di eseguire l'upgrade alla versione più recente della patch quando possibile per assicurarti che i cluster dispongano delle correzioni di sicurezza più recenti.
Upgrade delle versioni secondarie
Puoi eseguire l'upgrade dei cluster da una versione secondaria a quella 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.13.3 a 1.14.11.
Non puoi saltare le versioni secondarie durante l'upgrade dei cluster. Se provi a eseguire l'upgrade a una versione secondaria superiore a quella del cluster con due o più versioni secondarie, bmctl genera un errore. Ad esempio, non puoi eseguire l'upgrade di un cluster di versione 1.12.0 alla versione 1.14.0.
Un cluster di amministrazione può gestire cluster utente che si trovano nella stessa versione secondaria o in quella precedente. I cluster utente gestiti non possono avere più di una versione secondaria inferiore 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 di upgrade mostrano il processo di upgrade dalla versione 1.13.2 a GKE su Bare Metal 1.14.11.
Esegui l'upgrade dei componenti
L'upgrade dei componenti viene eseguito sia a livello di nodo che di cluster. A livello di cluster, viene eseguito l'upgrade dei seguenti componenti:
- Componenti del cluster per networking, osservabilità e archiviazione.
- Per cluster di amministrazione, 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 diversi componenti upgrade a seconda del ruolo del nodo:
| Ruolo del nodo | Funzione | Componenti di cui eseguire l'upgrade |
|---|---|---|
| Worker | Esegue i carichi di lavoro degli utenti | kubelet, runtime dei 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 Anthos | 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 Anthos 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 esegue speaker MetalLB per rivendicare indirizzi IP
virtuali |
Pod statici del bilanciatore del carico del piano di controllo (HAProxy, Keepasuspended)
Altoparlanti MetalLB |
Aspettativa di tempo di riposo
La tabella seguente descrive i tempi di inattività previsti e il potenziale impatto quando esegui l'upgrade dei cluster. Questa tabella presuppone che tu abbia più nodi del cluster e un piano di controllo ad alta disponibilità. Se esegui un cluster autonomo o non hai un piano di controllo ad alta disponibilità, prevedi tempi di inattività aggiuntivi. Se non diversamente specificato, questo tempo di inattività si applica sia agli upgrade dei cluster di amministrazione che a quelli dei cluster 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/A |
Controller del ciclo di vita e job ansible-runner (solo cluster di amministrazione) |
Zero tempi di inattività | N/A |
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 ed eseguito l'upgrade. Il tempo di riposo deve 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 networking esistenti. Deployment di DaemonSet due a due senza tempi di inattività. È stato eseguito lo 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) | Operatore 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 gestore della scalabilità automatica DNS (solo cluster utente) | CoreDNS ha più repliche con il gestore della scalabilità automatica. Generalmente nessun tempo 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 esistenti.
L'operatore potrebbe avere un tempo di inattività di 5 minuti. |
Al termine dell'upgrade dei nodi del piano di controllo. |
| Istio / Ingress | Viene eseguito lo svuotamento dell'operatore Istio e l'upgrade. Circa 5 minuti di 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 in caso di svuotamento e upgrade eseguito. | Al termine dell'upgrade dei nodi del piano di controllo. |
| Carichi di lavoro utente | Dipende dalla configurazione, ad esempio dall'alta disponibilità. 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 un upgrade del cluster utente. La sezione seguente descrive in dettaglio le deviazioni da questo flusso per gli upgrade di cluster amministrativi, ibridi o autonomi.
Il seguente diagramma mostra il processo di controllo preflight per un upgrade del cluster utente:
Il diagramma precedente descrive in dettaglio i passaggi che si verificano durante un upgrade:
- Il comando
bmctl upgrade clustercrea una risorsaPreflightCheckpersonalizzata. - Questo controllo preflight esegue controlli aggiuntivi, come quelli di upgrade del cluster, di integrità della rete e di integrità del nodo.
- I risultati di questi controlli aggiuntivi si combinano 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 di blocco, l'upgrade dei componenti nel cluster viene eseguito in un ordine specifico, 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. - Viene 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 eseguito l'upgrade del pool di nodi del bilanciatore del carico, viene eseguito l'upgrade dei pool di nodi worker.
- Una volta completato l'upgrade di tutti i componenti,
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 è stato 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 amministrativi, autonomi o ibridi. |
| 2 | status.anthosBareMetalManifestsVersion |
Versione del cluster dall'ultimo manifest applicato. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
Lo stato è stato copiato dallo stato del pool di nodi del bilanciatore del carico del piano di controllo. Questo campo è vuoto se non viene specificato un bilanciatore del carico del piano di controllo separato in Cluster.Spec. |
| 3 | status.anthosBareMetalVersions |
Una mappa aggregata delle versioni della versione ai numeri dei nodi. |
| 4 | status.anthosBareMetalVersion |
Stato finale della versione aggiornata. |
Dettagli sull'upgrade dei cluster amministrativi, ibridi e autonomi
L'upgrade di un cluster amministrativo, ibrido e autonomo in genere utilizza un cluster di bootstrap per gestire il processo. A partire da GKE su Bare Metal 1.13.0 e versioni successive, puoi eseguire l'upgrade senza un cluster di bootstrap. Solo i cluster con la versione 1.13.0 o successiva possono essere aggiornati senza un cluster di bootstrap. Le fasi dell'upgrade sono diverse a seconda del metodo utilizzato.
Per ulteriori informazioni sugli upgrade in loco, consulta Upgrade in loco per cluster autogestiti.
Con un cluster di bootstrap
La procedura di upgrade di un cluster di amministrazione, ibrido o autonomo è simile a quella 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 boot. Questo cluster di bootstrap è un cluster temporaneo che gestisce il cluster ibrido, amministrativo 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 monitorare ed eseguire il debug del processo di upgrade. È possibile accedere al cluster di bootstrap tramite bmctl-workspace/.kindkubeconfig.
Per trasferire di nuovo la proprietà della gestione del cluster al termine dell'upgrade, il cluster esegue il pivot delle risorse dal cluster di bootstrap al cluster aggiornato. Non è necessario 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.
Senza un cluster di bootstrap
GKE su Bare Metal 1.13.0 e versioni successive può eseguire l'upgrade di un cluster di amministrazione, ibrido o autonomo senza un cluster di bootstrap. Senza un cluster di bootstrap, l'esperienza di upgrade è simile a quella del cluster utente.
Il seguente diagramma mostra la differenza rispetto all'esperienza del cluster utente.
Senza un cluster di bootstrap, viene eseguito il deployment di una nuova versione di preflightcheck-operator prima dell'esecuzione del controllo preflight e dei controlli di integrità del cluster:
Come per l'upgrade del cluster utente, il processo di upgrade inizia aggiornando il campo Cluster.Spec.AnthosBareMetalVersion alla versione che preferisci.
Due passaggi aggiuntivi vengono eseguiti prima dell'aggiornamento dei componenti, come mostrato nel diagramma seguente: lifecycle-controller-manager esegue l'upgrade alla versione desiderata, quindi esegue il deployment della versione desiderata di anthos-cluster-operator. Questo anthos-cluster-operator viene riconciliato in una fase successiva del processo di upgrade:
Svuotamento dei nodi
Gli upgrade di GKE su Bare Metal potrebbero causare l'interruzione delle applicazioni durante lo svuotamento dei nodi. Questo processo di svuotamento causa l'arresto e il riavvio di tutti i pod in esecuzione su un nodo sui nodi rimanenti del cluster.
I deployment possono essere utilizzati per tollerare queste interruzioni. Un deployment può specificare più repliche di un'applicazione o di un servizio. Un'applicazione con più repliche dovrebbe subire interruzioni minime o nulle durante gli upgrade.
Budget per l'interruzione dei pod (PDB)
È possibile utilizzare i budget per l'interruzione dei pod (PDB) per garantire che un numero definito di repliche sia sempre in esecuzione nel cluster in condizioni di esecuzione normali. I PDB consentono di limitare l'interruzione di un carico di lavoro quando è necessario ripianificare i suoi 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 migliore. Alcuni pod potrebbero rimanere bloccati 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 Anthos clusters on bare metal
- Esegui l'upgrade di Anthos clusters on bare metal
- Risolvere i problemi di upgrade del cluster