Questo documento descrive come progettare, pianificare e implementare gli upgrade in un ambiente Google Kubernetes Engine (GKE) multi-cluster. Sebbene questo documento utilizzi Ingress multi-cluster per gli upgrade, i concetti possono essere applicati ad altre soluzioni. Questo documento è rivolto agli amministratori di Google Cloud responsabili della manutenzione dei parchi risorse per i cluster GKE.
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 una flotta di cluster Kubernetes integra e aggiornata senza violare gli SLO del servizio. Con strategie e pianificazione adeguate, la gestione del ciclo di vita dei cluster dovrebbe essere di routine, prevista e senza intoppi.
Per saperne di più sulla gestione della versione GKE di un cluster, consulta Informazioni sugli upgrade dei cluster GKE. Per saperne di più sulla gestione di tutti i tipi di modifiche durante il ciclo di vita di un cluster, consulta Gestire le modifiche al ciclo di vita del cluster per ridurre al minimo le interruzioni.
Gestione del ciclo di vita multicluster GKE
Questa sezione descrive varie strategie di gestione del ciclo di vita multi-cluster GKE e come pianificarle.
Considerazioni sulla pianificazione e sulla 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 di queste strategie, è importante discutere di 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 multi-cluster GKE, a qualsiasi tipo di cluster.
Posizionamento e footprint del cluster
Quando decidi il posizionamento e l'impatto del cluster, tieni conto dei seguenti fattori:
- Le zone e le regioni in cui devono trovarsi i cluster.
- Numero e dimensioni dei cluster necessari.
Il primo fattore è solitamente facile da gestire 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 a livello di regione e posizionare uno (o due) cluster 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 aggiornare. Potrebbero anche esserci costi aggiuntivi associati a un numero maggiore di nodi del piano di controllo. Puoi compensare i costi e l'elevato overhead operativo con l'automazione, una pianificazione e una strategia prevedibili e un attento coordinamento 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 normali:
- Eventi pianificati come gli upgrade dei cluster
- Eventi imprevisti come interruzioni del cluster, ad esempio push di configurazione errati e implementazioni errate
Quando pianifichi la capacità, devi tenere conto di eventuali interruzioni totali o parziali. Se progetti solo per 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 per gli upgrade senza degradare il servizio. Questo approccio è anche noto come 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 erogare la capacità prevista: uno per l'evento pianificato e uno per un evento non pianificato nel caso in cui si verifichi durante il periodo di manutenzione pianificato. 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 trasferimento) del traffico ad 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'utilizzo attento dello svuotamento e dello spilling è alla base di alcune strategie di gestione del ciclo di vita dei cluster. Quando pianifichi la capacità, devi considerare lo svuotamento e il traboccamento. Ad esempio, quando un singolo cluster viene svuotato, devi considerare se gli altri cluster hanno capacità sufficiente per gestire il traffico aggiuntivo trasferito. Altre considerazioni includono la capacità sufficiente nella zona o nella regione o la necessità di inviare il traffico a una regione diversa (se utilizzi un singolo cluster regionale per regione). Il seguente diagramma mostra il traffico che viene rimosso (a volte indicato come 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 dei cluster (numero, dimensioni e posizione) sia determinata dai servizi che devono essere eseguiti sui cluster. Pertanto, il posizionamento dei cluster è determinato dalla località in cui sono necessari i servizi distribuiti. Tieni presente quanto segue quando decidi il posizionamento dei servizi distribuiti:
- Requisito di posizione. 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 di cluster, zona o anche 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 gestiscono un solo 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 multi-tenant possono eseguire molti servizi e prodotti che in genere sono suddivisi in spazi dei nomi.
Impatto sui team
Un evento del cluster non influisce solo sui servizi, ma può anche avere un impatto 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 ridurre l'impatto su più team. L'upgrade di un cluster o di un parco risorse di cluster deve essere considerato come un'operazione di routine e senza problemi quando tutti i team sono informati.
Tempistiche, pianificazione 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 esistere un accordo tra i proprietari del servizio, gli operatori del servizio e gli amministratori della piattaforma su 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 dovresti 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 avere una strategia in atto che venga comunicata chiaramente ai proprietari del servizio, nonché ai team operativi e di assistenza. Non devono esserci sorprese e tutti devono sapere quando e come vengono aggiornati i 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, ad esempio team di amministratori di norme o di sicurezza, amministratori di rete e 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 responsabile della gestione degli incidenti, una stanza virtuale 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 descrive le principali strategie di gestione del ciclo di vita dei cluster spesso utilizzate nell'architettura multi-cluster GKE. È importante notare che una strategia non funzionerà 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 e aggiornato. 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 consideri i cluster come infrastruttura immutabile. L'infrastruttura immutabile impone di creare nuovi cluster ed evitare qualsiasi deriva imprevista della configurazione, anziché eseguire costantemente l'upgrade di un cluster, il che potrebbe produrre risultati indesiderati nel tempo.
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 template di configurazione nel 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 al 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 rispetto alla resilienza, utilizza la strategia di upgrade in sequenza. Durante questa strategia, non superi mai la capacità richiesta del parco risorse GKE per tutti i servizi distribuiti.
Il seguente diagramma confronta la sequenza temporale e il requisito di capacità del servizio durante un upgrade del cluster GKE in un'architettura multicluster.
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 da aggiornare 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. 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 aggiornamenti in sequenza, ma è più costosa. L'unica
differenza è che, invece di 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 ricevono tutto il traffico, svuoti ed elimini 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 inviargli 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 risorse GKE per la durata degli upgrade.
Nel diagramma precedente, l'aggiunta di un nuovo cluster aumenta temporaneamente la capacità disponibile rispetto alla capacità richiesta, mentre un altro cluster nel parco risorse viene svuotato e rimosso dal parco risorse. Tuttavia, dopo aver rimosso uno dei vecchi cluster (completamente svuotato), 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 macchine.
Upgrade canary dei cluster
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 resilienza più elevata per i tuoi servizi. Nelle strategie di upgrade rolling e blu/verde precedenti, mantieni l'intero parco risorse 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 più vecchio viene svuotato (ovvero quando è stata eseguita la migrazione di tutti i servizi 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 parchi risorse GKE. Le flotte aggiuntive ti offrono maggiore flessibilità, ma aumentano anche i costi e l'overhead operativo. Questi parchi risorse aggiuntivi non sono la stessa cosa di avere 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 la manutenzione di più versioni del parco risorse GKE nell'ambiente di produzione. Questa è 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 risorse 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 finché la flotta precedente non viene svuotata completamente nel tempo. Dopo che il parco risorse è stato svuotato, 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 dai la priorità alla resilienza, utilizza la strategia di upgrade del cluster canary.
Scegliere una strategia di upgrade
Il seguente diagramma può aiutarti a determinare la strategia migliore per te in base alle esigenze del servizio e dell'attività.
Il diagramma precedente è un albero decisionale che ti aiuta a scegliere la strategia di upgrade più adatta alle tue esigenze:
- Se non hai bisogno di un controllo completo sulla versione esatta e sul momento 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 ai costi, puoi scegliere la strategia di upgrade dei cluster canary.
Gestione del traffico multi-cluster per il ciclo di vita dei cluster GKE
Per mantenere la disponibilità del servizio durante gli upgrade multi-cluster, devi svuotare e cambiare percorso del traffico tra i cluster. Puoi gestire questo traffico utilizzando il gateway multi-cluster (consigliato) o Ingress multi-cluster. Il gateway multi-cluster è il successore di Ingress multi-cluster e fornisce un approccio più espressivo e orientato ai ruoli al networking dei servizi.
Utilizzare il gateway multi-cluster per la gestione del ciclo di vita del cluster
Multi-cluster Gateway (MCG) utilizza l'API Gateway per gestire il traffico per i servizi di cui è stato eseguito il deployment in più cluster GKE all'interno di un parco risorse.
Il controller GKE Gateway è un servizio ospitato da Google che monitora le risorse Gateway e HTTPRoute in un cluster di configurazione designato. Il controller esegue automaticamente il provisioning e la manutenzione dell'infrastruttura di bilanciamento del carico, fornendo un unico punto di accesso unificato per le applicazioni nei cluster del parco risorse. Questa architettura ti consente di disaccoppiare il ciclo di vita del bilanciatore del carico dai singoli cluster GKE in cui risiedono i workload.
Per la gestione del ciclo di vita dei cluster GKE, il gateway multicluster consente strategie avanzate di controllo del traffico:
- Aggiornamenti blu-verde: esegui il deployment di un nuovo cluster "verde" e sposta gradualmente il traffico dal cluster "blu" modificando i pesi nella risorsa HTTPRoute.
- Bilanciamento del carico basato sulla capacità: reindirizza automaticamente il traffico quando un servizio in un cluster raggiunge il limite di capacità definito, il che contribuisce a proteggerlo dal sovraccarico durante gli upgrade in sequenza.
- Failover basato sull'integrità: monitora l'integrità dei backend in tutti i cluster e reindirizza automaticamente il traffico da un cluster in fase di svuotamento o che presenta problemi.
Per ulteriori informazioni, segui il tutorial per implementare un gateway multicluster per la suddivisione ponderata del traffico.
Utilizza Ingress multi-cluster per la gestione del ciclo di vita dei cluster
Un'altra soluzione per la gestione del traffico 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 tra 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 i cluster, puoi utilizzare tecnologie di service mesh come Cloud Service Mesh o Istio, che forniscono funzionalità simili tra i servizi distribuiti.
Per saperne di più, segui il tutorial per eseguire l'upgrade di un ambiente GKE multi-cluster con Ingress multi-cluster.
Passaggi successivi
- Scopri di più sul gateway multi-cluster.
- Scopri di più su Ingress multi-cluster.