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, ad esempio la configurazione manuale di un bilanciatore del carico esterno. Esiste un tutorial associato a questo documento che mostra come eseguire l'upgrade di un ambiente GKE multi-cluster con Ingress multi-cluster. Questo documento è rivolto agli amministratori di Google Cloud responsabili della manutenzione dei parchi risorse per i cluster GKE.
La necessità di un'architettura multi-cluster
Questa sezione illustra i vari motivi per cui potrebbe essere necessaria un'architettura Kubernetes multi-cluster.
Kubernetes come infrastruttura
Questo documento considera i cluster Kubernetes come componenti dell'infrastruttura. L'infrastruttura è temporanea. Non è richiesto alcun trattamento speciale ai componenti dell'infrastruttura, in quanto i componenti hanno uno scopo specifico. 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-as-infrastructure, esistono diversi motivi per creare un ambiente multi-cluster:
- Area geografica. Molti servizi devono trovarsi in più regioni. Posizionare un Servizio più vicino al consumatore (nella sua regione) fornisce un'esperienza 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 cloud multi-cloud o ibridi richiedono anche più cluster in ciascun ambiente. I cluster Kubernetes vengono spesso allocati con le origini dati dei servizi (stateful). Alcune applicazioni potrebbero dover essere nella stessa località (regione e zona) del relativo backend, ad esempio un sistema di gestione di database relazionali (RDBMS).
- Tenancy e ambienti. I cluster Kubernetes sono progettati per la multi-tenancy. Più team possono condividere un unico cluster per i rispettivi servizi. Kubernetes fornisce risorse standard come spazi dei nomi, controllo dell'accesso basato su 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 co-residente in un cluster con altri Servizi a causa di norme aziendali, privacy, sicurezza o normative del settore. In questi casi, sono necessari più cluster per separare determinati tenant in 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 notevolmente e devono essere conservati come cluster separati.
- Composizione e funzione. A volte viene creato un cluster per eseguire una particolare funzione. 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 i cluster di istanze costituiti da VM spot per carichi di lavoro di analisi batch. Questi requisiti hardware potrebbero non essere applicabili ad altri Servizi. Questi flussi di lavoro potrebbero non essere cruciali per l'esecuzione dell'attività e possono richiedere cluster temporanei (cluster di breve durata). I servizi condivisi, come l'osservabilità (logging, metriche e tracce) e gli strumenti CI/CD, sono più adatti ai rispettivi cluster di amministrazione della piattaforma. Per i flussi di lavoro non business-critical vengono spesso utilizzati cluster separati, specifici per le funzioni.
- Resilienza. Spesso si usano più cluster per aumentare la resilienza in un ambiente. Ogni cluster ha un'area d'impatto. In questo contesto, un'area di impatto è il numero di servizi che hanno subito effetti negativi a causa di un malfunzionamento del cluster, di una configurazione errata o di un cluster che diventa offline a causa di manutenzione pianificata o non pianificata. Se hai un numero elevato di cluster di dimensioni inferiori, significa che ne hai un numero elevato di aree d'impatto di dimensioni inferiori. Se un servizio esiste in due cluster, questi condividono il carico equamente. Se un cluster diventa offline, il 50% del traffico viene influenzato. Se lo stesso servizio fosse gestito da un singolo cluster, qualsiasi evento su quel cluster causerebbe un'interruzione del 100% per quel servizio. Per questo motivo, spesso vengono usati più cluster per il ripristino di emergenza.
Questo documento è incentrato sull'aspetto della resilienza dei deployment multi-cluster.
Servizi multi-cluster e distribuiti
Un servizio distribuito è un servizio Kubernetes di cui viene eseguito il deployment in più cluster Kubernetes. I servizi distribuiti sono servizi stateless e agiscono idenalmente 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, così anche il servizio Kubernetes. I servizi distribuiti sono astratti dai singoli cluster Kubernetes. Se uno o più cluster Kubernetes non sono attivi, il servizio distribuito potrebbe essere online e rientrare nell'obiettivo del livello del servizio (SLO).
Nel diagramma seguente, frontend è un servizio distribuito in esecuzione su più cluster con lo stesso nome di servizio e spazio dei nomi.
Con questa architettura, il servizio frontend non è legato a un singolo cluster ed è rappresentato concettualmente nel diagramma come un livello che abbraccia il livello dell'infrastruttura del cluster Kubernetes. Se uno dei singoli cluster che esegue il servizio frontend smette di funzionare, frontend rimane online.
Sono presenti ulteriori servizi in esecuzione su singoli cluster singoli: accounts
Servizio e ledger Service. Il loro tempo di attività e la loro disponibilità dipendono
dall'uptime del cluster Kubernetes in cui risiedono.
La resilienza è uno dei motivi dei deployment multicluster. I servizi distribuiti creano servizi resilienti su un'architettura multi-cluster. I servizi stateless sono candidati ideali per i servizi distribuiti in un ambiente multi-cluster. Quando lavori con servizi distribuiti, si applicano le considerazioni e i requisiti seguenti:
Networking multi-cluster. Puoi inviare il traffico destinato a un servizio distribuito ai cluster che lo eseguono utilizzando una tecnologia Ingress multi-cluster come Ingress multi-cluster oppure utilizzando il tuo bilanciatore del carico o una soluzione proxy esterni. Qualunque opzione utilizzi, deve consentirti di controllare quando, dove e quanto traffico viene instradato verso una determinata istanza di un servizio distribuito. Il seguente diagramma mostra un bilanciatore del carico che invia traffico a un servizio distribuito
frontendin esecuzione in due cluster GKE.
Osservabilità. Usa gli strumenti per misurare collettivamente gli SLO, in genere disponibilità e latenza, per un servizio distribuito. Questa configurazione offre una visione globale delle prestazioni di ogni servizio su più cluster. Sebbene il servizio distribuito non sia una risorsa ben definita nella maggior parte delle soluzioni di osservabilità, puoi raccogliere e combinare singole metriche di Kubernetes Service. Soluzioni come Cloud Monitoring o strumenti open source come Grafana forniscono metriche di servizio Kubernetes. Anche le soluzioni mesh di servizi come Istio e Cloud Service Mesh forniscono metriche di servizio senza bisogno di alcuna strumentazione.
Posizionamento del servizio. I servizi Kubernetes offrono la tolleranza di errore a livello di nodo all'interno di un singolo cluster Kubernetes. Ciò significa che un servizio Kubernetes può tollerare interruzioni dei nodi. Durante le interruzioni dei nodi, un nodo del piano di controllo Kubernetes ripianifica automaticamente i pod su nodi integri. Un servizio distribuito fornisce la tolleranza di errore a livello di cluster. Ciò significa che un servizio distribuito può tollerare interruzioni del cluster. Quando pianifichi la capacità per un servizio distribuito, devi prendere in considerazione questo posizionamento di servizio. Non è necessario eseguire un servizio distribuito su tutti i cluster. I cluster in 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 di errore è richiesta per il servizio distribuito (cluster, a livello di zona o di regione?) Ad esempio, hai bisogno di più cluster in una singola zona o più cluster in zone di una o più regioni?
Quale livello di interruzioni dovrebbe sostenere il servizio distribuito nel peggiore dei casi? A livello di cluster sono disponibili le seguenti opzioni:
- N+1 (dove N rappresenta il numero di cluster necessari per soddisfare le esigenze di capacità di servizio). Un servizio distribuito può resistere a un errore del cluster singolo
- N+2. Un servizio distribuito può tollerare due errori simultanei. ad esempio un'interruzione pianificata e non pianificata di un servizio Kubernetes in due cluster contemporaneamente.
Implementazioni e rollback. I servizi distribuiti, come quelli 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 una modifica graduale. Le implementazioni e i rollback dipendono anche dal requisito del servizio. In alcuni casi, potresti dover eseguire l'upgrade del servizio su tutti i cluster contemporaneamente. Ad esempio, correggi un bug. In altri casi, potrebbe essere necessario implementare lentamente (o scaglionare) la modifica un cluster alla volta. Questa implementazione graduale riduce il rischio per il servizio distribuito mediante l'introduzione graduale di modifiche al servizio. Tuttavia, questa operazione potrebbe richiedere più tempo, a seconda del numero di cluster. Nessuna strategia di upgrade è la migliore. Spesso vengono utilizzate più strategie di implementazione e rollback a seconda dei requisiti dei servizi distribuiti. L'aspetto 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à aziendale si riferisce alla continuazione dei servizi critici in caso di evento importante (pianificato o non pianificato), mentre il ripristino di emergenza si riferisce alle misure adottate o necessarie per ripristinare lo stato normale delle operazioni aziendali dopo questi eventi. Esistono molte strategie per il BCDR che esulano dall'ambito di questo documento. Il BCDR richiede un certo livello di ridondanza in sistemi e servizi. La premessa fondamentale dei servizi distribuiti è che questi vengono eseguiti in più località (cluster, zone e regioni).
Le strategie BCDR spesso dipendono dalle strategie di lancio e rollback discusse in precedenza. Ad esempio, se le implementazioni vengono eseguite in modo sfalsato o controllato, l'effetto di un bug o di un push di configurazione errata può essere rilevato tempestivamente senza influire su un numero elevato di utenti. Su larga scala e insieme al ritmo di cambiamento rapido (ad esempio nelle moderne pratiche CI/CD), è normale che non a tutti gli utenti venga offerta la stessa versione di un servizio distribuito. La pianificazione e le strategie del BCDR nei sistemi e nei servizi distribuiti differiscono dalle tradizionali architetture monolitiche. Nei sistemi tradizionali, una modifica viene applicata all'ingrosso, interessando un gran numero di utenti (o forse tutti) e, di conseguenza, è necessario disporre di 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 in modo da interessare solo un numero limitato di utenti.
Gestione del ciclo di vita dei cluster. Come le implementazioni e i rollback controllati, i servizi distribuiti consentono una gestione controllata del ciclo di vita dei cluster. I servizi distribuiti forniscono resilienza a livello di cluster in modo che i cluster possano essere esclusi dalla rotazione per la manutenzione. La gestione del ciclo di vita dei cluster è un principio dei servizi distribuiti che non si applica ai servizi Kubernetes.
La parte restante di questo documento è incentrata sull'aspetto del ciclo di vita dei cluster dei servizi distribuiti.
Gestione del ciclo di vita dei cluster GKE
La gestione del ciclo di vita dei cluster può essere definita come le strategie e la pianificazione necessarie per mantenere un parco risorse integro e aggiornato di cluster Kubernetes senza violare gli SLO di servizio. Con strategie e pianificazione adeguate, la gestione del ciclo di vita dei cluster deve essere di routine e senza problemi.
Questo documento è incentrato 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 delle strategie e della pianificazione per la gestione del ciclo di vita dei cluster, è importante capire cosa costituisce un upgrade del cluster.
Un cluster contiene due componenti: i nodi del piano di controllo e i nodi worker. L'upgrade di un cluster Kubernetes richiede l'upgrade di tutti i nodi 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 della patch. Le release di minore entità avvengono all'incirca ogni tre mesi (trimestrale) e il progetto Kubernetes mantiene i rami di release per le tre release secondarie più recenti. Ciò significa che una release secondaria di Kubernetes risalente a nove mesi prima non è più mantenuta e potrebbe richiedere modifiche all'API quando esegui l'upgrade alla versione più recente. Gli upgrade di Kubernetes
devono essere pianificati con cadenza regolare. Consigliamo di eseguire gli upgrade di GKE pianificati
ogni trimestre oppure ogni due trimestri.
I cluster GKE supportano l'esecuzione di versioni Kubernetes da qualsiasi release secondaria supportata. Sono disponibili almeno due versioni secondarie in un dato momento.
GKE ha i seguenti tipi di disponibilità dei cluster:
- Cluster a zona singola. Un singolo nodo del piano di controllo e tutti i pool di nodi si trovano in un'unica zona all'interno di un'unica regione.
- Cluster multi-zona. Un singolo nodo del piano di controllo si trova in una zona e i pool di nodi si trovano in più zone all'interno di una singola regione.
- Cluster a livello di regione. Più nodi del piano di controllo e pool di nodi in più zone in una singola regione.
GKE è un servizio gestito e offre upgrade automatici sia per i nodi del piano di controllo che per i nodi worker.
Upgrade automatico di GKE
L'upgrade automatico di GKE è una strategia di ciclo di vita dei cluster molto diffusa e spesso utilizzata. L'upgrade automatico di GKE offre un modo completamente gestito per mantenere aggiornati i cluster GKE alle versioni supportate. GKE esegue gli upgrade automatici dei nodi del piano di controllo e dei nodi worker separatamente:
Esegui gli upgrade automatici principali. Per impostazione predefinita, viene eseguito l'upgrade automatico dei nodi del piano di controllo GKE. I cluster a zona singola e multi-zona hanno un piano di controllo unico (nodo del piano di controllo). Durante gli upgrade dei nodi del piano di controllo, i carichi di lavoro continuano a essere eseguiti. Tuttavia, non puoi eseguire il deployment di nuovi carichi di lavoro, modificare carichi di lavoro esistenti o apportare altre modifiche alla configurazione del cluster fino al completamento dell'upgrade.
I cluster a livello di regione hanno più repliche del piano di controllo e viene eseguito l'upgrade di una sola replica alla volta. Durante l'upgrade, il cluster rimane ad alta disponibilità e ogni replica del piano di controllo non è disponibile solo durante l'upgrade.
Upgrade automatici dei nodi worker. L'upgrade dei pool di nodi viene eseguito uno alla volta. All'interno di un pool di nodi, viene eseguito l'upgrade dei nodi uno alla volta in un ordine indefinito. 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 configurazioni dei carichi di lavoro.
Strategia del ciclo di vita di upgrade automatico di GKE
Consigliamo di utilizzare l'upgrade automatico di GKE, ove possibile. Gli upgrade automatici di GKE danno la priorità alla comodità rispetto al controllo. Tuttavia, gli upgrade automatici di GKE offrono molti modi per influenzare quando e come viene eseguito l'upgrade dei cluster entro determinati parametri. Puoi influenzare i periodi di manutenzione e le esclusioni di manutenzione. I canali di rilascio influiscono sulla selezione della versione e le strategie di upgrade dei nodi influenzano l'ordine e le tempistiche degli upgrade dei nodi. Nonostante questi controlli e cluster regionali (con più piani di controllo 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 una o più delle seguenti opzioni:
- Controllo della versione esatta dei cluster GKE.
- Controlla l'ora esatta per l'upgrade di GKE.
- Controlla la strategia di upgrade (trattata nella sezione successiva) per il tuo parco risorse GKE.
Gestione del ciclo di vita multi-cluster 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 parlare di queste strategie, è importante discutere di alcune decisioni di progettazione che potrebbero influire o essere influenzate dalla strategia di gestione del ciclo di vita dei 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 a livello di regione hanno più nodi del piano di controllo in cui viene eseguito l'upgrade automatico dei nodi uno alla volta, mentre i cluster di zona hanno un singolo nodo del piano di controllo. Se non utilizzi l'upgrade automatico di GKE e consideri tutti i cluster Kubernetes come infrastrutture monouso, potrebbe non essere importante il tipo di cluster che scegli quando decidi una strategia di gestione del ciclo di vita dei cluster. Puoi applicare le strategie descritte nella sezione successiva, Gestione del ciclo di vita multi-cluster di GKE a qualsiasi tipo di cluster.
Posizionamento e utilizzo del cluster
Considera i seguenti fattori quando decidi il posizionamento e l'utilizzo del cluster:
- Zone e regioni in cui i cluster devono trovarsi.
- Numero e dimensione dei cluster necessari.
Il primo fattore di solito è facile da gestire perché le zone e le regioni sono dettate dalla tua attività e dalle regioni in cui servi i tuoi utenti.
Gestire il numero e le dimensioni dei cluster in genere rientra nelle seguenti categorie, ciascuna 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 a livello di regione di grandi dimensioni per regione. Il vantaggio di questo approccio è il basso overhead operativo della gestione di più cluster. Lo svantaggio è che può interessare 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 servizi sono suddivisi in più cluster. Questo approccio funziona bene anche per i cluster temporanei di breve durata, ad esempio quelli che eseguono un carico di lavoro batch. Lo svantaggio di questo approccio è l'overhead operativo più elevato, perché i cluster devono essere aggiornati. Potrebbero esserci costi aggiuntivi associati a un numero maggiore di nodi del piano di controllo. Puoi compensare i costi e l'overhead operativo elevato con automazione, pianificazione e strategia prevedibili e un attento coordinamento tra i team e i servizi interessati.
Questo documento non consiglia un approccio rispetto all'altro; si tratta di opzioni. In alcuni casi, è possibile scegliere entrambi i pattern di progettazione per diverse categorie di servizi.
Le seguenti strategie funzionano con entrambe le scelte di design.
Pianificazione della capacità
Quando si pianifica la capacità, è importante considerare la strategia di ciclo di vita del cluster scelta. La pianificazione della capacità deve considerare i seguenti normali eventi di carico e manutenzione del servizio:
- Eventi pianificati come gli upgrade dei cluster
- Eventi non pianificati come interruzioni dei cluster, ad esempio push per configurazioni errate e implementazioni errate
Quando pianifichi la capacità, devi prendere in considerazione eventuali interruzioni totali o parziali. Se progetti solo per eventi di manutenzione pianificati, tutti i servizi distribuiti devono avere un cluster aggiuntivo rispetto a quello richiesto, in modo da poter escludere dalla rotazione un cluster alla volta per gli upgrade senza ridurre il servizio. Questo approccio è noto anche come N+1 pianificazione della capacità. Se progetti eventi di manutenzione pianificati e non pianificati, tutti i servizi distribuiti devono avere due (o più) cluster aggiuntivi rispetto al necessario per gestire 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 pianificata. Questo approccio è indicato anche come pianificazione della capacità N+2.
Nelle architetture multi-cluster, vengono spesso utilizzati i termini drening e spilling. Questi termini fanno riferimento al processo di rimozione (o svuotamento) del traffico da un cluster e al reindirizzamento (o trasferimento) del traffico su altri cluster durante gli upgrade e gli eventi di manutenzione. Questo processo si ottiene utilizzando soluzioni di networking come Ingress multi-cluster o altri metodi di bilanciamento del carico. L'uso attento di svuotamento e fuoriuscita è al centro di alcune strategie di gestione del ciclo di vita dei cluster. Durante la pianificazione della capacità, valuta l'idea di svuotare e sversare i dispositivi. Ad esempio, quando viene svuotato un singolo cluster, devi valutare se gli altri cluster hanno capacità sufficiente per gestire il traffico versato aggiuntivo. Altre considerazioni includono capacità sufficiente nella zona o regione o la necessità di inviare traffico a una regione diversa (se utilizzi un singolo cluster a livello di regione per regione). Il seguente diagramma mostra il traffico rimosso (a volte denominato svuotamento di un cluster) da un cluster e inviato a un altro che esegue lo stesso servizio distribuito.
Cluster e servizi distribuiti
La progettazione dei cluster basata su servizi determina che l'architettura del cluster (numero, dimensioni e località) è determinata dai servizi che devono essere eseguiti sui cluster. Pertanto, il posizionamento dei cluster è dettato da dove sono necessari i servizi distribuiti. Quando decidi il posizionamento dei servizi distribuiti, considera quanto segue:
- Requisito per la località. Da quali regioni deve essere gestito il servizio?
- Criticità. Quanto è cruciale la disponibilità di un servizio per l'azienda?
- SLO. Quali sono gli obiettivi del livello di servizio (in genere basati sulla criticità)?
- Resilienza. Quanto deve essere resiliente il servizio? Deve tollerare errori relativi a cluster, a livello di zona o persino a livello di regione?
Quando pianifichi gli upgrade dei cluster, devi considerare il numero di servizi interessati da un singolo cluster quando viene svuotato e devi tenere conto del trasferimento di ciascuno di questi servizi ad altri cluster appropriati. I cluster possono essere a tenant singolo o multi-tenant. I cluster a tenant singolo gestiscono solo un servizio o un prodotto rappresentato da un insieme di servizi. I cluster a tenant singolo non condividono il cluster con altri servizi o prodotti. I cluster multi-tenant possono eseguire molti servizi e prodotti, generalmente partizionati in spazi dei nomi.
Impatto sui team
Un evento cluster non solo influisce sui servizi, ma può anche interessare i team. Ad esempio, il team DevOps potrebbe dover reindirizzare o arrestare le pipeline CI/CD durante l'upgrade del cluster. Analogamente, i team di assistenza possono ricevere avvisi in caso di interruzioni pianificate. Devono essere previsti sistemi di Automation e 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 routine e senza problemi quando tutti i team sono informati.
Tempistica, programmazione e coordinamento
Kubernetes rilascia una nuova versione secondaria ogni trimestre e mantiene le ultime tre release. Devi pianificare con attenzione le tempistiche e la pianificazione degli upgrade dei cluster. Deve essere presente un accordo tra i proprietari dei servizi, gli operatori dei servizi e gli amministratori della piattaforma sulla data di esecuzione di questi upgrade. Quando pianifichi gli upgrade, poniti le seguenti domande:
- Con quale frequenza esegui l'upgrade? L'upgrade viene eseguito ogni trimestre o in base a tempistiche diverse?
- Quando eseguire l'upgrade? L'upgrade viene eseguito all'inizio del trimestre, quando l'attività rallenta o durante altri tempi di inattività dovuti al settore?
- Quando conviene non eseguire l'upgrade? Hai una pianificazione chiara per quando non eseguire l'upgrade? Ad esempio, evita eventi di picco come il Black Friday, il Cyber Monday o le conferenze di alto profilo e altri eventi specifici del settore.
È importante implementare una strategia che sia chiaramente comunicata ai proprietari dei servizi, nonché ai team operativi e di assistenza. Non dovrebbero esserci sorprese e tutti dovrebbero sapere quando e come viene eseguito l'upgrade dei cluster. Ciò richiede un chiaro coordinamento 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, che è responsabile dell'esecuzione sicura e affidabile del servizio. Gli operatori possono essere costituiti da più team, come amministratore dei criteri o della sicurezza, amministratori di rete e team di assistenza.
Tutti devono comunicare durante gli upgrade del cluster per poter intraprendere le azioni appropriate durante 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 non sono stati interessati gli utenti). Per ulteriori informazioni, consulta Risposta agli incidenti.
Strategie del ciclo di vita dei 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 singola strategia non funziona per tutti gli scenari e che è possibile scegliere più strategie per varie categorie di servizi ed esigenze dell'attività.
Upgrade in sequenza
Il seguente diagramma mostra la strategia di upgrade in sequenza.
Con un bilanciatore del carico, viene svuotato il traffico in un cluster GKE e ne viene eseguito l'upgrade. Il carico del traffico svuotato viene trasferito a un cluster GKE diverso.
Tra le strategie illustrate in questo documento, gli upgrade in sequenza sono la più semplice e la più conveniente. Inizi con un numero di cluster n che esegue la versione old_ver (o di produzione attuale). Quindi svuota i cluster m alla volta, dove m è inferiore a n. Puoi quindi eliminare e ricreare i nuovi cluster con la nuova versione o eseguire l'upgrade dei cluster svuotati.
La decisione tra l'eliminazione e l'upgrade di nuovi cluster dipende dalle dimensioni dei cluster e dal fatto che i cluster siano un'infrastruttura immutabile. L'infrastruttura immutabile impone di creare nuovi cluster ed evitare deviazioni impreviste nella configurazione, anziché eseguire l'upgrade costante di un cluster, che potrebbe produrre risultati indesiderati.
Se usi GKE, puoi creare un cluster GKE con un singolo comando o una chiamata API. La nuova strategia per i cluster richiede che l'intera configurazione del cluster (manifest del cluster) sia archiviata all'esterno del cluster, in genere in Git. Puoi quindi utilizzare lo stesso modello di configurazione nel nuovo cluster. Se si tratta di un nuovo cluster, assicurati che le pipeline CI/CD puntino al cluster corretto. Dopo che il cluster è stato configurato correttamente, puoi inviare lentamente il traffico al cluster, monitorando al contempo gli SLO dei servizi.
Il processo viene ripetuto per tutti i cluster. A seconda della pianificazione della capacità, puoi eseguire l'upgrade di più cluster alla volta senza violare gli SLO di servizio.
Se dai priorità alla semplicità e ai costi rispetto alla resilienza, utilizza la strategia di upgrade in sequenza. Con questa strategia, non supererai mai la capacità richiesta del parco risorse GKE per tutti i servizi distribuiti.
Il seguente diagramma mette a confronto 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 il 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 escluso dalla rotazione, viene fatto lo scale up degli altri cluster 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. Quindi viene utilizzato un bilanciatore del carico per inviare traffico al nuovo cluster, svuotando lentamente uno dei vecchi cluster finché non viene inviato alcun traffico. Il vecchio cluster completamente svuotato può essere rimosso. Puoi seguire lo stesso processo per i cluster rimanenti.
La strategia di upgrade blu/verde fornisce una maggiore resilienza.
Questa strategia è simile agli upgrade in sequenza, ma è più costosa. L'unica
differenza è che, invece di svuotare prima i cluster esistenti, crei prima nuovi cluster m con la versione, dove m è
minore o uguale a n. Aggiungi i nuovi cluster alle pipeline CI/CD e poi versa lentamente il traffico durante il monitoraggio degli SLO del servizio. Quando i nuovi cluster assumono completamente il traffico, svuota ed elimini i cluster con la versione precedente.
La strategia blu/verde per l'upgrade dei cluster è simile a una strategia blu/verde solitamente utilizzata per i servizi. La creazione di più nuovi cluster alla volta aumenta il costo complessivo, ma ti offre il vantaggio di accelerare i tempi di upgrade del parco risorse. Il costo aggiuntivo si applica solo per la durata dell'upgrade, quando vengono utilizzati cluster aggiuntivi. Il vantaggio della creazione di nuovi cluster è che, in caso di errore, puoi eseguire il rollback. Puoi anche testare il nuovo cluster prima di inviargli traffico di produzione. Poiché questi cluster coesistono con le controparti della vecchia versione per un breve periodo di tempo, i costi aggiuntivi sono minimi.
Se attribuisci la priorità alla semplicità e alla resilienza rispetto al costo, utilizza la strategia di upgrade blu/verde. Vengono aggiunti prima cluster aggiuntivi 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 oltre la 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 svuotati), la capacità torna a quella necessaria. Questa modifica della capacità è evidenziata perché potrebbe esserci un aumento dei costi con questo modello, a seconda del numero e delle dimensioni dei cluster nel parco risorse.
Upgrade canary dei cluster
L'upgrade di un cluster canary è la strategia più resiliente e complessa tra quelle esaminate in questo documento. Questa strategia astrae completamente la gestione del ciclo di vita dei cluster dalla gestione del ciclo di vita dei servizi, offrendo così il rischio minimo e la massima resilienza per i servizi. Nelle precedenti strategie di upgrade in sequenza e blu/verde, mantieni l'intero parco risorse GKE su un'unica versione. In questa strategia, gestisci due o forse tre gruppi di cluster GKE che eseguono versioni diverse. Anziché eseguire l'upgrade dei cluster, nel tempo esegui la migrazione dei servizi da un parco risorse all'altro. Una volta svuotato il parco risorse GKE meno recente (ossia è stata eseguita la migrazione di tutti i servizi al successivo parco risorse GKE con controllo delle versioni), viene eliminato.
Questa strategia richiede che tu mantenga almeno due parchi risorse GKE: uno per l'ambiente di produzione attuale e uno per la successiva versione candidata alla produzione. Puoi anche gestire più di due parchi risorse GKE. I parchi risorse extra offrono maggiore flessibilità, ma anche i costi e i costi operativi. Questi parchi risorse aggiuntivi non sono la stessa cosa che 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 di upgrade dei cluster canary richiede di mantenere più versioni del parco risorse GKE nell'ambiente di produzione. È un approccio simile alle strategie di versione canary usate spesso dai Servizi. Con i deployment di un servizio canary, il proprietario del servizio può sempre individuare i problemi di una determinata versione del servizio. Con i cluster canary, il proprietario del servizio deve tenere conto anche delle versioni del parco risorse GKE su cui sono in esecuzione i suoi servizi. Una singola versione di un servizio distribuito può essere eseguita su più versioni del parco risorse GKE. La migrazione di un servizio può avvenire gradualmente, di modo che tu possa vederne gli effetti sul nuovo parco risorse prima di inviare tutto il traffico per il servizio ai nuovi cluster sottoposti al controllo delle versioni.
Il seguente diagramma mostra che la gestione di diversi parchi risorse di cluster GKE può astrarre completamente il ciclo di vita del cluster dal ciclo di vita dei servizi.
Il diagramma precedente mostra la migrazione graduale di un servizio distribuito frontend da un parco risorse GKE a quello successivo che esegue la nuova versione fino a quando il parco risorse precedente non viene completamente svuotato nel tempo. Dopo lo svuotamento, il parco risorse può essere rimosso e viene creato un nuovo parco risorse. Tutti i servizi vengono migrati al parco risorse successivo, rimuovendo quelli meno recenti quando vengono svuotati.
Se consideri la resilienza più di tutto, utilizza la strategia di upgrade dei cluster canary.
Scegli una strategia di upgrade
Il seguente diagramma può aiutarti a determinare la strategia migliore per te in base al servizio e alle esigenze aziendali.
Il diagramma precedente è un albero decisionale che ti consente di scegliere la strategia di upgrade più adatta a te:
- Se non hai bisogno del controllo completo sulla versione e sull'ora esatte dell'upgrade, puoi scegliere la funzionalità di upgrade automatico disponibile in GKE.
- Se la tua priorità è un costo basso, puoi scegliere la strategia di upgrade in sequenza.
- Se la tua priorità è bilanciare costo e resilienza, puoi scegliere la strategia blu/verde.
- Se la tua priorità è 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 ogni strategia dipende dalla capacità di svuotare e reinstradare il traffico ad 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 Cloud per cluster GKE che supporta il deployment di risorse di bilanciamento del carico condivise in cluster e tra regioni. Ingress multi-cluster è una soluzione per indirizzare il traffico client a un servizio distribuito in esecuzione in molti cluster in molte 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, ovvero servizi Kubernetes in esecuzione su più cluster GKE. Per il traffico da Service-to-Service tra i cluster, puoi utilizzare tecnologie mesh di servizi come Cloud Service Mesh o Istio, che forniscono funzionalità simili nei servizi distribuiti.
Per gli ambienti multi-cluster GKE, 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 di GKE utilizzando la strategia blu/verde.
Passaggi successivi
- Scopri di più su Ingress multi-cluster.
- Scopri come eseguire il deployment di Ingress multi-cluster in più cluster.