I cluster Servizio TKG supportano un modello di aggiornamento in sequenza. È possibile avviare un aggiornamento in sequenza modificando la specifica del cluster. Alcune operazioni di sistema possono avviare un aggiornamento in sequenza. Prima di aggiornare l'ambiente, è necessario familiarizzare con il processo dell'aggiornamento in sequenza.
Modello di aggiornamento in sequenza per i cluster TKGS successivi a Servizio TKG 3.0
A partire Servizio TKG 3.0, il controller TKG è indipendente da vCenter Server e Supervisore. Vedere Utilizzo della Servizio TKG. Se si aggiornano questi componenti, non verrà avviato un aggiornamento in sequenza dei cluster TKGS.
L'aggiornamento della versione di Servizio TKG potrebbe attivare un aggiornamento in sequenza dei cluster TKGS.
Modello di aggiornamento in sequenza per i cluster TKGS precedenti a Servizio TKG 3.0
Il controller TKG viene eseguito nel Supervisore. Quando si aggiorna il Supervisore, il controller TKG viene aggiornato automaticamente se è disponibile un aggiornamento. Ogni aggiornamento del controller TKG può includere aggiornamenti per i servizi di supporto, ad esempio CNI, CSI, CPI, nonché aggiornamenti della configurazione per i cluster. Per supportare la compatibilità, il sistema esegue controlli preliminari e impone la conformità.
vSphere IaaS control plane utilizza un modello di aggiornamento in sequenza per i cluster TKG nel Supervisore. Il modello di aggiornamento in sequenza garantisce un tempo di inattività minimo durante il processo di aggiornamento del cluster. Gli aggiornamenti in sequenza includono l'aggiornamento delle versioni del software Kubernetes e l'infrastruttura e i servizi che supportano i cluster, come le configurazioni e le risorse delle macchine virtuali, i servizi e gli spazi dei nomi, nonché le risorse personalizzate. Affinché l'aggiornamento venga eseguito correttamente, la configurazione deve soddisfare diversi requisiti di compatibilità. Il sistema applica quindi le condizioni di ricontrollo per assicurarsi che i cluster siano pronti per gli aggiornamenti e supporta il rollback se l'upgrade del cluster non riesce.
È possibile avviare un aggiornamento in sequenza di un cluster TKG modificando alcuni aspetti del manifesto del cluster. Un aggiornamento in sequenza del cluster può essere avviato anche dal sistema. Ad esempio, quando viene eseguito un aggiornamento Spazi dei nomi vSphere, il sistema propaga immediatamente le configurazioni aggiornate a tutti i cluster del carico di lavoro. Questi aggiornamenti possono attivare un aggiornamento in sequenza dei nodi del cluster. Inoltre, una modifica a uno qualsiasi degli elementi di configurazione può avviare un aggiornamento in sequenza. Ad esempio, se si rinomina o si sostituisce VirtualMachineImage corrispondente a una versione di distribuzione, viene avviato un aggiornamento in sequenza man mano che il sistema tenta di avviare l'esecuzione di tutti i nodi nella nuova immagine. Inoltre, l'aggiornamento di un Supervisore attiverà probabilmente un aggiornamento in sequenza dei cluster del carico di lavoro distribuiti nel cluster. Ad esempio, quando vmware-system-tkg-controller-manager viene aggiornato, il sistema introduce nuovi valori nel generatore di manifesti e il controller avvia un aggiornamento in sequenza per distribuire tali valori.
Il processo di aggiornamento in sequenza per la sostituzione dei nodi del cluster è simile al processo di aggiornamento in sequenza dei pod in una distribuzione Kubernetes. Sono disponibili due controller distinti responsabili dell'esecuzione di un aggiornamento in sequenza dei cluster del carico di lavoro: il controller dei componenti aggiuntivi e il controller del cluster. All'interno di questi due controller sono presenti tre fasi chiave per un aggiornamento in sequenza: aggiornamento dei componenti aggiuntivi, aggiornamento del piano di controllo e aggiornamento dei nodi di lavoro. Queste fasi vengono eseguite in ordine e le verifiche preliminari impediscono l'inizio di un passaggio finché quello precedente non è sufficientemente avanzato. Questi passaggi possono essere ignorati se si stabilisce che non sono necessari. Ad esempio, un aggiornamento può influire solo sui nodi worker e pertanto non richiede alcun aggiornamento dei componenti aggiuntivi o dei piani di controllo.
Durante il processo di aggiornamento, il sistema aggiunge un nuovo nodo di cluster e attende che il nodo passi online con la versione di Kubernetes di destinazione. Il sistema contrassegna quindi il vecchio nodo per l'eliminazione, passa al nodo successivo e ripete il processo. Il vecchio nodo non viene eliminato finché non vengono rimossi tutti i pod. Ad esempio, se un pod viene definito con PodDisruptionBudgets che impedisce lo svuotamento completo di un nodo, il nodo viene isolato ma non viene rimosso finché non sarà possibile eliminare tale pod. Il sistema esegue innanzitutto l'upgrade di tutti i nodi del piano di controllo e quindi dei nodi worker. Durante un aggiornamento, lo stato del cluster diventa "aggiornamento in corso". Al termine del processo di aggiornamento in sequenza, lo stato del cluster diventa "in esecuzione".
I pod in esecuzione in un cluster non gestiti da un controller di replica verranno eliminati durante un aggiornamento della versione di Kubernetes come parte dello svuotamento del nodo di lavoro durante l'aggiornamento del cluster. Questo succede se l'aggiornamento del cluster viene attivato manualmente o automaticamente da un aggiornamento degli spazi dei nomi di vSphere o Supervisore. I pod non gestiti da un controller di replica includono i pod che non vengono creati come parte di una specifica Deployment o ReplicaSet. Per ulteriori informazioni, fare riferimento a Pod Lifecycle: Pod lifetime nella documentazione di Kubernetes.
Aggiornamenti in sequenza avviati dall'utente
Aggiornamenti in sequenza avviati dal sistema
- kubeadmcontrolplanetemplate/kubeadmcontrolplane
- kubeadmconfigtemplate/kubeadmconfig
- vspheremachinetemplate/vspheremachine (per vSphere 8.x)
- wcpmachinetemplate/wcpmachine (per vSphere 7.x)
In vSphere IaaS control plane, il controller TKG eseguito in Supervisore genera questi oggetti e li tiene sincronizzati con il codice di sistema. Questo significa che quando i controller vengono aggiornati al codice più recente, le modifiche apportate a uno qualsiasi degli oggetti precedenti causano un aggiornamento in sequenza dei cluster TKG esistenti. In breve, le modifiche del codice di sistema che influiscono su Supervisore comportano aggiornamenti in sequenza dei cluster TKG.
| Scenario di aggiornamento | Descrizione |
|---|---|
| Aggiornamento da una versione 7.x di vCenter Server a una versione qualsiasi di vCenter Server | Potrebbe attivare un aggiornamento in sequenza di tutti i cluster Tanzu Kubernetes. Un aggiornamento in sequenza viene attivato dal primo aggiornamento di Supervisore in seguito a un aggiornamento di vCenter Server. Un aggiornamento in sequenza in genere non viene attivato da un aggiornamento di Supervisore nello stesso vCenter Server. Per informazioni specifiche dettagliate, consultare le note di rilascio. |
| Aggiornamento da una qualsiasi versione di vCenter Server a una versione 8.x di vCenter Server | Attiverà un aggiornamento in sequenza di tutti i cluster TKG perché è necessario propagare le seguenti modifiche del codice:
|
| Aggiornamento dalla versione vCenter Server 8.0 GA (8.0.0) alle versioni vCenter Server 8.0.0b o 8.0.0c | Attiverà un aggiornamento in sequenza dei cluster TKG specificati se si verifica uno dei casi seguenti:
|
| Aggiornamento da vSphere 8.0.0b a vSphere 8.0.0c | Nessun rollout automatico dei cluster del carico di lavoro |
| Aggiornamento da vSphere 8.0.0c a vSphere 8.0 Update 1 (8.0.1) | Nessun rollout automatico dei cluster del carico di lavoro |
| Aggiornamento da qualsiasi versione 8.x di vSphere alla versione 8.0 U2 (8.0.2). | Ciò causerà un aggiornamento in sequenza di tutti i TKC poiché devono essere apportate le seguenti modifiche:
|
| Aggiornamento da qualsiasi versione vSphere 8.x precedente alla versione 8.0 U2 (8.0.2) alla versione 8.0 U2c | Ciò causerà un aggiornamento in sequenza di tutti i TKC poiché devono essere apportate le seguenti modifiche:
|
Si consideri ad esempio uno scenario in cui si utilizza una libreria di contenuti con sottoscrizione che usa automaticamente i nomi OVA definiti dal sistema. Si passa quindi a una libreria di contenuti locale e la si popola con gli stessi OVA ma assegnando loro nomi diversi. Ciò attiverà un aggiornamento in sequenza di tutti i cluster TKG perché la libreria di contenuti sostitutiva ha gli stessi OVA ma con nomi diversi definiti dall'utente.
Considerazioni sull'aggiornamento in sequenza per i cluster con più pool di nodi
- Pool di nodi di lavoro
-
I pool di nodi di lavoro sono stati introdotti con l'API TKGS v1alpha2, rilasciata con vSphere 7 U3. I MachineDeployments dell'API del cluster è la primitiva Kubernetes sottostante dei pool di nodi di lavoro.
ClusterClass è stato introdotto con la versione vSphere 8 di TKGS. Entrambe le API v1alpha3 e v1beta1 si basano su ClusterClass (v1alpha3 è un livello di astrazione sopra ClusterClass).
- Modalità di aggiornamento di più pool di nodi durante l'aggiornamento in sequenza
-
Quando si aggiorna un cluster del carico di lavoro TKGS sottoposto a provisioning con più pool di nodi, il modello di aggiornamento in sequenza varia in base alla versione di vSphere utilizzata.
vSphere API TKGS Comportamento di aggiornamento TKG vSphere 7 API v1alpha2 Più pool di nodi all'interno dello stesso cluster vengono aggiornati contemporaneamente (simultaneamente) TKG vSphere 8 API v1alpha3 e API v1beta1 Più pool di nodi all'interno dello stesso cluster vengono aggiornati seguendo un ordine logico (in sequenza)
- Considerazioni sulle procedure consigliate
-
Il provisioning di un cluster TKGS vSphere 8 con più pool di nodi identici non ha alcuno scopo in termini di dimensionamento. I pool di nodi devono essere utilizzati per dimensioni diverse, classi di macchine virtuali, versioni di TKr e così via. Evitare di utilizzare più pool di nodi identici per giocare con il sistema e aggiornare i cluster più rapidamente perché non funzionerà.
I budget per le interruzioni dei pod sono il modo corretto per assicurarsi che gli aggiornamenti non interferiscano con le applicazioni in esecuzione. Il modo migliore per gestire questa operazione consiste nell'impostare PodDisruptionBudgets sui carichi di lavoro (vedere https://kubernetes.io/docs/tasks/run-application/configure-pdb/). L'API del cluster rispetta questi criteri e non terminerà una macchina se le soglie vengono superate.
- Dettagli sull'aggiornamento in sequenza per i cluster TKGS 8 vSphere
-
Durante un aggiornamento della versione del cluster TKGS 8 vSphere:
- i nodi del piano di controllo vengono aggiornati per primi, quindi viene eseguito il rollback di un nodo di lavoro alla volta a partire dal pool di nodi Zona A. Se vengono utilizzati due pool di nodi, verrà eseguito il rollout di un solo nodo di lavoro alla volta.
