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 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 appreso come 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 con prestazioni elevate. Per farlo, 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 workload, inclusa la loro preparazione per gestire le 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.
In che modo 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 dell'applicazione avviene silenziosamente in background, mantenendo i workload in esecuzione senza interruzioni. Tuttavia, alcune modifiche critiche devono essere completate in modi che potrebbero interrompere temporaneamente i workload, come descritto nella sezione successiva.
Alcune modifiche ai cluster possono causare interruzioni dei workload
Sebbene GKE si impegni a mantenere i tuoi workload in esecuzione senza problemi, alcuni tipi di modifiche essenziali possono richiedere interruzioni temporanee dei workload, principalmente modifiche che riavviano i nodi che eseguono i 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 workload 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 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 anche essere definiti upgrade dei node pool perché GKE utilizza un'unica 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 performante, 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 degli aggiornamenti dei nodi
Alcuni tipi di modifiche ai cluster, per lo più modifiche ai nodi, possono causare interruzioni.
GKE utilizza strategie di upgrade dei nodi per aggiornare i nodi, sia i nodi Autopilot sia i node pool dei 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 con prestazioni elevate.
Utilizza i periodi di manutenzione e le esclusioni per scegliere quando eseguire o meno la manutenzione del cluster e, per i cluster Standard, scegli una strategia di upgrade dei nodi che meglio si adatta al profilo del workload e ai vincoli delle risorse.
Sia per le modifiche ai nodi avviate manualmente che per quelle avviate 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 le policy di manutenzione e non applica la modifica inviata 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 generalmente utilizzano strategie di aggiornamento dei nodi: Quando GKE applica la maggior parte delle modifiche automatiche o avviate manualmente ai nodi, inclusi gli aggiornamenti dei nodi diversi dagli aggiornamenti di versione, GKE sceglie una strategia di aggiornamento dei nodi: aggiornamenti di picco, aggiornamenti blue-green o blue-green autoscaled (Anteprima). Autopilot utilizza sempre gli upgrade surge. 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ù sulla 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 relativa 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 ulteriori informazioni, 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.
Massimizza la disponibilità dei workload preparandoti a modifiche che causano interruzioni
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, in modo da 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 dei 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 dei 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 workload. Inoltre, scegli il numero di pool di nodi di cui GKE esegue automaticamente l'upgrade 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 l'annullamento, la ripresa, il rollback e il completamento degli upgrade automatici o manuali in corso.
Gestisci e monitora il tuo 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 iniziano o terminano gli upgrade, 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 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 le indicazioni prescrittive che identificano potenziali opportunità di ottimizzazione e spiegano come ottimizzare l'utilizzo del cluster, incluse le indicazioni per il ritiro di funzionalità e API.
Prepara i 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'interruzione della durata corretta per 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 richiedono tempo per arrestare correttamente l'I/O e smontare lo spazio di archiviazione, segui i passaggi descritti in Assicurati che i workload stateful siano pronti per le interruzioni.
Per una discussione generale di questi argomenti, consulta la sezione Gestisci le interruzioni del blog post Best practice per GKE: operazioni day-2 per la business continuity.
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 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 di correzioni di emergenza estremamente rare, se necessario. Gli upgrade manuali non sono bloccati dalle policy di manutenzione. |
Upgrade delle patch, con frequenza settimanale, a seconda del canale di rilascio. Upgrade minori ogni quattro mesi circa. Per i cluster del 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 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. |
| Upgrade dei nodi | 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, sono uguali agli upgrade del control plane. Se il tuo cluster non è registrato in un canale di rilascio e disattivi gli upgrade automatici dei nodi, sei responsabile dell'upgrade manuale dei node pool del cluster. |
Tutti i nodi per i cluster Autopilot o uno o più pool di nodi dei cluster Standard. |
I nodi devono essere arrestati per essere ricreati, i pod devono essere sostituiti. GKE utilizza gli upgrade surge per Autopilot o la strategia di upgrade dei nodi configurata (surge, 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 le policy di manutenzione
Consulta la tabella seguente 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 policy 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 | Avviato manualmente | Non rispetta le policy 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 di un cluster Standard. |
I nodi devono essere arrestati per essere ricreati. I pod devono essere sostituiti. GKE utilizza immediatamente gli upgrade di surge 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 eseguire l'override delle policy 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 modifica manuale di questo tipo o dipende dalla durata delle credenziali del cluster per l'avvio automatico. Puoi richiamare manualmente le operazioni per passaggi specifici del 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 dei 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 | Avviato manualmente | 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 del 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 dei 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 è 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 | Avviato manualmente | Rispetta le policy di manutenzione | Una volta per modifica di questo tipo | Tutti i nodi per i cluster Autopilot, tutti i nodi in ogni pool di nodi di cluster Standard. |
I nodi devono essere arrestati per essere ricreati, i pod devono essere sostituiti. GKE utilizza gli upgrade di surge per ricreare i nodi. GKE utilizza gli upgrade di surge indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Configurazione della visibilità tra nodi | Avviato manualmente | Rispetta le policy di manutenzione | Una volta per modifica di questo tipo | Tutti i nodi per i cluster Autopilot, tutti i nodi in ogni pool di nodi di cluster Standard. |
I nodi devono essere arrestati per essere ricreati, i pod devono essere sostituiti. GKE utilizza gli upgrade di surge 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 | Avviato manualmente | Rispetta le policy di manutenzione | Una volta per 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, i pod devono essere sostituiti. GKE utilizza gli upgrade di surge per ricreare i nodi. GKE utilizza gli upgrade di surge indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Attivazione di Image Streaming | Avviato manualmente |
Durante l'aggiornamento a livello di cluster, rispetta le policy di manutenzione. Durante l'aggiornamento dei singoli pool di nodi, non rispetta le policy di manutenzione. |
Una volta per modifica di questo tipo |
Se l'opzione è attivata a livello di pool di nodi, tutti i nodi nel pool di nodi del cluster Standard. Se l'opzione è attivata a livello di cluster, i nodi di qualsiasi node pool di cluster Standard in cui non hai attivato o disattivato singolarmente 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 surge 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 tabella seguente 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 è raro, ma aumenta di frequenza con gli eventi di scalabilità dei 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 | Consulta Eventi di manutenzione per la frequenza approssimativa. | 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 Altre Google Cloud manutenzioni. |
| 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. |
| Recupera le VM spot e le VM preemptible | 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 sulla terminazione e l'arresto normale delle VM spot e sulla terminazione e l'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 tabella seguente 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 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 | Avviato manualmente | Non rispetta le policy di manutenzione, apporta immediatamente le modifiche. | Una volta per modifica di questo tipo | Il control plane è aggiornato. | Quando il control plane viene ricreato, il livello di interruzione è il seguente:
|
| Aggiornamento dell'etichetta del node pool | Avviato manualmente | Non rispetta le policy di manutenzione, apporta immediatamente le modifiche. | Una volta per modifica di questo tipo | Tutti i nodi in un pool di nodi di un 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 surge indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Scalabilità verticale dei nodi modificando gli attributi della macchina dei nodi | Avviato manualmente | Non rispetta le policy di manutenzione, apporta immediatamente le modifiche. | Una volta per modifica di questo tipo | Tutti i nodi in un pool di nodi di un cluster Standard | 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 surge indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Modifiche al tipo di immagine | Avviato manualmente | Non rispetta le policy di manutenzione, apporta immediatamente le modifiche. | Una volta per modifica di questo tipo | Tutti i nodi in un pool di nodi di un cluster Standard |
I nodi devono essere arrestati per essere ricreati, 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. |
| Aggiungi o sostituisci i pool di archiviazione in un node pool di un cluster Standard | Avviato manualmente | Non rispetta le policy di manutenzione, apporta immediatamente le modifiche. | Una volta per modifica di questo tipo | Tutti i nodi in un pool di nodi di un cluster Standard |
I nodi devono essere arrestati per essere ricreati, 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. |
| Attivazione di Image Streaming | Avviato manualmente |
Durante l'aggiornamento a livello di cluster, rispetta le policy di manutenzione. Durante l'aggiornamento dei singoli pool di nodi, non rispetta le policy di manutenzione. |
Una volta per modifica di questo tipo |
Se l'opzione è attivata a livello di pool di nodi, tutti i nodi nel pool di nodi del cluster Standard. Se l'opzione è attivata a livello di cluster, i nodi di qualsiasi node pool di cluster Standard in cui non hai attivato o disattivato singolarmente 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 surge 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 | Avviato manualmente | Non rispetta le policy di manutenzione, apporta immediatamente le modifiche. | Una volta per modifica di questo tipo | Tutti i nodi in un pool di nodi di un 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 surge indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Attivazione di gVNIC | Avviato manualmente | Non rispetta le policy di manutenzione, apporta immediatamente le modifiche. | Una volta per modifica di questo tipo | Tutti i nodi in un pool di nodi di un 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 surge 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 (utilizzando la strategia di upgrade standard) | Avviato manualmente | Non rispetta le policy di manutenzione, apporta immediatamente le modifiche. | Una volta per modifica di questo tipo | Tutti i nodi in un pool di nodi di un 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 surge indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
| Nodi riservati | Avviato manualmente | Non rispetta le policy di manutenzione, apporta immediatamente le modifiche. | Una volta per modifica di questo tipo | Tutti i nodi in un pool di nodi di un 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 surge indipendentemente dal fatto che sia configurata una strategia di upgrade dei nodi diversa, ad esempio gli upgrade blu/verde. |
Modifiche che non richiedono la nuova creazione dei nodi
Consulta la tabella seguente per capire quali modifiche alla configurazione dei nodi non richiedono la ricreazione dei nodi. Queste modifiche non sono invasive, tuttavia potrebbero comunque verificarsi interruzioni se la configurazione del nodo aggiornata influisce sul tuo workload.
| Cambia | Avviato automaticamente o manualmente | Rispetta le policy di manutenzione | Frequenza | Tipo di interruzione | Livello di interruzione |
|---|---|---|---|---|---|
|
Aggiorna le seguenti impostazioni:
|
Avviato manualmente | Non rispetta le policy di manutenzione, apporta immediatamente le modifiche. | Una volta per modifica di questo tipo | Tutti i nodi pertinenti sono aggiornati. | I pod non devono essere sostituiti perché la configurazione dei nodi viene aggiornata senza ricrearli. |
Passaggi successivi
- Panoramica di GKE
- Architettura dei cluster GKE
- Responsabilità condivisa di GKE
- Controllo delle versioni e assistenza di GKE
- Accordo sul livello del servizio di GKE
- Upgrade dei cluster GKE