Informazioni sugli upgrade GKE multi-cluster con Ingress multi-cluster

Autopilot Standard

---

Questo documento descrive come progettare, pianificare e implementare gli upgrade in un ambiente Google Kubernetes Engine (GKE) multi-cluster. Sebbene questo documento utilizzi Multi Cluster Ingress per gli upgrade, i concetti possono essere applicati ad altre soluzioni, ad esempio la configurazione manuale di un bilanciatore del carico esterno. Esiste un tutorial di accompagnamento a questo documento che mostra come eseguire l'upgrade di un ambiente GKE multi-cluster con Ingress multi-cluster. Questo documento è destinato agli Google Cloud amministratori responsabili della manutenzione delle flotte per i cluster GKE.

La necessità di un'architettura multi-cluster

Questa sezione illustra vari motivi per cui potresti aver bisogno di un'architettura Kubernetes multi-cluster.

Kubernetes come infrastruttura

Questo documento considera i cluster Kubernetes come componenti dell'infrastruttura. L'infrastruttura è temporanea. Nessun componente dell'infrastruttura deve essere trattato in modo speciale perché i componenti sono lì per uno scopo. Lo scopo di Kubernetes è fornire automazione e orchestrazione a sviluppatori e operatori per fornire applicazioni e servizi basati su container ai consumatori. I consumatori possono essere team interni, altri servizi o clienti esterni.

Scenari multi-cluster comuni

Oltre all'argomento Kubernetes come infrastruttura, esistono diversi motivi per avere un ambiente multicluster:

• Area geografica. Molti servizi devono trovarsi in più regioni. Se posizioni un servizio più vicino al consumatore (nella sua regione), l'esperienza sarà migliore grazie a una latenza inferiore rispetto a quando il servizio viene fornito da una singola regione. Un cluster Kubernetes viene eseguito in una singola regione. Per i deployment multiregionali, sono necessari più cluster Kubernetes in più regioni. Gli ambienti multi-cloud o cloud ibrido richiedono anche più cluster in ogni ambiente. I cluster Kubernetes sono spesso collocati insieme alle origini dati (stateful) dei Servizi. Alcune applicazioni potrebbero dover trovarsi nella stessa località (regione e zona) del relativo backend, ad esempio un sistema di gestione di database relazionali (RDBMS).
• Tenant e ambienti. I cluster Kubernetes sono progettati per il multi-tenancy. Più team possono condividere un singolo cluster per i rispettivi servizi. Kubernetes fornisce risorse standard, come spazi dei nomi, controllo dell'accesso basato sui ruoli (RBAC), criteri di rete e autenticazione, per configurare correttamente i controlli dell'accesso in ambienti multi-tenant. In alcuni casi, alcuni Servizi potrebbero non essere in grado di coesistere in un cluster con altri Servizi a causa di norme aziendali, privacy, sicurezza o normative di settore. In questi casi, sono necessari più cluster per separare determinati tenant nei propri cluster. Anche gli ambienti (sviluppo, gestione temporanea e produzione) vengono spesso creati come cluster separati. L'ambito di accesso e i tipi di applicazioni installate in ambienti diversi variano enormemente e devono essere mantenuti come cluster separati.
• Composizione e funzione. A volte un cluster viene creato per svolgere una funzione specifica. Ad esempio, i flussi di lavoro di machine learning utilizzano Kubeflow o job di analisi dei dati che potrebbero richiedere nodi con GPU o altri requisiti hardware per cluster di istanze costituiti da VM spot allo scopo di workload di analisi batch. Questi requisiti hardware potrebbero non essere applicabili ad altri Servizi. Questi flussi di lavoro potrebbero non essere fondamentali per la gestione dell'attività e possono richiedere cluster effimeri (cluster di breve durata). I servizi condivisi, come l'osservabilità (logging, metriche e tracce) e gli strumenti CI/CD, sono più adatti al proprio cluster di amministrazione della piattaforma. Spesso vengono visualizzati cluster separati specifici per le funzioni per i workflow non fondamentali per l'attività.
• Resilienza. Spesso vengono utilizzati più cluster per aumentare la resilienza in un ambiente. Ogni cluster ha un'area di impatto. In questo contesto, un'area di impatto è il numero di servizi interessati negativamente a causa di un malfunzionamento, di una configurazione errata o di un cluster offline a causa di manutenzione pianificata o non pianificata. Se hai un numero elevato di cluster di dimensioni più ridotte, hai un numero elevato di aree di impatto di dimensioni più ridotte. Se un servizio esiste in due cluster, questi condividono il carico in modo equo. Se un cluster va offline, il 50% del traffico viene interessato. Se lo stesso Servizio è stato pubblicato da un singolo cluster, qualsiasi evento su quel cluster causerebbe un'interruzione del 100% per quel Servizio. Per questo motivo, spesso vengono utilizzati più cluster anche per il ripristino di emergenza.

