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à e ridurre al minimo l'interruzione del carico di lavoro.
Questa pagina è destinata agli amministratori della piattaforma che vogliono pianificare e ottimizzare l'ambiente del cluster per ridurre al minimo le interruzioni dei workload. 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 control plane, che include i nodi di gestione che eseguono i componenti di sistema, e dai nodi worker, in cui esegui il deployment dei workload.
La creazione di un ambiente cluster ottimale per l'esecuzione dei 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 control plane, 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 maggiori informazioni, consulta 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 tuoi workload. 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 workload 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 ai cluster possono causare interruzioni dei workload
Anche se GKE si impegna a mantenere i tuoi workload in esecuzione senza problemi, alcuni tipi essenziali di modifiche possono richiedere interruzioni temporanee dei tuoi workload, principalmente modifiche che riavviano i nodi che eseguono i tuoi workload. 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 che GKE apporta ai cluster, il tipo di interruzione che causano e come puoi prepararti.
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 del 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 del 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 relative 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 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 workload. 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 manualmente e automaticamente, GKE apporta modifiche con le seguenti caratteristiche generali:
Le modifiche in genere rispettano le policy di manutenzione: quando GKE apporta modifiche ai nodi, queste modifiche in genere rispettano le policy di manutenzione di GKE. Alcune eccezioni includono la manutenzione dell'host per determinati tipi di nodi, ad esempio quelli con GPU e TPU.
Tieni presente quanto segue se avvii modifiche manuali che richiedono la ricreazione di tutti i nodi in un pool di nodi:
- Per alcune modifiche, GKE rispetta i criteri di manutenzione e non applica la modifica inviata finché non è disponibile la manutenzione. Se GKE è in attesa della disponibilità per la 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, upgrade blue-green o blue-green con scalabilità automatica (anteprima). Autopilot utilizza sempre gli upgrade di picco. Le modifiche ai node pool dei cluster Standard in genere utilizzano gli upgrade di sovraccarico, tranne quando hai configurato gli upgrade blu/verde o blu/verde con scalabilità automatica ed esegui determinati tipi di modifiche. Per saperne di più su quale strategia è configurata per un pool di nodi, consulta Esamina le impostazioni di upgrade di un node pool.
Le modifiche richiedono risorse sufficienti: quando GKE applica una modifica utilizzando una strategia di upgrade dei nodi, questa modifica richiede una certa quantità di risorse a seconda della strategia e della sua configurazione. Il progetto del cluster deve disporre di una quota di risorse, una disponibilità delle risorse e una capacità di prenotazione sufficienti (per i pool di nodi con affinità di prenotazione specifica). Per saperne di più, consulta Garantisci le risorse per gli upgrade dei nodi.
Per un elenco dettagliato delle modifiche specifiche e delle relative caratteristiche, consulta Tipi di modifiche a un cluster GKE in questa pagina.
Massimizzare la disponibilità dei workload preparandosi a modifiche disruptive
Per massimizzare la disponibilità dei workload in esecuzione su un cluster GKE, ti consigliamo di intraprendere 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 a livello di regione anziché un cluster Standard a livello di zona. Per saperne di più, consulta Informazioni sulle scelte di configurazione del cluster.
Controlla 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 le versioni del cluster con il bilanciamento scelto tra disponibilità e stabilità delle funzionalità.
- Periodi di manutenzione: specifica un periodo di tempo ricorrente in cui possono essere eseguiti determinati tipi di manutenzione del cluster GKE, ad esempio gli upgrade.
- Esclusioni dalla manutenzione: impediscono l'esecuzione della manutenzione del cluster per un periodo di tempo specifico.
- Budget di interruzione dei cluster: personalizza l'intervallo di tempo minimo tra tipi specifici di upgrade del cluster, inclusi upgrade di patch o secondari.
- Strategie di upgrade dei nodi: se utilizzi un pool di nodi Standard, scegli come aggiornare i nodi (upgrade di sovraccarico, blu/verde o blu/verde con scalabilità automatica (anteprima)) per ridurre al minimo l'interruzione dei carichi di lavoro. Inoltre, scegli quanti node pool GKE aggiorna automaticamente contemporaneamente in un cluster.
- 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 annullare, riprendere, eseguire il rollback e completare gli 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.
- Visualizza gli upgrade dei cluster per comprendere lo stato degli upgrade dei tuoi cluster.
- Consulta la pianificazione delle release 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 i ritiri di funzionalità e API.
Prepara i tuoi workload
Gestisci le interruzioni rendendo i tuoi workload il più resilienti possibile:
- Esegui repliche dei tuoi workload per garantire la ridondanza ed evitare un single point of failure.
- Specifica un budget di interruzione per la tua applicazione utilizzando un budget di interruzione dei pod.
- Imposta un periodo di tolleranza per l'arresto della durata corretta per consentire l'arresto controllato del workload.
- 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 l'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 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 la frequenza e il livello di interruzione.
Tipi di upgrade
Consulta la seguente tabella 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 di correzioni di emergenza estremamente rare, se necessario. Gli upgrade manuali non sono bloccati dalle policy di manutenzione. |
Upgrade delle patch, anche ogni settimana, a seconda del canale di rilascio. Upgrade minori ogni quattro mesi circa. Per i cluster canale esteso, gli upgrade secondari vengono eseguiti solo quando la versione secondaria si avvicina alla fine del supporto. |
Control plane |
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 di correzioni di emergenza estremamente rare, se necessario. Gli upgrade manuali non sono bloccati dalle policy di manutenzione. |
In genere, è uguale agli upgrade 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ù pool di nodi 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 (sovraccarico, blu/verde o blu/verde con scalabilità automatica (anteprima)) 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 |
|---|---|---|---|---|---|
| Disabilitazione della porta di sola lettura di Kubelet | Avvio manuale | Non rispetta le norme 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. |
Per essere ricreati, i nodi devono essere arrestati. I pod devono essere sostituiti. GKE utilizza immediatamente gli upgrade con capacità aggiuntiva per ricreare i nodi, indipendentemente dalle policy di manutenzione attive. GKE utilizza gli upgrade di sovraccarico indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| 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 policy 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 nel processo 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 nel processo 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 | Avviato manualmente |
La ricreazione del control plane non rispetta le policy di manutenzione e apporta immediatamente le modifiche. La ricreazione dei nodi rispetta le policy di manutenzione. |
Una volta per 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 delle policy 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, i pod devono essere sostituiti. GKE utilizza gli upgrade di picco per ricreare i nodi. GKE utilizza gli upgrade con capacità aggiuntiva indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| 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, i pod devono essere sostituiti. GKE utilizza gli upgrade di picco per ricreare i nodi. GKE utilizza gli upgrade di sovraccarico indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| 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 di picco per ricreare i nodi. GKE utilizza gli upgrade con capacità aggiuntiva indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Attivazione dello streaming di immagini | Avviato manualmente |
Quando esegui l'aggiornamento a livello di cluster, rispetta le policy di manutenzione. Quando aggiorni singoli node pool, 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 in cui non hai attivato o disattivato individualmente l'impostazione per il pool di nodi. |
GKE utilizza gli upgrade di sovraccarico per ricreare i nodi di un pool di nodi. GKE utilizza gli upgrade di sovraccarico indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
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 policy 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 control plane è casuale, ma non ha alcun impatto sui cluster Autopilot e Standard a livello di regione. Il ridimensionamento del control plane è poco frequente, ma aumenta di frequenza con gli eventi di scalabilità del cluster e non ha alcun impatto sui cluster Autopilot e Standard a livello di regione. |
Control plane |
Per i cluster Autopilot e Standard regionali, il control plane rimane disponibile. Per i cluster Standard di zona, diversi minuti in cui non puoi comunicare con il control plane, il che significa che non puoi configurare il cluster, i nodi e i workload 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 saperne di più, consulta Altra Google Cloud manutenzione. |
| 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 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 preemptible, 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 workload. | Nessuno. Il database basato su Spanner viene eseguito separatamente dal control plane 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 policy 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 con capacità aggiuntiva e quando GKE utilizza gli upgrade blu-verde che non sono incluse nell'altra sezione perché non rispettano le policy di manutenzione.
| Cambia | Avviato automaticamente o manualmente | Rispetta le policy di manutenzione | Frequenza | Tipo di interruzione | Livello di interruzione |
|---|---|---|---|---|---|
| Modifiche alla raccolta dei log del control plane | Avvio manuale | Non rispetta le norme di manutenzione, ma apporta immediatamente le modifiche. | Una volta per modifica di questo tipo | Il control plane viene aggiornato. | Quando il control plane viene ricreato, il livello di interruzione è il seguente:
|
| Aggiornamento dell'etichetta del node pool | Avviato manualmente | Non rispetta le norme di manutenzione, ma apporta 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 di sovraccarico per ricreare il pool di nodi quando aggiorni le etichette dei nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. GKE utilizza gli upgrade di sovraccarico indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Scalare verticalmente i nodi modificando gli attributi della macchina dei nodi | Avvio manuale | Non rispetta le norme di manutenzione, ma apporta immediatamente le modifiche. | Una volta per ogni modifica di questo tipo | Tutti i nodi in un pool di nodi di un cluster Standard | GKE utilizza immediatamente gli upgrade con capacità aggiuntiva per ricreare i nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. GKE utilizza gli upgrade di sovraccarico indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Modifiche al tipo di immagine | Avvio manuale | Non rispetta le norme di manutenzione, ma apporta 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, blu/verde o blu/verde con scalabilità automatica (anteprima)) per i cluster Standard. |
| Aggiungere o sostituire i pool di archiviazione in un node pool del cluster Standard | Avviato manualmente | Non rispetta le norme di manutenzione, ma apporta 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, blu/verde o blu/verde con scalabilità automatica (anteprima)) per i cluster Standard. |
| Attivare lo streaming di immagini | Avvio manuale |
Quando esegui l'aggiornamento a livello di cluster, rispetta le policy di manutenzione. Quando aggiorni singoli node pool, 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 in cui non hai attivato o disattivato individualmente l'impostazione per il pool di nodi. |
GKE utilizza gli upgrade con capacità aggiuntiva per ricreare i nodi di un pool di nodi. GKE utilizza gli upgrade di sovraccarico indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Aggiornamenti della configurazione delle prestazioni di rete | Avvio manuale | Non rispetta le norme di manutenzione, ma apporta 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, i pod devono essere sostituiti. GKE utilizza immediatamente gli upgrade di sovraccarico per ricreare i nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. GKE utilizza gli upgrade con capacità aggiuntiva indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Attivazione di gVNIC | Avvio manuale | Non rispetta le norme di manutenzione, ma apporta 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, i pod devono essere sostituiti. GKE utilizza immediatamente gli upgrade di sovraccarico per ricreare i nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. GKE utilizza gli upgrade con capacità aggiuntiva indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Modifiche alla configurazione del sistema dei nodi | Avvio manuale | Non rispetta le norme di manutenzione, ma apporta 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, i pod devono essere sostituiti. GKE utilizza immediatamente gli upgrade di sovraccarico per ricreare i nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. GKE utilizza gli upgrade di sovraccarico indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Nodi riservati | Avvio manuale | Non rispetta le norme di manutenzione, ma apporta 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, i pod devono essere sostituiti. GKE utilizza immediatamente gli upgrade con capacità aggiuntiva per ricreare i nodi in un pool di nodi esistente, indipendentemente dalle policy di manutenzione attive. GKE utilizza gli upgrade di sovraccarico indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
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, ma 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 norme di manutenzione, ma apporta immediatamente le modifiche. | Una volta per 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