Questa pagina spiega come tu e Google Kubernetes Engine (GKE) gestite le modifiche durante il ciclo di vita di un cluster per massimizzare le prestazioni e la disponibilità riducendo al minimo l'interruzione del workload.
Questa pagina è destinata agli amministratori delle piattaforme che vogliono pianificare e ottimizzare l'ambiente cluster per ridurre al minimo le interruzioni per i carichi di lavoro. Puoi leggere questa pagina prima o dopo aver imparato a eseguire le attività di gestione di base dei cluster descritte in Gestione dei cluster e Panoramica dell'amministrazione dei cluster.
Una piattaforma gestita e una responsabilità condivisa
GKE è un'implementazione gestita da Google della piattaforma di orchestrazione dei container open source Kubernetes. Come indicato in Come funziona GKE, un cluster GKE è costituito da un piano di controllo, che include nodi di gestione che eseguono componenti di sistema, e nodi worker, in cui vengono distribuiti i carichi di lavoro.
La creazione di un ambiente cluster ottimale per l'esecuzione dei tuoi workload, con prestazioni e disponibilità massime e interruzioni minime, è una responsabilità condivisa:
- La responsabilità di GKE è mantenere un ambiente cluster affidabile, disponibile, sicuro e performante. A questo scopo, GKE gestisce il piano di controllo, i componenti di sistema e, per la modalità Autopilot, i nodi worker.
- In qualità di amministratore della piattaforma, la tua responsabilità è configurare il cluster e gestire i carichi di lavoro, inclusa la preparazione alla gestione delle interruzioni. Con la modalità Standard, crei e gestisci anche i nodi worker, che sono raggruppati in node pool.
Per saperne di più, consulta la pagina relativa alla responsabilità condivisa di GKE.
Come GKE gestisce le modifiche durante il ciclo di vita di un cluster
In quanto implementazione di Kubernetes, un cluster GKE è una rete di processi e sistemi che agiscono insieme per mantenere l'ambiente ottimale per l'esecuzione dei carichi di lavoro. Per gestire il cluster, GKE esegue attività di manutenzione, apporta modifiche, avvia operazioni, aggiorna i componenti ed esegue l'upgrade della versione del control plane e dei nodi.
La maggior parte delle operazioni quotidiane della tua applicazione viene eseguita silenziosamente in background, mantenendo i tuoi carichi di lavoro in esecuzione senza interruzioni. Alcune modifiche critiche, tuttavia, devono essere completate in modi che potrebbero interrompere temporaneamente i tuoi carichi di lavoro, come descritto nella sezione successiva.
Alcune modifiche al cluster possono interrompere i carichi di lavoro
Anche se GKE si impegna a mantenere i tuoi carichi di lavoro in esecuzione senza problemi, alcuni tipi di modifiche essenziali possono richiedere interruzioni temporanee dei tuoi carichi di lavoro, principalmente modifiche che riavviano i nodi che eseguono i tuoi carichi di lavoro. Utilizzando le funzionalità di GKE e Kubernetes, puoi specificare quando e come vuoi che si verifichi l'interruzione, in modo che, quando si verifica, i tuoi carichi di lavoro possano gestire correttamente le modifiche.
Le sezioni seguenti spiegano i tipi di modifiche apportate da GKE ai cluster, il tipo di interruzione che causano e come prepararsi.
Upgrade e aggiornamenti con la gestione del ciclo di vita dei cluster GKE
In GKE, gli upgrade e gli aggiornamenti dei cluster hanno significati correlati.
In GKE, il termine upgrade dei cluster, o semplicemente upgrade, si riferisce all'aggiornamento della versione di Kubernetes del control plane (upgrade del control plane) o dei nodi (upgrade dei nodi) o di entrambi. Quando utilizzi i cluster Standard, gli upgrade dei nodi possono essere definiti anche upgrade dei node pool perché GKE utilizza una singola operazione per eseguire l'upgrade di un node pool di nodi.
Il termine aggiornamenti del cluster, o semplicemente aggiornamenti, è un termine più generale che si riferisce a qualsiasi tipo di modifica del control plane o dei nodi, incluso l'aggiornamento delle versioni. GKE gestisce attivamente l'ambiente del cluster eseguendo upgrade, altri tipi di aggiornamenti e le operazioni di manutenzione necessarie. Queste azioni garantiscono che il cluster rimanga efficiente, sicuro e aggiornato con le funzionalità e le correzioni di bug più recenti. GKE utilizza strumenti come le strategie di upgrade dei nodi e le policy di manutenzione per ridurre al minimo le interruzioni durante questi processi.
Pianificazione delle interruzioni dell'aggiornamento dei nodi
Alcuni tipi di modifiche ai cluster, principalmente modifiche ai nodi, possono causare interruzioni.
GKE utilizza strategie di upgrade dei nodi per aggiornare i nodi, sia i nodi Autopilot sia i pool di nodi del cluster standard, in modo ottimizzato per le esigenze del tuo carico di lavoro. Queste strategie si applicano agli upgrade di versione e anche ad altri tipi di modifiche ai nodi. Le strategie consentono a GKE di ridurre al minimo le interruzioni durante l'esecuzione degli aggiornamenti dei nodi, che sono importanti per mantenere i cluster funzionali e performanti.
Utilizza i periodi di manutenzione e le esclusioni per scegliere quando eseguire e non eseguire la manutenzione di alcuni cluster e, per i cluster Standard, scegli una strategia di upgrade dei nodi più adatta al tuo profilo di workload e ai vincoli delle risorse.
Per le modifiche ai nodi avviate sia manualmente sia automaticamente, GKE apporta modifiche con le seguenti caratteristiche generali:
- Le modifiche in genere rispettano le norme di manutenzione: quando GKE
apporta modifiche ai nodi, queste modifiche in genere rispettano
le norme di manutenzione
di GKE.
Tieni presente quanto segue se avvii modifiche manuali che richiedono la ricreazione di tutti i nodi di un pool di nodi:
- Per alcune modifiche, GKE rispetta le norme di manutenzione e non applica la modifica che hai inviato finché non è disponibile la manutenzione. Se GKE è in attesa della disponibilità della manutenzione e la modifica è urgente, puoi applicare manualmente le modifiche per applicare immediatamente la nuova configurazione.
- Per altre modifiche manuali, inclusi gli upgrade manuali, GKE non rispetta le policy di manutenzione. Per queste modifiche manuali, assicurati che i tuoi workload siano preparati per un'interruzione immediata.
- Le modifiche in genere utilizzano strategie di upgrade dei nodi: quando GKE applica la maggior parte delle modifiche automatiche o avviate manualmente ai nodi, inclusi gli aggiornamenti dei nodi diversi dagli upgrade di versione, GKE sceglie una strategia di upgrade dei nodi: upgrade surge o upgrade blue-green. Autopilot utilizza sempre gli upgrade dinamici. Le modifiche ai pool di nodi del cluster Standard in genere utilizzano gli upgrade inattivi, tranne quando hai configurato gli upgrade blue-green e apporti determinati tipi di modifiche.
- Le modifiche richiedono risorse sufficienti: quando GKE applica una modifica utilizzando una strategia di upgrade dei nodi, questa modifica richiede una determinata quantità di risorse a seconda della strategia e della sua configurazione. Il progetto del cluster deve disporre di una quota di risorse, una disponibilità di risorse e una capacità di prenotazione sufficienti (per i pool di nodi con affinità di prenotazione specifica). Per saperne di più, vedi Assicurarsi che le risorse per gli upgrade dei nodi siano disponibili.
Per un elenco dettagliato delle modifiche specifiche e delle loro caratteristiche, consulta Tipi di modifiche a un cluster GKE in questa pagina.
Massimizza la disponibilità del workload preparandoti a modifiche disruptive
Per massimizzare la disponibilità dei tuoi workload in esecuzione su un cluster GKE, ti consigliamo di eseguire le azioni descritte nelle sezioni seguenti:
Scegli la disponibilità del cluster
Se la disponibilità del control plane è una priorità, scegli un cluster Autopilot o un cluster Standard regionale anziché un cluster Standard a livello di zona. Per saperne di più, consulta Informazioni sulle scelte di configurazione del cluster.
Controllare gli upgrade utilizzando gli strumenti GKE
Puoi utilizzare i seguenti strumenti per controllare quando e come GKE esegue l'upgrade del cluster, consentendoti di implementare le best practice:
- Canali di rilascio: scegli un canale di rilascio per ottenere versioni del cluster con il bilanciamento che preferisci tra disponibilità e stabilità delle funzionalità.
- Periodi di manutenzione: specifica un periodo di tempo ricorrente durante il quale può essere eseguita determinati tipi di manutenzione del cluster GKE, ad esempio gli upgrade.
- Esclusioni dalla manutenzione: impedisci che la manutenzione del cluster venga eseguita per un periodo di tempo specifico.
- Strategie di upgrade dei nodi: Se utilizzi cluster standard, scegli la modalità di aggiornamento dei nodi (upgrade inattivo o blu/verde) per ridurre al minimo l'interruzione dei carichi di lavoro.
- Sequenza di implementazione: Qualifica gli upgrade in un ambiente di pre-produzione prima che GKE esegua l'upgrade dei cluster di produzione.
- Upgrade manuali: esegui l'upgrade manuale del cluster ed esegui azioni come l'annullamento, la ripresa, il rollback e il completamento degli upgrade automatici o manuali in corso.
Gestire e monitorare il cluster
Per gestire le potenziali interruzioni dei cluster, esegui continuamente le seguenti attività:
- Monitora il cluster con la suite di osservabilità di GKE.
- Segui le note di rilascio di GKE per gli annunci.
- Visualizza le notifiche del cluster, ad esempio quando gli upgrade iniziano o vengono completati, quando sono disponibili nuove versioni, i bollettini sulla sicurezza e le date di fine del supporto.
- Ottieni visibilità sugli upgrade dei cluster per comprendere lo stato degli upgrade per i tuoi cluster.
- Consulta il programma di rilascio di GKE per una stima ottimale di quando le versioni secondarie sono disponibili per gli upgrade e raggiungono la fine del supporto.
- Utilizza indicazioni prescrittive che identificano potenziali opportunità di ottimizzazione e spiegano come ottimizzare l'utilizzo del cluster, incluse indicazioni per il ritiro di funzionalità e API.
Prepara i tuoi workload
Gestisci le interruzioni rendendo i tuoi carichi di lavoro il più resilienti possibile:
- Esegui repliche dei tuoi workload per garantire la ridondanza ed evitare un singolo punto di errore.
- Specifica un budget di interruzione per la tua applicazione utilizzando un budget di interruzione dei pod.
- Imposta un periodo di tolleranza per l'interruzione della durata giusta per arrestare correttamente il carico di lavoro.
- Se il tuo workload utilizza GPU o TPU, segui le istruzioni per gestire le interruzioni dei nodi GKE per GPU e TPU.
- Per le applicazioni stateful, che spesso hanno bisogno di tempo per interrompere correttamente l'I/O e smontare lo spazio di archiviazione, segui i passaggi descritti in Assicurarsi che i carichi di lavoro stateful siano pronti per le interruzioni.
Per una discussione generale di questi argomenti, consulta la sezione Gestire le interruzioni del post del blog Best practice per GKE: operazioni day-2 per la continuità operativa.
Tipi di modifiche a un cluster GKE
Le tabelle seguenti mostrano i tipi più comuni di modifiche principali a un cluster, incluse le caratteristiche di queste modifiche, come frequenza e livello di interruzione.
Tipi di upgrade
Consulta la tabella seguente per capire in che modo gli upgrade possono interrompere un ambiente cluster.
| Cambia | Avviato automaticamente o manualmente | Rispetta le policy di manutenzione | Frequenza | Tipo di interruzione | Livello di interruzione |
|---|---|---|---|---|---|
| Upgrade del control plane | Automatico o manuale |
Gli upgrade automatici rispettano le policy di manutenzione fino alla fine del supporto, ad eccezione delle correzioni di emergenza estremamente rare, se necessario. Gli upgrade manuali non sono bloccati dalle policy di manutenzione. |
Aggiornamenti delle patch, anche ogni settimana, a seconda del canale di rilascio. Aggiornamenti minori circa ogni quattro mesi. Per i cluster del canale esteso, gli upgrade secondari vengono eseguiti solo quando la versione secondaria si avvicina alla fine del supporto. |
Piano di controllo |
Per i cluster Autopilot e Standard regionali, il control plane rimane disponibile. Per i cluster Standard zonali, più minuti in cui non puoi comunicare con il control plane, il che significa che non puoi configurare il cluster, i nodi e i carichi di lavoro durante questo periodo. |
| Upgrade del nodo | Automatico o manuale |
Gli upgrade automatici rispettano le policy di manutenzione fino alla fine del supporto, ad eccezione delle correzioni di emergenza estremamente rare, se necessario. Gli upgrade manuali non sono bloccati dalle policy di manutenzione. |
In genere, uguali a quelli del control plane. Se il cluster non è registrato in un canale di rilascio e disabiliti gli upgrade automatici dei nodi, sei responsabile dell'upgrade manuale dei pool di nodi del cluster. |
Tutti i nodi per i cluster Autopilot o uno o più node pool del cluster Standard. |
I nodi devono essere arrestati per essere ricreati e i pod devono essere sostituiti. GKE utilizza gli upgrade di sovraccarico per Autopilot o la strategia di upgrade dei nodi configurata (surge o blue-green) per i cluster Standard. |
Modifiche manuali che ricreano i nodi utilizzando una strategia di upgrade dei nodi e rispettando i criteri di manutenzione
Consulta la seguente tabella per capire in che modo queste modifiche manuali possono interrompere un ambiente cluster. Questo elenco include, tra le altre modifiche, modifiche manuali che rispettano le norme di manutenzione di GKE.
| Cambia | Avviato automaticamente o manualmente | Rispetta le policy di manutenzione | Frequenza | Tipo di interruzione | Livello di interruzione |
|---|---|---|---|---|---|
| Disattivazione della porta di sola lettura di Kubelet | Avvio manuale | Non rispetta i criteri di manutenzione, apporta immediatamente le modifiche. | Una volta per ogni modifica di questo tipo. | Tutti i nodi in un cluster Autopilot Tutti i nodi in un pool di nodi del cluster Standard. |
I nodi devono essere arrestati per essere ricreati. I pod devono essere sostituiti. GKE utilizza immediatamente gli upgrade di picco per ricreare i nodi, indipendentemente dalle policy di manutenzione attive. |
| Rotazione delle credenziali del cluster | Automatico se le credenziali del cluster scadono entro 30 giorni, può anche essere avviato manualmente. | Rispetta le policy di manutenzione. Tuttavia, GKE potrebbe ignorare le norme di manutenzione entro 30 giorni dalla scadenza delle credenziali. Entro 30 giorni, GKE ignora la disponibilità della manutenzione per il primo passaggio, ovvero l'avvio della rotazione. Inoltre, se attivi manualmente operazioni specifiche dopo il primo passaggio, l'operazione non rispetta le norme di manutenzione. | Una volta per ogni modifica manuale di questo tipo oppure dipende dalla durata delle credenziali del cluster per l'avvio automatico. Puoi richiamare manualmente le operazioni per passaggi specifici nella procedura di rotazione. | Per alcuni passaggi, il control plane. Per gli altri passaggi, tutti i nodi per i cluster Autopilot, tutti i nodi in ogni pool di nodi del cluster standard. |
Quando avvii la rotazione e la completi, il livello di interruzione è il seguente:
Quando i nodi vengono ricreati, il livello di interruzione è il seguente:
|
| Rotazione dell'indirizzo IP del control plane | Avvio manuale | Rispetta le policy di manutenzione, ma se attivi manualmente operazioni specifiche dopo il primo passaggio, l'operazione non rispetta le policy di manutenzione. | Una volta per ogni modifica manuale di questo tipo. Puoi richiamare manualmente le operazioni per passaggi specifici nella procedura di rotazione. | Per alcuni passaggi, il control plane. Per gli altri passaggi, tutti i nodi per i cluster Autopilot, tutti i nodi in ogni pool di nodi del cluster standard. |
Quando avvii la rotazione e la completi, il livello di interruzione è il seguente:
Quando i nodi vengono ricreati, il livello di interruzione è il seguente:
|
| Configurazione dei nodi schermati | Avvio manuale |
La ricreazione del control plane non rispetta i criteri di manutenzione e apporta immediatamente le modifiche. La ricreazione dei nodi rispetta le policy di manutenzione. |
Una volta per ogni modifica di questo tipo |
Il control plane viene aggiornato. Dopo l'aggiornamento del control plane, tutti i nodi in ogni pool di nodi del cluster Standard devono essere ricreati. |
Quando il control plane viene ricreato, il livello di interruzione è il seguente:
Quando i nodi vengono ricreati, il livello di interruzione è il seguente:
|
| Configurazione dei criteri di rete | Avvio manuale | Rispetta le policy di manutenzione | Una volta per ogni modifica di questo tipo | Tutti i nodi per i cluster Autopilot, tutti i nodi in ogni pool di nodi del cluster standard. |
I nodi devono essere arrestati per essere ricreati e i pod devono essere sostituiti. GKE utilizza gli upgrade inattivi per ricreare i nodi. |
| Configurazione della visibilità tra nodi | Avvio manuale | Rispetta le policy di manutenzione | Una volta per ogni modifica di questo tipo | Tutti i nodi per i cluster Autopilot, tutti i nodi in ogni pool di nodi del cluster standard. |
I nodi devono essere arrestati per essere ricreati e i pod devono essere sostituiti. GKE utilizza gli upgrade inattivi per ricreare i nodi. |
| Configurazione di NodeLocal DNSCache | Avvio manuale | Rispetta le policy di manutenzione | Una volta per ogni modifica di questo tipo | Tutti i nodi nel pool di nodi del cluster Standard in fase di aggiornamento devono essere aggiornati. |
I nodi devono essere arrestati per essere ricreati e i pod devono essere sostituiti. GKE utilizza gli upgrade inattivi per ricreare i nodi. |
| Attivare il flusso immagine | Avvio manuale |
Quando esegui l'aggiornamento a livello di cluster, rispetta le policy di manutenzione. Quando aggiorni i singoli pool di nodi, non rispetta le policy di manutenzione. |
Una volta per ogni modifica di questo tipo |
Se attivato a livello di pool di nodi, tutti i nodi nel pool di nodi del cluster standard. Se attivata a livello di cluster, i nodi di tutti i node pool del cluster Standard per i quali non hai attivato o disattivato individualmente l'impostazione per il pool di nodi. |
GKE utilizza gli upgrade inattivi per ricreare i nodi di un pool di nodi. |
Manutenzione automatica che non rispetta le policy di manutenzione
Consulta la seguente tabella per capire in che modo la manutenzione automatica che non rispetta le norme di manutenzione può interrompere un ambiente cluster.
| Cambia | Avviato automaticamente o manualmente | Rispetta le policy di manutenzione | Frequenza | Tipo di interruzione | Livello di interruzione |
|---|---|---|---|---|---|
| Riparazione o ridimensionamento del control plane | Automatico | Non rispetta le policy di manutenzione |
La frequenza di riparazione del piano di controllo è casuale, ma non ha alcun impatto sui cluster Autopilot e Standard regionali. Il ridimensionamento del control plane è raro, ma aumenta di frequenza con gli eventi di scalabilità del cluster e non ha alcun impatto per i cluster Autopilot e Standard regionali. |
Piano di controllo |
Per i cluster Autopilot e Standard regionali, il control plane rimane disponibile. Per i cluster Standard zonali, più minuti in cui non puoi comunicare con il control plane, il che significa che non puoi configurare il cluster, i nodi e i carichi di lavoro durante questo periodo. |
| Evento di manutenzione dell'host | Automatico | Non rispetta le policy di manutenzione | Per la frequenza approssimativa, consulta Eventi di manutenzione. | Un nodo |
Per la maggior parte dei tipi di nodi, l'effetto è minimo. Alcuni nodi, inclusi quelli con GPU o TPU, potrebbero subire interruzioni maggiori. Per scoprire di più, consulta Altra manutenzione Trusted Cloud by S3NS . |
| Riparazione automatica dei nodi | Automatico | Non rispetta le policy di manutenzione | La frequenza di riparazione automatica dei nodi è casuale. |
Un nodo | Il nodo viene riavviato, quindi tutti i pod in esecuzione sul nodo vengono interrotti. |
| Recuperare le VM spot e le VM prerilasciabili | Automatico | Non rispetta le policy di manutenzione |
Per le VM prerilasciabili, almeno una volta ogni 24 ore. Per le VM spot, quando Compute Engine ha bisogno delle risorse altrove. |
Un nodo | Consulta i dettagli relativi all'interruzione e all'arresto normale delle VM spot e all'interruzione e all'arresto normale delle VM preemptible. |
| Manutenzione del database dello stato del cluster basato su Spanner | Automatico | Non rispetta le policy di manutenzione | Gli eventi sono casuali e non hanno alcun impatto su cluster o carichi di lavoro. | Nessuno. Il database basato su Spanner viene eseguito separatamente dal piano di controllo e dai nodi del cluster nell'infrastruttura di Google. | Nessuno. Il database basato su Spanner viene replicato per tutti i tipi di cluster e rimane disponibile durante la manutenzione. |
Modifiche manuali che ricreano i nodi utilizzando una strategia di upgrade dei nodi senza rispettare le norme di manutenzione
Consulta la seguente tabella per capire in che modo queste modifiche manuali possono interrompere un ambiente cluster. Questo elenco include le modifiche apportate quando GKE utilizza gli upgrade surge e quando GKE utilizza gli upgrade blue-green che non sono incluse nell'altra sezione perché non rispettano le norme di manutenzione.
| Cambia | Avviato automaticamente o manualmente | Rispetta le policy di manutenzione | Frequenza | Tipo di interruzione | Livello di interruzione |
|---|---|---|---|---|---|
| Aggiornamento dell'etichetta del node pool | Avvio manuale | Non rispetta le policy di manutenzione, ma applica immediatamente le modifiche. | Una volta per ogni modifica di questo tipo | Tutti i nodi in un pool di nodi del cluster Standard | GKE utilizza immediatamente gli upgrade inattivi per ricreare il pool di nodi quando aggiorni le etichette dei nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. |
| Scalare verticalmente i nodi modificando gli attributi della macchina dei nodi | Avvio manuale | Non rispetta le policy di manutenzione, ma applica immediatamente le modifiche. | Una volta per ogni modifica di questo tipo | Tutti i nodi in un pool di nodi del cluster Standard | GKE utilizza immediatamente gli upgrade inattivi per ricreare i nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. |
| Modifiche al tipo di immagine | Avvio manuale | Non rispetta le policy di manutenzione, ma applica immediatamente le modifiche. | Una volta per ogni modifica di questo tipo | Tutti i nodi in un pool di nodi del cluster Standard |
I nodi devono essere arrestati per essere ricreati e i pod devono essere sostituiti. GKE utilizza la strategia di upgrade dei nodi configurata (surge o blu/verde) per i cluster Standard. |
| Aggiungere o sostituire i pool di archiviazione in un node pool del cluster Standard | Avvio manuale | Non rispetta le policy di manutenzione, ma applica immediatamente le modifiche. | Una volta per ogni modifica di questo tipo | Tutti i nodi in un pool di nodi del cluster Standard |
I nodi devono essere arrestati per essere ricreati e i pod devono essere sostituiti. GKE utilizza la strategia di upgrade dei nodi configurata (surge o blu/verde) per i cluster Standard. |
| Attivare il flusso immagine | Avvio manuale |
Quando esegui l'aggiornamento a livello di cluster, rispetta le policy di manutenzione. Quando aggiorni i singoli pool di nodi, non rispetta le policy di manutenzione. |
Una volta per ogni modifica di questo tipo |
Se attivato a livello di pool di nodi, tutti i nodi nel pool di nodi del cluster standard. Se attivata a livello di cluster, i nodi di tutti i node pool del cluster Standard per i quali non hai attivato o disattivato individualmente l'impostazione per il pool di nodi. |
GKE utilizza gli upgrade inattivi per ricreare i nodi di un pool di nodi. |
| Aggiornamenti della configurazione delle prestazioni di rete | Avvio manuale | Non rispetta le policy di manutenzione, ma applica immediatamente le modifiche. | Una volta per ogni modifica di questo tipo | Tutti i nodi in un pool di nodi del cluster Standard |
I nodi devono essere arrestati per essere ricreati e i pod devono essere sostituiti. GKE utilizza immediatamente gli upgrade inattivi per ricreare i nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. |
| Attivazione di gVNIC | Avvio manuale | Non rispetta le policy di manutenzione, ma applica immediatamente le modifiche. | Una volta per ogni modifica di questo tipo | Tutti i nodi in un pool di nodi del cluster Standard |
I nodi devono essere arrestati per essere ricreati e i pod devono essere sostituiti. GKE utilizza immediatamente gli upgrade inattivi per ricreare i nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. |
| Modifiche alla configurazione del sistema di nodi | Avvio manuale | Non rispetta le policy di manutenzione, ma applica immediatamente le modifiche. | Una volta per ogni modifica di questo tipo | Tutti i nodi in un pool di nodi del cluster Standard |
I nodi devono essere arrestati per essere ricreati e i pod devono essere sostituiti. GKE utilizza immediatamente gli upgrade inattivi per ricreare i nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. |
| Nodi riservati | Avvio manuale | Non rispetta le policy di manutenzione, ma applica immediatamente le modifiche. | Una volta per ogni modifica di questo tipo | Tutti i nodi in un pool di nodi del cluster Standard |
I nodi devono essere arrestati per essere ricreati e i pod devono essere sostituiti. GKE utilizza immediatamente gli upgrade inattivi per ricreare i nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. |
Modifiche che non richiedono la ricreazione dei nodi
Consulta la tabella seguente per capire quali modifiche alla configurazione dei nodi non richiedono la ricreazione dei nodi. Queste modifiche non sono distruttive, tuttavia l'interruzione è comunque possibile se la configurazione del nodo aggiornata influisce sul tuo carico di lavoro.
| Cambia | Avviato automaticamente o manualmente | Rispetta le policy di manutenzione | Frequenza | Tipo di interruzione | Livello di interruzione |
|---|---|---|---|---|---|
|
Aggiorna le seguenti impostazioni:
|
Avvio manuale | Non rispetta le policy di manutenzione, ma applica immediatamente le modifiche. | Una volta per ogni modifica di questo tipo | Tutti i nodi pertinenti vengono aggiornati. | I pod non devono essere sostituiti perché la configurazione del nodo viene aggiornata senza ricreare i nodi. |
Passaggi successivi
- Panoramica di GKE
- Architettura del cluster GKE
- Responsabilità condivisa di GKE
- Controllo delle versioni e assistenza di GKE
- Accordo sul livello del servizio di GKE
- Upgrade dei cluster GKE