Questo documento si concentra sull'aspetto della resilienza dei deployment multi-cluster.

Servizi multi-cluster e distribuiti

Un servizio distribuito è un servizio Kubernetes di cui è stato eseguito il deployment in più cluster Kubernetes. I servizi distribuiti sono servizi stateless e si comportano in modo identico in più cluster. Ciò significa che un servizio distribuito ha lo stesso nome di servizio Kubernetes ed è implementato nello stesso spazio dei nomi in più cluster. I servizi Kubernetes sono collegati al cluster Kubernetes su cui vengono eseguiti. Se un cluster Kubernetes va offline, lo stesso vale per il servizio Kubernetes. I servizi distribuiti sono astratti dai singoli cluster Kubernetes. Se uno o più cluster Kubernetes sono inattivi, il servizio distribuito potrebbe essere online e rientrare nell'obiettivo del livello di servizio (SLO).

Nel seguente diagramma, frontend è un servizio distribuito in esecuzione su più cluster con lo stesso nome e spazio dei nomi del servizio.

Con questa architettura, il servizio frontend non è legato a un singolo cluster ed è rappresentato concettualmente nel diagramma come un livello che si estende sul livello di infrastruttura del cluster Kubernetes. Se uno dei singoli cluster che eseguono il servizio frontend diventa inattivo, il servizio frontend rimane online. Esistono servizi aggiuntivi in esecuzione su singoli cluster individuali: accounts Servizio e ledger Servizio. Il loro uptime e la loro disponibilità dipendono dall'uptime del cluster Kubernetes in cui si trovano.

La resilienza è uno dei motivi dei deployment multicluster. I servizi distribuiti creano servizi resilienti su un'architettura multi-cluster. I servizi stateless sono i candidati ideali per i servizi distribuiti in un ambiente multicluster. Quando lavori con servizi distribuiti, si applicano i seguenti requisiti e considerazioni:

• Networking multi-cluster. Puoi inviare il traffico destinato a un servizio distribuito ai cluster che eseguono il servizio utilizzando una tecnologia di ingresso multicluster come Multi Cluster Ingress o utilizzando il tuo bilanciatore del carico esterno o la tua soluzione proxy. Qualunque opzione utilizzi, deve darti il controllo su quando, dove e quanto traffico viene indirizzato a una particolare istanza di un servizio distribuito. Il seguente diagramma mostra un bilanciatore del carico che invia traffico a un servizio frontend distribuito in esecuzione in due cluster GKE.

  

• Osservabilità. Utilizza strumenti per misurare gli SLO, in genere disponibilità e latenza, collettivamente per un servizio distribuito. Questa configurazione fornisce una visione globale del rendimento di ogni servizio in più cluster. Sebbene il servizio distribuito non sia una risorsa ben definita nella maggior parte delle soluzioni di osservabilità, puoi raccogliere e combinare le singole metriche del servizio Kubernetes. Soluzioni come Cloud Monitoring o strumenti open source come Grafana forniscono metriche del servizio Kubernetes. Le soluzioni di service mesh come Istio e Cloud Service Mesh forniscono anche metriche di servizio senza richiedere alcuna strumentazione.

• Posizionamento del servizio. I servizi Kubernetes forniscono la tolleranza agli errori a livello di nodo all'interno di un singolo cluster Kubernetes. Ciò significa che un servizio Kubernetes può resistere alle interruzioni dei nodi. Durante le interruzioni dei nodi, un nodo del control plane Kubernetes ripianifica automaticamente i pod sui nodi integri. Un servizio distribuito fornisce tolleranza di errore a livello di cluster. Ciò significa che un servizio distribuito può resistere alle interruzioni del cluster. Quando pianifichi la capacità per un servizio distribuito, devi considerare il posizionamento del servizio. Un servizio distribuito non deve essere eseguito su ogni cluster. I cluster su cui viene eseguito un servizio distribuito dipendono dai seguenti requisiti:

  • Dove o in quali regioni è richiesto il servizio?
  • Qual è lo SLO richiesto per il servizio distribuito?
  • Quale tipo di tolleranza agli errori è richiesto per il servizio distribuito: cluster, zona o regione? Ad esempio, hai bisogno di più cluster in una singola zona o di più cluster in più zone in una singola regione o in più regioni?

  • Quale livello di interruzioni deve sopportare il servizio distribuito nello scenario peggiore? Nel livello del cluster sono disponibili le seguenti opzioni:

    • N+1 (dove N rappresenta il numero di cluster necessari per soddisfare le esigenze di capacità del servizio). Un servizio distribuito può resistere all'errore di un singolo cluster
    • N+2. Un servizio distribuito può resistere a due errori simultanei. Ad esempio, un'interruzione pianificata e una non pianificata di un servizio Kubernetes in due cluster contemporaneamente.

