Questo documento descrive come progettare, pianificare e implementare gli upgrade in un ambiente Google Kubernetes Engine (GKE) multi-cluster. Anche se questo documento utilizza Multi cluster Ingress per gli upgrade, i concetti possono essere applicati ad altre soluzioni, ad esempio configurando manualmente un bilanciatore del carico esterno. È disponibile un tutorial correlato 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 gestione 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 è usa e getta. Non deve essere dato un trattamento speciale ai componenti dell'infrastruttura, perché i componenti servono per uno scopo. Lo scopo di Kubernetes è fornire automazione e orchestrazione a sviluppatori e operatori per fornire ai consumatori applicazioni e servizi basati su container. I consumatori possono essere team interni, altri servizi o clienti esterni.
Scenari multi-cluster comuni
Oltre all'argomento Kubernetes-as-infrastruttura, esistono diversi motivi per avere un ambiente multi-cluster:
- Area geografica. Molti Servizi devono trovarsi in più regioni. Collocare un Servizio più vicino al consumatore (nella sua regione) offre un'esperienza migliore grazie a una latenza più bassa 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 richiesti più cluster Kubernetes in più regioni. Gli ambienti cloud multi-cloud o ibridi richiedono anche più cluster in ogni ambiente. I cluster Kubernetes sono spesso colocati con le origini dati (stateful) dei servizi. Alcune applicazioni potrebbe essere necessario che si trovino nella stessa località (regione e zona) del backend, ad esempio un sistema di gestione di database relazionali (RDBMS).
- Tenancy e ambienti. I cluster Kubernetes sono progettati per la multitenancy. 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, determinati Servizi potrebbero non essere in grado di risiedere in un cluster insieme ad 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 diversi ambienti variano enormemente e devono essere conservati come cluster separati.
- Composizione e funzione. A volte, un cluster viene creato per eseguire 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 composti 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 fondamentali per l'esecuzione dell'attività e possono richiedere cluster temporanei (cluster a breve durata). I servizi condivisi, come l'osservabilità (logging, metriche e tracce) e gli strumenti CI/CD, sono più adatti nel proprio cluster di amministrazione della piattaforma. Spesso per flussi di lavoro non business critical cluster separati, specifici per le funzioni.
- 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 interessata è il numero di servizi interessati negativamente a causa di un malfunzionamento del cluster, un errore di configurazione o un cluster che passa offline a causa di una manutenzione pianificata o non pianificata. Se hai un numero elevato di cluster di dimensioni ridotte, significa che hai un numero elevato di aree interessate dalle dimensioni più piccole. Se un servizio è presente in due cluster, questi condividono il carico in modo uguale. Se un cluster è offline, questo influisce sul 50% del traffico. Se lo stesso servizio fosse gestito da un singolo cluster, qualsiasi evento in quel cluster causerebbe un'interruzione del 100% per quel servizio. Per questo motivo, spesso vengono utilizzati 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 è stato eseguito il deployment in più cluster Kubernetes. I servizi distribuiti sono servizi stateless e agiscono in modo identico su 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 passa alla modalità offline, lo stesso vale per 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 all'interno dell'obiettivo del livello di servizio (SLO).
Nel diagramma seguente, frontend è un servizio distribuito in esecuzione su
più cluster con lo stesso nome di servizio e lo stesso spazio dei nomi.
Con questa architettura, il servizio frontend non è legato a un singolo cluster ed è rappresentato concettualmente nel diagramma come un livello che copre il livello dell'infrastruttura del cluster Kubernetes. Se uno dei singoli cluster che eseguono il servizio frontend non funziona, frontend rimane online.
Esistono servizi aggiuntivi in esecuzione su singoli cluster: accounts
Service e ledger Service. Inoltre, la disponibilità e l'uptime dipendono dal tempo di attività del cluster Kubernetes su cui risiedono.
La resilienza è uno dei motivi dei deployment multicluster. I servizi distribuiti creano servizi resilienti in 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 i seguenti requisiti e considerazioni:
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 o utilizzando il tuo bilanciatore del carico esterno o una soluzione proxy. Qualunque sia l'opzione che utilizzi, devi avere il controllo su quando, dove e quanto traffico viene instradato a 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à. Utilizza gli strumenti per misurare i tuoi SLO (di solito disponibilità e latenza) per un servizio distribuito. Questa configurazione offre una visualizzazione globale delle prestazioni di ogni servizio su più cluster. Sebbene un servizio distribuito non sia una risorsa ben definita nella maggior parte delle soluzioni di osservabilità, puoi raccogliere e combinare singole metriche dei servizi Kubernetes. Soluzioni come Cloud Monitoring o strumenti open source come Grafana forniscono metriche di servizio Kubernetes. Anche le soluzioni di mesh di servizi come Istio e Cloud Service Mesh forniscono metriche di servizio senza bisogno di strumentazione.
Posizionamento del servizio. I servizi Kubernetes offrono una tolleranza di errore a livello di nodo all'interno di un cluster Kubernetes. Ciò significa che un servizio Kubernetes può resistere alle interruzioni dei nodi. In caso di interruzioni dei nodi, un nodo del piano di controllo Kubernetes riprogramma automaticamente i pod. Un servizio distribuito offre tolleranza agli errori a livello di cluster. Ciò significa che un servizio distribuito può resistere alle interruzioni dei cluster. Quando pianifichi la capacità per un servizio distribuito, devi considerare questo posizionamento. Non è necessario eseguire un servizio distribuito 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?
- Che tipo di tolleranza agli errori è richiesto per il servizio distribuito: cluster, di zona o a livello di regione? Ad esempio, hai bisogno di più cluster in una singola zona o più cluster in zone in una o più regioni?
Quale livello di interruzioni deve 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à del servizio). Un servizio distribuito è in grado di resistere a un singolo errore di cluster
- N+2. Un servizio distribuito è in grado di tollerare due errori simultanei. un'interruzione pianificata e 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 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 per correggere un bug. In altri casi, potresti dover implementare lentamente (o scaglionare) la modifica di un cluster alla volta. Questa implementazione graduale riduce il rischio per il servizio distribuito introducendo gradualmente 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 lancio e rollback a seconda dei requisiti dei servizi distribuiti. La cosa importante è che i servizi distribuiti devono consentire modifiche graduali e controllate all'ambiente.
Continuità aziendale e ripristino di emergenza (BCDR). Questi termini vengono spesso utilizzati insieme. La continuità aziendale si riferisce alla continuazione di servizi critici in caso di un evento importante (pianificato o non pianificato), mentre il ripristino di emergenza si riferisce ai passaggi eseguiti o necessari per riportare le operazioni aziendali al loro stato normale dopo questi eventi. Esistono molte strategie per la BCDR che esulano dall'ambito di questo documento. Il BCDR richiede un certo livello di ridondanza in sistemi e servizi. Il presupposto fondamentale dei servizi distribuiti è che vengono eseguiti in più località (cluster, zone e regioni).
Le strategie BCDR dipendono spesso dalle strategie di implementazione e rollback discusse in precedenza. Ad esempio, se le implementazioni vengono eseguite in modo scaglionato o controllato, l'effetto di un bug o di un push di configurazione non valido può essere individuato in anticipo senza influire su un gran numero di utenti. Su larga scala e abbinata a un rapido tasso di modifica (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 BCDR in sistemi e servizi distribuiti differiscono dalle architetture monolitiche tradizionali. Nei sistemi tradizionali, una modifica viene applicata globalmente, riguardando molti utenti, o forse tutti, gli utenti, e quindi deve disporre di un sistema ridondante o di backup in caso di effetti indesiderati dell'implementazione. Nei servizi e nei sistemi distribuiti, quasi tutte le modifiche vengono apportate in modo graduale per 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 tolti dalla rotazione per la manutenzione. La gestione del ciclo di vita dei cluster è un principio di 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 del servizio. Con strategie e pianificazione adeguate, la gestione del ciclo di vita del cluster dovrebbe essere regolare, prevista 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: nodi del piano di controllo e nodi worker. Un upgrade del cluster Kubernetes richiede che venga eseguito 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 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 viene più mantenuta e potrebbe richiedere modifiche all'API quando esegui l'upgrade alla versione più recente. Gli upgrade di Kubernetes
devono essere pianificati con una cadenza regolare. Ti consigliamo di eseguire gli upgrade di GKE pianificati trimestralmente o 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 determinato 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 in 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 un'unica regione.
- Cluster a livello di regione. Nodi e pool di nodi del piano di controllo in più zone all'interno di un'unica regione.
GKE è un servizio gestito e offre upgrade automatici sia per i nodi del piano di controllo sia per i nodi worker.
Upgrade automatico di GKE
L'upgrade automatico di GKE è una strategia popolare e spesso utilizzata per il ciclo di vita dei cluster. L'upgrade automatico di GKE offre un modo completamente gestito per mantenere i cluster GKE aggiornati alle versioni supportate. GKE esegue automaticamente l'upgrade dei nodi del piano di controllo e dei nodi worker separatamente:
Controlla gli upgrade automatici. 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 singolo piano di controllo (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 quelli 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 di cui 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, l'upgrade dei nodi viene eseguito uno alla volta in un ordine non definito. Puoi modificare il numero di nodi di cui viene eseguito l'upgrade alla volta, 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
Se possibile, ti consigliamo di utilizzare l'upgrade automatico di GKE. Gli upgrade automatici di GKE danno la priorità alla praticità rispetto al controllo. Tuttavia, gli upgrade automatici di GKE offrono molti modi per influire su quando e come viene eseguito l'upgrade dei cluster entro determinati parametri. Puoi influenzare periodi di manutenzione ed esclusioni di manutenzione. I canali di rilascio influenzano la selezione della versione e le strategie di upgrade dei nodi influiscono sull'ordine e sulle 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 il momento esatto per eseguire l'upgrade di GKE.
- Controlla la strategia di upgrade (spiegata nella prossima sezione) per il tuo parco risorse GKE.
Gestione del ciclo di vita multi-cluster di GKE
Questa sezione descrive varie strategie di gestione del ciclo di vita multi-cluster GKE e come pianificarle.
Considerazioni su pianificazione e progettazione
L'architettura multi-cluster di GKE gioca un ruolo importante 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 del cluster.
Tipo di cluster
Se utilizzi l'upgrade automatico di GKE come strategia di gestione del ciclo di vita dei cluster, il tipo di cluster può essere importante. Ad esempio, i cluster regionali hanno più nodi del piano di controllo in cui i nodi del piano di controllo vengono aggiornati automaticamente 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 se consideri tutti i cluster Kubernetes come infrastruttura usa e getta, 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 prossima sezione 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'impronta del cluster:
- Zone e regioni in cui devono trovarsi i cluster.
- Numero e dimensione dei cluster necessari.
Solitamente il primo fattore è facile da gestire perché le zone e le regioni sono dettate dalla tua azienda e dalle regioni in cui fornisci i tuoi servizi agli utenti.
Gestire il numero e le dimensioni dei cluster in genere ricade 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 a livello di regione di grandi dimensioni per regione. Il vantaggio di questo approccio è il basso overhead operativo derivante dalla gestione di più cluster. Lo svantaggio è che può interessare un numero elevato di servizi contemporaneamente a causa della sua vasta area.
- Numero elevato di cluster di piccole dimensioni. Puoi creare un numero elevato di piccoli cluster per ridurre l'area di impatto del cluster, poiché i tuoi servizi sono suddivisi in molti cluster. Questo approccio funziona bene anche per i cluster temporanei di breve durata (ad esempio, per i cluster che eseguono un carico di lavoro batch). Lo svantaggio di questo approccio è un overhead operativo maggiore perché sono presenti più cluster da aggiornare. Potrebbero anche esserci costi aggiuntivi associati a un numero più elevato di nodi del piano di controllo. Puoi compensare i costi e l'overhead operativo elevato con l'automazione, la pianificazione e la strategia prevedibili e un attento coordinamento tra i team e i servizi interessati.
Questo documento non consiglia un approccio rispetto all'altro, sono opzioni. In alcuni casi, puoi scegliere entrambi i pattern di progettazione per diverse categorie di servizi.
Le seguenti strategie sono efficaci con entrambe le scelte progettuali.
Pianificazione della capacità
Quando pianifichi la capacità, è importante considerare la strategia per il ciclo di vita del cluster scelta. La pianificazione della capacità deve considerare i seguenti normali eventi di carico di servizio e manutenzione:
- Eventi pianificati come gli upgrade dei cluster
- Eventi non pianificati come interruzioni dei cluster, ad esempio push di configurazione e implementazioni non corrette
Nella pianificazione della 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 rimuovere dalla rotazione un cluster alla volta per gli upgrade senza ridurre il servizio. Questo approccio è denominato anche pianificazione delle capacità +1. Se progetti per eventi di manutenzione pianificati e non pianificati, tutti i servizi distribuiti devono disporre di 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 è anche definito Pianificazione delle capacità N+2.
Nelle architetture multi-cluster, vengono spesso utilizzati i termini svuotamento e spilling. Questi termini fanno riferimento al processo di rimozione (o svuotamento) del traffico da un cluster e di reindirizzamento (o versamento) del traffico su altri cluster durante gli upgrade e gli eventi di manutenzione. Questo processo si esegue utilizzando soluzioni di rete come Ingress multi-cluster o altri metodi di bilanciamento del carico. L'uso attento dello svuotamento e del dispersione è al centro di alcune strategie di gestione del ciclo di vita dei cluster. Quando pianifichi la capacità, devi valutare come drenare e versare acqua. Ad esempio, quando un singolo cluster viene svuotato, devi valutare se gli altri cluster abbiano una capacità sufficiente per gestire il traffico sversato aggiuntivo. Altre considerazioni includono capacità sufficiente nella zona o regione o la necessità di inviare il traffico a una regione diversa (se utilizzi un singolo cluster a livello di regione 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 del 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 scegli il posizionamento dei servizi distribuiti, considera quanto segue:
- Requisito di località. Da quali regioni deve essere servito il servizio?
- Criticità. Quanto è cruciale la disponibilità di un servizio per l'attività?
- SLO. Quali sono gli obiettivi del livello del servizio (in genere basati sulla criticità)?
- Resilienza. Quanto deve essere resiliente il servizio? Ha bisogno di resistere a guasti del cluster, 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 il rischio di versare ciascuno di questi servizi negli altri cluster appropriati. I cluster possono essere single-tenant o multi-tenant. I cluster con tenant singolo gestiscono solo un singolo 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, in genere partizionati in spazi dei nomi.
Impatto sui team
Un evento del cluster non solo interessa i servizi, ma può anche avere un impatto sui team. Ad esempio, il team DevOps potrebbe dover reindirizzare o arrestare le proprie pipeline CI/CD durante un upgrade del cluster. Analogamente, i team di assistenza possono ricevere avvisi per le interruzioni pianificate. L'Automation e gli strumenti devono essere in atto per ridurre l'impatto a più team. L'upgrade di un cluster o di un parco risorse di cluster deve essere considerato come routine e privo di problemi quando tutti i team sono informati.
Tempi, pianificazione 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 del cluster. Deve esistere un contratto tra i proprietari dei servizi, gli operatori dei servizi e gli amministratori della piattaforma in merito al momento in cui vengono eseguiti questi upgrade. Quando pianifichi gli upgrade, poniti le seguenti domande:
- Con quale frequenza esegui l'upgrade? Esegui l'upgrade ogni trimestre oppure in una tempistica diversa?
- Quando esegui l'upgrade? Esegui l'upgrade all'inizio del trimestre quando l'azienda rallenta o durante altri periodi di inattività legati al tuo settore?
- Quando non dovresti eseguire l'upgrade? Hai una pianificazione chiara in merito ai momenti in cui non eseguire l'upgrade, ad esempio evita eventi di picco come il Black Friday e il Cyber Monday o durante conferenze di alto profilo e altri eventi specifici del settore.
È importante attuare una strategia che sia comunicata chiaramente con i proprietari del servizio e con i team operativi e di assistenza. Non dovrebbero esserci sorprese e tutti devono 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 vi interagiscono. In genere, questi team possono essere raggruppati nelle seguenti categorie:
- Lo sviluppatore del Servizio, responsabile della creazione e della programmazione della logica di business in un Servizio.
- L'operatore del servizio, che è responsabile dell'esecuzione del Servizio in modo sicuro e affidabile. Gli operatori possono essere composti da più team, ad esempio amministratore dei criteri o della sicurezza, amministratore di rete e team di assistenza.
Tutti devono essere in comunicazione durante gli upgrade del cluster in modo da poter eseguire le azioni corrette durante questo periodo. Un approccio è pianificare gli upgrade nello stesso modo in cui si pianifica un incidente. Puoi usare un incident commander, una chat room e una retrospettiva (anche se nessun utente ha subito il problema). Per ulteriori informazioni, consulta Risposta agli incidenti.
Strategie per il 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 strategia non funziona per tutti gli scenari e che potresti 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.
Mediante un bilanciatore del carico, un cluster GKE viene svuotato di tutto il traffico e eseguito l'upgrade. Il carico del traffico svuotato viene versato su un altro cluster GKE.
Gli upgrade in sequenza sono la strategia più semplice ed economica tra le strategie discusse in questo documento. Inizierai con il numero di cluster n che eseguono la versione old_ver (o di produzione attuale). Quindi svuota m cluster alla volta, dove m è inferiore a n. Quindi elimini e ricrea i 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 i cluster siano un'infrastruttura immutabile. Un'infrastruttura immutabile impone di creare nuovi cluster ed evitare deviazioni impreviste della configurazione, anziché eseguire l'upgrade costante di un cluster.
Se usi 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 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 eseguire lentamente il push del traffico nel cluster durante il monitoraggio degli 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 preferisci la semplicità e il costo piuttosto che la 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 confronta la sequenza temporale e il requisito di capacità del servizio durante l'upgrade di un cluster GKE in un'architettura multi-cluster.
Il diagramma precedente mostra che in tutto il processo di upgrade di GKE, la capacità di supportare i servizi non è mai inferiore a quella richiesta. Quando il cluster GKE di cui eseguire l'upgrade viene rimosso 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, mentre viene svuotato lentamente uno dei cluster precedenti finché non viene inviato traffico. Il vecchio cluster completamente svuotato può quindi essere rimosso. Puoi seguire la stessa procedura 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, invece di svuotare prima i cluster esistenti, crei prima nuovi cluster m con la versione, dove m è inferiore o uguale a n. Devi aggiungere i nuovi cluster alle pipeline CI/CD, quindi
sondare lentamente il traffico durante il monitoraggio degli SLO di servizio. Quando i nuovi cluster assumono completamente il traffico, svuota ed elimini i cluster con la versione precedente.
La strategia blu/verde per eseguire l'upgrade dei cluster è simile a una strategia blu/verde solitamente utilizzata 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 si applica 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 controparti della versione precedente per un breve periodo di tempo, i costi aggiuntivi sono minimi.
Se la semplicità e la resilienza sono più che costi, utilizza la strategia di upgrade blu/verde. Vengono aggiunti prima cluster aggiuntivi che superano la capacità richiesta del parco risorse GKE per la durata degli upgrade.
Nel diagramma precedente, l'aggiunta di un nuovo cluster prima aumenta temporaneamente la capacità disponibile oltre la capacità richiesta, mentre un altro cluster del parco risorse viene svuotato e rimosso dal parco risorse. Tuttavia, dopo la rimozione di uno dei vecchi cluster (completamente svuotati), la capacità torna a quella necessaria. Questa modifica della capacità è evidenziata perché potrebbe verificarsi un aumento dei costi con questo modello, a seconda del numero e delle dimensioni dei cluster nel parco risorse.
Upgrade dei cluster canary
L'upgrade di un cluster canary è la strategia più resiliente e complessa tra quelle trattate in questo documento. Questa strategia astrae completamente la gestione del ciclo di vita dei cluster dalla gestione del ciclo di vita dei servizi, offrendo il rischio più basso e la massima resilienza per i tuoi 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 parchi risorse di cluster GKE che eseguono versioni diverse. Invece di 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 (ovvero che è stata eseguita la migrazione di tutti i servizi al successivo parco risorse GKE sottoposto al controllo delle versioni), il parco risorse viene eliminato.
Questa strategia richiede di mantenere almeno due parchi risorse GKE: uno per la versione di produzione attuale e uno per la prossima versione candidata per la produzione. Puoi inoltre gestire più di due parchi risorse GKE. Altri parchi risorse ti offrono maggiore flessibilità, ma aumentano anche i costi e i costi operativi. 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 upgrade dei cluster canary impone la gestione di più versioni del parco risorse GKE nell'ambiente di produzione. È 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 di una determinata versione del servizio. Nel caso dei cluster canary, il proprietario del servizio deve tenere conto anche delle versioni del parco risorse GKE su cui sono in esecuzione i suoi servizi. Un'unica versione distribuita del servizio può essere eseguita su più versioni del parco risorse GKE. La migrazione di un servizio può avvenire gradualmente, in modo da poter vedere gli effetti del servizio 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 lenta di un servizio distribuito frontend da un parco risorse GKE al parco risorse successivo che esegue la nuova versione fino a quando il parco risorse precedente non viene completamente svuotato nel tempo. Dopo aver svuotato il parco risorse, puoi rimuoverlo e crearne uno nuovo. Viene eseguita la migrazione di tutti i servizi al parco risorse successivo, rimuovendo quelli meno recenti man mano che vengono svuotati.
Se la resilienza è più importante di qualsiasi altra cosa, utilizza la strategia di upgrade del cluster canary.
Scegli una strategia di upgrade
Il seguente diagramma può aiutarti a determinare la strategia migliore per te in base alle esigenze aziendali e relative al servizio.
Il diagramma precedente è un albero decisionale che consente di scegliere la strategia di upgrade più adatta a te:
- Se non hai bisogno del controllo completo sulla versione esatta e sull'ora dell'upgrade, puoi scegliere la funzionalità di upgrade automatico disponibile in GKE.
- Se la tua priorità è bassa, puoi scegliere la strategia di upgrade in sequenza.
- Se la tua priorità è trovare l'equilibrio tra costo e resilienza, puoi scegliere la strategia blu/verde.
- Se la tua priorità è la resilienza rispetto ai costi, 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 ad altri cluster durante gli upgrade. Una soluzione che offre questa funzionalità di Ingress multi-cluster è Ingress multi-cluster. Multi-cluster Ingress è un controller Ingress multi-cluster ospitato da Google Cloud per i cluster GKE che supporta il deployment di risorse di bilanciamento del carico condivise nei cluster e tra regioni. Ingress multi-cluster è una soluzione per ottenere il traffico client verso un servizio distribuito in esecuzione in molti cluster e 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 nei cluster, puoi utilizzare tecnologie mesh di servizi come Cloud Service Mesh o Istio, che forniscono funzionalità simili su 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 con la strategia blu/verde.
Passaggi successivi
- Scopri di più su Ingress multi-cluster.
- Scopri come eseguire il deployment di Ingress multi-cluster nei cluster.