• Implementazioni e rollback. I servizi distribuiti, come i servizi Kubernetes, consentono implementazioni e rollback graduali. A differenza dei servizi Kubernetes, i servizi distribuiti consentono ai cluster di essere un'unità aggiuntiva di deployment come mezzo per un cambiamento graduale. Anche i rollout e i rollback dipendono dai requisiti del servizio. In alcuni casi, potrebbe essere necessario eseguire l'upgrade del servizio su tutti i cluster contemporaneamente, ad esempio una correzione di bug. In altri casi, potrebbe essere necessario implementare lentamente (o scaglionare) la modifica un cluster alla volta. Questo lancio graduale riduce il rischio per il servizio distribuito introducendo gradualmente le modifiche al servizio. Tuttavia, questa operazione potrebbe richiedere più tempo a seconda del numero di cluster. Non esiste una strategia di upgrade migliore di altre. Spesso vengono utilizzate più strategie di implementazione e rollback a seconda dei requisiti del servizio distribuito. Il punto importante è che i servizi distribuiti devono consentire modifiche graduali e controllate nell'ambiente.

• Continuità aziendale e ripristino di emergenza (BCDR). Questi termini vengono spesso usati insieme. La continuità operativa si riferisce alla continuazione dei servizi critici in caso di un evento importante (pianificato o non pianificato), mentre il ripristino di emergenza si riferisce ai passaggi intrapresi o necessari per riportare le operazioni aziendali al loro stato normale dopo tali eventi. Esistono molte strategie per il BCDR che non rientrano nell'ambito di questo documento. Il BCDR richiede un certo livello di ridondanza nei sistemi e nei servizi. Il presupposto fondamentale dei servizi distribuiti è che vengono eseguiti in più località (cluster, zone e regioni).

  Le strategie di BCDR spesso dipendono dalle strategie di implementazione e rollback discusse in precedenza. Ad esempio, se i rollout vengono eseguiti in modo scaglionato o controllato, l'effetto di un bug o di un push di configurazione errata può essere rilevato in anticipo senza interessare un numero elevato di utenti. Su larga scala e in combinazione con un rapido tasso di cambiamento (ad esempio nelle moderne pratiche CI/CD), è comune che non a tutti gli utenti venga fornita la stessa versione di un servizio distribuito. La pianificazione e le strategie di BCDR nei sistemi e nei servizi distribuiti differiscono dalle architetture monolitiche tradizionali. Nei sistemi tradizionali, una modifica viene apportata all'ingrosso, interessando un numero elevato di utenti, o forse tutti, e quindi deve essere presente un sistema ridondante o di backup in caso di effetti indesiderati di un implementazione. Nei sistemi e nei servizi distribuiti, quasi tutte le modifiche vengono apportate in modo graduale per interessare solo un numero limitato di utenti.

• Gestione del ciclo di vita del cluster. Come i rollout e i rollback controllati, i servizi distribuiti consentono la gestione controllata del ciclo di vita del cluster. I servizi distribuiti forniscono resilienza a livello di cluster, in modo che i cluster possano essere rimossi dalla rotazione per la manutenzione. La gestione del ciclo di vita del cluster è un principio dei servizi distribuiti che non si applica ai servizi Kubernetes.

Il resto di questo documento si concentra sull'aspetto del ciclo di vita del cluster dei servizi distribuiti.

Gestione del ciclo di vita del cluster GKE

La gestione del ciclo di vita del cluster può essere definita come le strategie e la pianificazione necessarie per mantenere un parco di cluster Kubernetes integro e aggiornato senza violare gli SLO del servizio. Con strategie e pianificazione adeguate, la gestione del ciclo di vita del cluster deve essere di routine, prevista e senza imprevisti.

Questo documento si concentra sulla gestione del ciclo di vita di GKE. Tuttavia, puoi applicare questi concetti ad altre distribuzioni di Kubernetes.

Controllo delle versioni e upgrade di GKE

Prima di discutere le strategie e pianificare la gestione del ciclo di vita del cluster, è importante capire cosa costituisce un upgrade del cluster.

Un cluster contiene due componenti: nodi del control plane e nodi worker. L'upgrade di un cluster Kubernetes richiede che tutti i nodi vengano aggiornati alla stessa versione. Kubernetes segue uno schema di controllo delle versioni semantico. Le versioni di Kubernetes sono espresse come X.Y.Z:, dove X è la versione principale, Y è la versione secondaria e Z è la versione patch. Le release secondarie vengono rilasciate circa ogni tre mesi (trimestralmente) e il progetto Kubernetes mantiene i rami di rilascio per le tre release secondarie più recenti. Ciò significa che una versione secondaria di Kubernetes di nove mesi non viene più gestita e potrebbe richiedere modifiche all'API quando esegui l'upgrade all'ultima versione. Gli upgrade di Kubernetes devono essere pianificati a intervalli regolari. Ti consigliamo di eseguire upgrade pianificati di GKE ogni trimestre o ogni due trimestri.

I cluster GKE supportano l'esecuzione di versioni di Kubernetes da qualsiasi release secondaria supportata. In un dato momento sono disponibili almeno due versioni secondarie.

GKE è un servizio gestito e offre upgrade automatici sia per i nodi del control plane sia per i nodi worker.

Upgrade automatico di GKE

L'upgrade automatico di GKE è una strategia di ciclo di vita del cluster popolare e spesso utilizzata. L'upgrade automatico di GKE offre un modo completamente gestito per mantenere i tuoi cluster GKE aggiornati alle versioni supportate. Gli upgrade automatici di GKE eseguono l'upgrade dei nodi del control plane e dei nodi worker separatamente:

• Upgrade automatici principali. Per impostazione predefinita, i nodi del control plane GKE vengono aggiornati automaticamente. I cluster a zona singola e multi-zona hanno un unico control plane (nodo del control plane). Durante gli upgrade dei nodi del control plane, i carichi di lavoro continuano a essere eseguiti. Tuttavia, non puoi eseguire il deployment di nuovi carichi di lavoro, modificare quelli esistenti o apportare altre modifiche alla configurazione del cluster finché l'upgrade non è completato.

  I cluster regionali hanno più repliche del control plane e solo una replica viene sottoposta ad upgrade alla volta. Durante l'upgrade, il cluster rimane a disponibilità elevata e ogni replica del control plane non è disponibile solo durante l'upgrade.

• Upgrade automatici dei nodi worker. I pool di nodi vengono sottoposti a upgrade uno alla volta. All'interno di un pool di nodi, i nodi vengono aggiornati uno alla volta in un ordine non definito. Puoi modificare il numero di nodi di cui viene eseguito l'upgrade contemporaneamente, ma questo processo può richiedere diverse ore a seconda del numero di nodi e delle loro configurazioni del carico di lavoro.

Strategia del ciclo di vita dell'upgrade automatico di GKE

Ti consigliamo di utilizzare l'upgrade automatico di GKE, se possibile. Gli upgrade automatici di GKE danno la priorità alla praticità rispetto al controllo. Tuttavia, gli upgrade automatici di GKE offrono molti modi per influenzare quando e come vengono eseguiti gli upgrade dei cluster entro determinati parametri. Puoi influenzare i periodi di manutenzione e le esclusioni dalla manutenzione. I canali di rilascio influiscono sulla selezione della versione e le strategie di upgrade dei nodi influiscono sull'ordine e sulla tempistica degli upgrade dei nodi. Nonostante questi controlli e i cluster regionali (con più control plane Kubernetes), l'upgrade automatico di GKE non garantisce l'uptime dei servizi. Puoi scegliere di non utilizzare la funzionalità di upgrade automatico di GKE se hai bisogno di uno o più dei seguenti elementi:

• Controllo della versione esatta dei cluster GKE.
• Controlla l'ora esatta in cui eseguire l'upgrade di GKE.
• Controlla la strategia di upgrade (descritta nella sezione successiva) per la tua flotta GKE.

Gestione del ciclo di vita multi-cluster GKE

Questa sezione descrive varie strategie di gestione del ciclo di vita multicluster di GKE e come pianificarle.

Considerazioni su pianificazione e progettazione

L'architettura multi-cluster GKE svolge un ruolo nella selezione di una strategia di gestione del ciclo di vita dei cluster. Prima di discutere queste strategie, è importante discutere alcune decisioni di progettazione che potrebbero influire o essere influenzate dalla strategia di gestione del ciclo di vita del cluster.

Tipo di cluster

Se utilizzi l'upgrade automatico di GKE come strategia di gestione del ciclo di vita del cluster, il tipo di cluster può essere importante. Ad esempio, i cluster regionali hanno più nodi del control plane, che vengono aggiornati automaticamente uno alla volta, mentre i cluster di zona hanno un singolo nodo del control plane. Se non utilizzi l'upgrade automatico di GKE e se consideri tutti i cluster Kubernetes come infrastruttura usa e getta, il tipo di cluster che scegli potrebbe non essere importante quando decidi una strategia di gestione del ciclo di vita del cluster. Puoi applicare le strategie descritte nella sezione successiva, Gestione del ciclo di vita multicluster GKE, a qualsiasi tipo di cluster.

Posizionamento e footprint del cluster

Quando decidi il posizionamento e l'ingombro del cluster, prendi in considerazione i seguenti fattori:

• Le zone e le regioni in cui devono trovarsi i cluster.
• Numero e dimensioni dei cluster necessari.

Il primo fattore è in genere facile da affrontare perché le zone e le regioni sono dettate dalla tua attività e dalle regioni in cui servi i tuoi utenti.

La gestione del numero e delle dimensioni dei cluster rientra in genere nelle seguenti categorie, ognuna con vantaggi e svantaggi:

• Numero ridotto di cluster di grandi dimensioni. Puoi scegliere di utilizzare la ridondanza e la resilienza fornite dai cluster regionali e posizionare uno (o due) cluster regionali di grandi dimensioni per regione. Il vantaggio di questo approccio è il basso overhead operativo della gestione di più cluster. Lo svantaggio è che può influire su un numero elevato di servizi contemporaneamente a causa della sua ampia area di impatto.
• Numero elevato di piccoli cluster. Puoi creare un numero elevato di cluster di piccole dimensioni per ridurre l'area di impatto del cluster perché i tuoi servizi sono suddivisi in molti cluster. Questo approccio funziona bene anche per i cluster temporanei di breve durata (ad esempio, i cluster che eseguono un carico di lavoro batch). Lo svantaggio di questo approccio è un overhead operativo maggiore perché ci sono più cluster da eseguire l'upgrade. Potrebbero esserci anche costi aggiuntivi associati a un numero maggiore di nodi del control plane. Puoi compensare i costi e l'elevato overhead operativo con l'automazione, una pianificazione e una strategia prevedibili e un coordinamento attento tra i team e i servizi interessati.

Questo documento non consiglia un approccio rispetto a un altro, ma offre delle opzioni. In alcuni casi, puoi scegliere entrambi i pattern di progettazione per diverse categorie di servizi.

Le seguenti strategie funzionano con entrambe le scelte di progettazione.

Pianificazione della capacità

Quando pianifichi la capacità, è importante considerare la strategia del ciclo di vita del cluster scelta. La pianificazione della capacità deve tenere conto dei seguenti eventi di carico e manutenzione del servizio normale:

• Eventi pianificati come gli upgrade dei cluster
• Eventi non pianificati come interruzioni del cluster, ad esempio push di configurazione errati e implementazioni errate

Quando pianifichi la capacità, devi prendere in considerazione eventuali interruzioni totali o parziali. Se progetti solo eventi di manutenzione pianificata, tutti i servizi distribuiti devono avere un cluster aggiuntivo rispetto a quelli richiesti, in modo da poter rimuovere un cluster alla volta dalla rotazione per gli upgrade senza degradare il servizio. Questo approccio è detto anche pianificazione della capacità N+1. Se progetti per eventi di manutenzione pianificati e non pianificati, tutti i servizi distribuiti devono avere due (o più) cluster aggiuntivi rispetto a quelli necessari per fornire la capacità prevista: uno per l'evento pianificato e uno per un evento non pianificato nel caso in cui si verifichi durante la periodo di manutenzione pianificata. Questo approccio è anche chiamato pianificazione della capacità N+2.

Nelle architetture multi-cluster, vengono spesso utilizzati i termini draining e spilling. Questi termini si riferiscono al processo di rimozione (o svuotamento) del traffico da un cluster e al reindirizzamento (o spillover) del traffico su altri cluster durante gli upgrade e gli eventi di manutenzione. Questo processo viene eseguito utilizzando soluzioni di networking come Ingress multi-cluster o altri metodi di bilanciamento del carico. L'uso attento dello svuotamento e del versamento è alla base di alcune strategie di gestione del ciclo di vita dei cluster. Quando pianifichi la capacità, devi considerare lo svuotamento e il versamento. Ad esempio, quando un singolo cluster viene svuotato, devi valutare se gli altri cluster hanno capacità sufficiente per gestire il traffico aggiuntivo. Altre considerazioni includono una capacità sufficiente nella zona o nella regione o la necessità di inviare traffico a un'altra regione (se utilizzi un singolo cluster regionale per regione). Il seguente diagramma mostra il traffico rimosso (a volte chiamato svuotamento di un cluster) da un cluster e inviato a un altro cluster che esegue lo stesso servizio distribuito.

Cluster e servizi distribuiti

La progettazione dei cluster basata sui servizi prevede che l'architettura del cluster (numero, dimensioni e posizione) sia determinata dai servizi necessari per l'esecuzione sui cluster. Pertanto, il posizionamento dei cluster è determinato dalla posizione in cui sono necessari i servizi distribuiti. Tieni presente quanto segue quando decidi il posizionamento dei servizi distribuiti:

• Requisito di localizzazione. Da quali regioni deve essere servito il servizio?
• Criticità. Quanto è fondamentale la disponibilità di un servizio per l'attività?
• SLO. Quali sono gli obiettivi del livello di servizio per il servizio (in genere in base alla criticità)?
• Resilienza. Quanto deve essere resiliente il servizio? Deve resistere a errori del cluster, della zona o persino della regione?

Quando pianifichi gli upgrade del cluster, devi considerare il numero di servizi che un singolo cluster influenza quando viene svuotato e devi tenere conto del trasferimento di ciascuno di questi servizi ad altri cluster appropriati. I cluster possono essere single-tenant o multi-tenant. I cluster single-tenant pubblicano solo un singolo servizio o un prodotto rappresentato da un insieme di servizi. I cluster single-tenant non condividono il cluster con altri servizi o prodotti. I cluster multitenant possono eseguire molti servizi e prodotti che in genere sono partizionati in spazi dei nomi.

Impatto sui team

Un evento del cluster non influisce solo sui servizi, ma può avere un impatto anche sui team. Ad esempio, il team DevOps potrebbe dover reindirizzare o interrompere le pipeline CI/CD durante l'upgrade di un cluster. Allo stesso modo, i team di assistenza possono ricevere avvisi per interruzioni pianificate. Devono essere implementati l'Automation e gli strumenti per contribuire a ridurre l'impatto su più team. L'upgrade di un cluster o di un parco risorse di cluster deve essere considerato di routine e senza problemi quando tutti i team sono informati.

Tempistiche, programmazione e coordinamento

Kubernetes rilascia una nuova versione secondaria ogni trimestre e mantiene le ultime tre versioni. Devi pianificare attentamente la tempistica e la pianificazione degli upgrade del cluster. Deve essere presente un accordo tra i proprietari del servizio, gli operatori del servizio e gli amministratori della piattaforma in merito a quando vengono eseguiti questi upgrade. Quando pianifichi gli upgrade, considera le seguenti domande:

• Con quale frequenza esegui l'upgrade? Esegui l'upgrade ogni trimestre o in un periodo di tempo diverso?
• Quando esegui l'upgrade? Esegui l'upgrade all'inizio del trimestre quando l'attività rallenta o durante altri periodi di inattività aziendale dovuti al tuo settore?
• Quando non devi eseguire l'upgrade? Hai una pianificazione chiara su quando non eseguire l'upgrade, ad esempio evita eventi di picco come il Black Friday, il Cyber Monday o durante conferenze di alto profilo e altri eventi specifici del settore.

È importante disporre di una strategia chiaramente comunicata ai proprietari del servizio, nonché ai team di operazioni e assistenza. Non devono esserci sorprese e tutti devono sapere quando e come vengono eseguiti gli upgrade dei cluster. Ciò richiede un coordinamento chiaro con tutti i team coinvolti. Un singolo servizio ha più team che interagiscono con esso. In genere, questi team possono essere raggruppati nelle seguenti categorie:

• Lo sviluppatore del servizio, responsabile della creazione e della codifica della logica di business in un servizio.
• L'operatore del servizio, responsabile del funzionamento sicuro e affidabile del servizio. Gli operatori possono essere costituiti da più team, come il team di amministratori di norme o di sicurezza, il team di amministratori di rete e i team di assistenza.

Tutti devono comunicare durante gli upgrade del cluster per poter intraprendere le azioni appropriate in questo periodo. Un approccio consiste nel pianificare gli upgrade nello stesso modo in cui pianifichi un incidente di interruzione. Hai un Incident Commander, una chat room e una retrospettiva (anche se nessun utente è stato interessato). Per ulteriori informazioni, consulta Risposta agli incidenti.

Strategie del ciclo di vita del cluster GKE

Questa sezione illustra le principali strategie di gestione del ciclo di vita dei cluster spesso utilizzate nell'architettura multi-cluster GKE. È importante notare che una strategia non funziona per tutti gli scenari e potresti scegliere più strategie per varie categorie di servizi ed esigenze dell'attività.

Upgrade in sequenza

Il seguente diagramma mostra la strategia di aggiornamento in sequenza.

Utilizzando un bilanciatore del carico, un cluster GKE viene svuotato di tutto il traffico ed eseguito l'upgrade. Il carico di traffico svuotato viene trasferito a un altro cluster GKE.

Gli upgrade in sequenza sono la strategia più semplice ed economica tra quelle discusse in questo documento. Inizi con n cluster che eseguono la versione old_ver (o di produzione attuale). Dopodiché, svuoti i cluster m alla volta, dove m è inferiore a n. Quindi, elimina e ricrea nuovi cluster con la nuova versione o esegui l'upgrade dei cluster svuotati.

La decisione tra l'eliminazione e l'upgrade dei nuovi cluster dipende dalle dimensioni dei cluster e dal fatto che tu li consideri un'infrastruttura immutabile. L'infrastruttura immutabile prevede che, anziché eseguire costantemente l'upgrade di un cluster, il che potrebbe produrre risultati indesiderati nel tempo, vengano creati nuovi cluster ed evitato qualsiasi deriva imprevista della configurazione.

Se utilizzi GKE, puoi creare un cluster GKE con un singolo comando o una chiamata API. La nuova strategia di cluster richiede che l'intera configurazione del cluster (manifest del cluster) sia archiviata al di fuori del cluster, in genere in Git. Puoi quindi utilizzare lo stesso modello di configurazione sul nuovo cluster. Se si tratta di un nuovo cluster, assicurati che le pipeline CI/CD puntino al cluster corretto. Una volta configurato correttamente il cluster, puoi reindirizzare lentamente il traffico verso il cluster monitorando gli SLO dei servizi.

La procedura viene ripetuta per tutti i cluster. A seconda della pianificazione della capacità, puoi eseguire l'upgrade di più cluster contemporaneamente senza violare gli SLO del servizio.

Se preferisci la semplicità e il costo alla resilienza, utilizza la strategia di aggiornamenti in sequenza. Durante questa strategia, non superi mai la capacità richiesta del parco GKE per tutti i servizi distribuiti.

Il seguente diagramma confronta la cronologia e il requisito di capacità del servizio durante l'upgrade di un cluster GKE in un'architettura multi-cluster.

Il diagramma precedente mostra che durante l'intero processo di upgrade di GKE, la capacità di supportare i servizi non scende mai al di sotto di quanto richiesto. Quando il cluster GKE di cui eseguire l'upgrade viene rimosso dalla rotazione, gli altri cluster vengono scalati per supportare il carico.

Upgrade blu/verde

Il seguente diagramma mostra una strategia di upgrade blu/verde.

Nel diagramma precedente viene aggiunto un nuovo cluster GKE che esegue la nuova versione. Viene quindi utilizzato un bilanciatore del carico per inviare il traffico al nuovo cluster, mentre uno dei vecchi cluster viene svuotato lentamente fino a quando non viene più inviato traffico al suo interno. Il vecchio cluster completamente svuotato può essere rimosso. La stessa procedura può essere seguita per i cluster rimanenti.

La strategia di upgrade blu/verde offre una maggiore resilienza. Questa strategia è simile agli upgrade in sequenza, ma è più costosa. L'unica differenza è che, anziché svuotare prima i cluster esistenti, crei nuovi cluster m con la versione, dove m è minore o uguale a n. Aggiungi i nuovi cluster alle pipeline CI/CD e poi sposta lentamente il traffico monitorando gli SLO del servizio. Quando i nuovi cluster gestiscono completamente il traffico, svuota ed elimina i cluster con la versione precedente.

La strategia blu/verde per l'upgrade dei cluster è simile a una strategia blu/verde utilizzata in genere per i servizi. La creazione di più nuovi cluster contemporaneamente aumenta il costo complessivo, ma offre il vantaggio di accelerare i tempi di upgrade del parco risorse. Il costo aggiuntivo è previsto solo per la durata dell'upgrade quando vengono utilizzati cluster aggiuntivi. Il vantaggio di creare prima nuovi cluster è che in caso di errore, puoi eseguire il rollback. Puoi anche testare il nuovo cluster prima di inviarvi il traffico di produzione. Poiché questi cluster coesistono con le loro controparti della versione precedente per un breve periodo di tempo, i costi aggiuntivi sono minimi.

Se preferisci la semplicità e la resilienza al costo, utilizza la strategia di upgrade blu/verde. I cluster aggiuntivi vengono aggiunti per primi e superano la capacità richiesta del parco GKE per la durata degli upgrade.

Nel diagramma precedente, l'aggiunta di un nuovo cluster aumenta temporaneamente la capacità disponibile rispetto a quella richiesta, mentre un altro cluster nel parco risorse viene svuotato e rimosso. Tuttavia, dopo aver rimosso uno dei vecchi cluster (completamente scarichi), la capacità torna a quella necessaria. Questa modifica della capacità è evidenziata perché con questo modello può verificarsi un aumento dei costi, a seconda del numero e delle dimensioni dei cluster nel parco veicoli.

Upgrade dei cluster canary

L'upgrade di un cluster canary è la strategia più resiliente e complessa tra quelle descritte in questo documento. Questa strategia astrae completamente la gestione del ciclo di vita del cluster dalla gestione del ciclo di vita dei servizi, offrendo così il rischio più basso e la massima resilienza per i tuoi servizi. Nelle strategie di aggiornamento rolling e blu/verde precedenti, mantieni l'intera flotta GKE su una singola versione. In questa strategia, mantieni due o tre parchi risorse di cluster GKE che eseguono versioni diverse. Anziché eseguire l'upgrade dei cluster, esegui la migrazione dei servizi da un parco risorse di cluster all'altro nel tempo. Quando il parco risorse GKE meno recente è esaurito (ovvero tutti i servizi sono stati migrati al parco risorse GKE con la versione successiva), elimini il parco risorse.

Questa strategia richiede di mantenere un minimo di due fleet GKE: una per la produzione attuale e una per la successiva versione candidata alla produzione. Puoi anche gestire più di due fleet GKE. Le flotte aggiuntive offrono maggiore flessibilità, ma aumentano anche i costi e l'overhead operativo. Questi parchi risorse aggiuntivi non sono uguali ai cluster in ambienti diversi, ad esempio ambienti di sviluppo, gestione temporanea e produzione. Gli ambienti non di produzione sono ideali per testare le funzionalità e i servizi Kubernetes con traffico non di produzione.

Questa strategia di utilizzo degli upgrade dei cluster canary prevede di mantenere più versioni del parco risorse GKE nell'ambiente di produzione. Questo è simile alle strategie di versione canary spesso utilizzate dai servizi. Con i deployment del servizio canary, il proprietario del servizio può sempre individuare i problemi relativi a una versione specifica del servizio. Con i cluster canary, il proprietario del servizio deve tenere conto anche delle versioni del parco GKE su cui vengono eseguiti i servizi. Una singola versione del servizio distribuito può potenzialmente essere eseguita su più versioni della flotta GKE. La migrazione di un servizio può avvenire gradualmente, in modo da poter vedere gli effetti del servizio sulla nuova flotta prima di inviare tutto il traffico del servizio ai nuovi cluster con controllo delle versioni.

Il seguente diagramma mostra che la gestione di diverse flotte di cluster GKE può astrarre completamente il ciclo di vita del cluster dal ciclo di vita dei servizi.

Il diagramma precedente mostra un servizio distribuito frontend di cui viene eseguita lentamente la migrazione da una flotta di cluster GKE alla successiva che esegue la nuova versione fino a quando la flotta precedente non viene completamente svuotata nel tempo. Una volta svuotato il parco risorse, può essere rimosso e viene creato un nuovo parco risorse. Tutti i servizi vengono migrati al parco veicoli successivo, rimuovendo quelli precedenti man mano che vengono svuotati.

Se per te la resilienza è l'aspetto più importante, utilizza la strategia di upgrade del cluster canary.

Scegliere una strategia di upgrade

Il seguente diagramma può aiutarti a determinare la strategia più adatta alle tue esigenze in base al servizio e alle esigenze aziendali.

Il diagramma precedente è un albero decisionale che ti aiuta a scegliere la strategia di upgrade più adatta a te:

• Se non hai bisogno del controllo completo sulla versione e sull'ora esatta dell'upgrade, puoi scegliere la funzionalità di upgrade automatico disponibile in GKE.
• Se la tua priorità è il costo ridotto, puoi scegliere la strategia di upgrade in sequenza.
• Se la tua priorità è bilanciare costi e resilienza, puoi scegliere la strategia blue/green.
• Se la tua priorità è la resilienza rispetto al costo, puoi scegliere la strategia di upgrade del cluster canary.

Utilizzo di Ingress multi-cluster per la gestione del ciclo di vita dei cluster GKE

Quasi tutte le strategie dipendono dalla capacità di svuotare e reindirizzare il traffico verso altri cluster durante gli upgrade. Una soluzione che fornisce questa funzionalità di Ingress multi-cluster è Ingress multi-cluster. Ingress multi-cluster è un controller Ingress multi-cluster ospitato da Google Cloudper i cluster GKE che supporta il deployment di risorse di bilanciamento del carico condivise in più cluster e regioni. Ingress multi-cluster è una soluzione per indirizzare il traffico client a un servizio distribuito in esecuzione in molti cluster in più regioni. Come Ingress per GKE, utilizza Cloud Load Balancing per inviare il traffico a un servizio di backend. Il servizio di backend è il servizio distribuito. Il servizio di backend invia il traffico a più backend, che sono servizi Kubernetes in esecuzione su più cluster GKE. Per il traffico da servizio a servizio tra cluster, puoi utilizzare tecnologie di service mesh come Cloud Service Mesh o Istio, che forniscono funzionalità simili tra servizi distribuiti.

Per gli ambienti GKE multi-cluster, puoi utilizzare Ingress multi-cluster per manipolare il traffico verso più cluster per le strategie di gestione del ciclo di vita dei cluster discusse in precedenza. Puoi seguire un tutorial per utilizzare Ingress multi-cluster per gli upgrade GKE utilizzando la strategia blu/verde.

Passaggi successivi

• Scopri di più su Ingress multi-cluster.
• Scopri come eseguire il deployment di Ingress multi-cluster nei cluster.