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, come ad esempio la configurazione manuale di un bilanciatore del carico esterno. Questo documento è accompagnato da un tutorial 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 fleet per i cluster GKE.
La necessità di un'architettura multi-cluster
Questa sezione illustra diversi motivi per cui potresti aver bisogno di un'architettura Kubernetes multi-cluster.
Kubernetes come infrastruttura
Questo documento considera i cluster Kubernetes come componenti dell'infrastruttura. L'infrastruttura è usa e getta. Non è necessario alcun trattamento speciale per i componenti dell'infrastruttura perché hanno uno scopo. Lo scopo di Kubernetes è fornire automazione e orchestrazione a sviluppatori e operatori per offrire 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 come infrastruttura, esistono diversi motivi per avere un ambiente multicluster:
- Geografia. Molti servizi devono essere in più regioni. Posizionare un servizio più vicino al consumatore (nella sua regione) offre un'esperienza migliore grazie a una latenza inferiore rispetto a un servizio pubblicato da una singola regione. Un cluster Kubernetes viene eseguito in un'unica regione. Per i deployment in più regioni, sono necessari più cluster Kubernetes in più regioni. Anche gli ambienti multi-cloud o cloud ibrido richiedono più cluster in ogni ambiente. Inoltre, i cluster Kubernetes sono spesso colocalizzati con le origini dati (con stato) dei servizi. Per alcune applicazioni potrebbe essere necessario che si trovino nella stessa posizione (regione e zona) del backend, ad esempio un sistema di gestione di database relazionali (RDBMS).
- Diritti di proprietà ed ambienti. I cluster Kubernetes sono progettati per il multitenancy. Più team possono condividere un singolo cluster per i rispettivi servizi. Kubernetes fornisce risorse standard, come gli spazi dei nomi, controllo dell'accesso basato sui ruoli (RBAC), i criteri di rete e l'autenticazione, per configurare correttamente i controlli dell'accesso negli ambienti multi-tenant. In alcuni casi, alcuni servizi potrebbero non essere in grado di coesistere in un cluster con altri servizi a causa di norme aziendali, sulla privacy, sulla sicurezza o normative di settore. In questi casi, sono necessari più cluster per separare determinati tenant nei propri cluster. Spesso gli ambienti (sviluppo, gestione temporanea e produzione) vengono creati anche come cluster separati. L'ambito di accesso e i tipi di applicazioni installate in ambienti diversi variano notevolmente e devono essere mantenuti come cluster distinti.
- Composizione e funzione. A volte viene creato un cluster per eseguire una determinata 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 ai fini dei carichi di lavoro di analisi batch. Questi requisiti hardware potrebbero non essere applicati ad altri servizi. Questi flussi di lavoro potrebbero non essere fondamentali per la gestione dell'attività e possono richiedere cluster effimeri (cluster di breve durata). I servizi condivisi, come l'osservabilità (registrazione, metriche e tracce) e gli strumenti CI/CD, sono più adatti al proprio cluster di amministrazione della piattaforma. Spesso vengono utilizzati cluster specifici per funzione per i flussi di lavoro non fondamentali per l'attività.
- Resilienza. Spesso vengono utilizzati più cluster per aumentare la resilienza in un ambiente. Ogni cluster ha un'area di impatto. In questo contesto, un'area di impatto è il numero di servizi interessati negativamente a causa di un malfunzionamento del cluster, di una configurazione errata o del passaggio offline del cluster a causa di una manutenzione pianificata o non pianificata. Se hai un numero elevato di cluster di dimensioni ridotte, hai un numero elevato di aree di impatto di dimensioni ridotte. Se un servizio esiste in due cluster, i cluster condividono il carico in modo uguale. Se un cluster diventa offline, il 50% del traffico è interessato. Se lo stesso servizio fosse fornito da un singolo cluster, qualsiasi evento su quel cluster causerebbe un'interruzione del 100% del servizio. Per questo motivo, spesso vengono utilizzati anche più cluster per il ripristino di emergenza.
Questo documento si concentra sull'aspetto della resilienza dei deployment multi-cluster.
Servizi multi-cluster e distribuiti
Un servizio distribuito è un servizio Kubernetes di cui viene 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 legati al cluster Kubernetes su cui vengono eseguiti. Se un cluster Kubernetes viene messo offline, lo stesso vale per il servizio Kubernetes. I servizi distribuiti sono astrazioni dei singoli cluster Kubernetes. Se uno o più cluster Kubernetes sono inattivi, il servizio distribuito potrebbe essere online e rientrare nell'obiettivo del livello di servizio (SLO).
Nel seguente diagramma, frontend è un servizio distribuito in esecuzione su più cluster con lo stesso nome e spazio dei nomi.
Con questa architettura, il servizio frontend non è legato a un singolo cluster
e viene rappresentato concettualmente nel diagramma come un livello che si estende al livello di infrastruttura del cluster Kubernetes. Se uno dei singoli cluster su cui è in esecuzione il servizio frontend si arresta, frontend rimane online.
Esistono altri servizi in esecuzione su singoli cluster: accounts
Service e ledger Service. Il loro tempo di attività e la loro disponibilità dipendono dal tempo di attività del cluster Kubernetes su cui si trovano.
La resilienza è uno dei motivi per cui vengono eseguiti i deployment multicluster. I servizi distribuiti creano servizi resilienti su un'architettura multi-cluster. I servizi senza stato sono i candidati ideali per i servizi distribuiti in un ambiente multi-cluster. Quando lavori con i 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 di ingresso multi-cluster come Ingresso multi-cluster o utilizzando il tuo bilanciatore del carico o la tua soluzione proxy esterni. Qualsiasi opzione tu utilizzi, deve darti il controllo su quando, dove e quanto viene indirizzato il traffico 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 strumenti per misurare gli SLO, in genere disponibilità e latenza, collettivamente per un servizio distribuito. Questa configurazione fornisce una visione globale del rendimento di ciascun 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 le metriche dei singoli servizi Kubernetes. Soluzioni come Cloud Monitoring o strumenti open source come Grafana forniscono metriche dei servizi Kubernetes. Le soluzioni di mesh di servizi come Istio e Cloud Service Mesh forniscono anche metriche dei servizi senza alcuna strumentazione richiesta.
Posizionamento del servizio. I servizi Kubernetes forniscono tolleranza ai guasti a livello di nodo all'interno di un singolo cluster Kubernetes. Ciò significa che un servizio Kubernetes può resistere alle interruzioni dei nodi. Durante le interruzioni del servizio dei nodi, un nodo del piano di controllo Kubernetes riprogramma automaticamente i pod su nodi integri. Un servizio distribuito offre tolleranza di errore a livello di cluster. Ciò significa che un servizio distribuito può resistere alle interruzioni del cluster. Quando pianifichi la capacità per un servizio distribuito, devi prendere in considerazione il posizionamento del servizio. Un servizio distribuito non deve essere eseguito su ogni cluster. I cluster su cui viene eseguito un servizio distribuito dipendono dai seguenti requisiti:
- Dove o in quali regioni è richiesto il servizio?
- Qual è lo SLO richiesto per il servizio distribuito?
- Quale tipo di tolleranza ai guasti è richiesta per il servizio distribuito: cluster, zonale o regionale? Ad esempio, hai bisogno di più cluster in un'unica zona o di più cluster in più zone in una o più regioni?
Quale livello di interruzioni deve sopportare il servizio distribuito nel peggiore dei casi? Al livello del cluster sono disponibili le seguenti opzioni:
- N+1 (dove N rappresenta il numero di cluster necessari per soddisfare le esigenze di capacità del servizio). Un servizio distribuito può resistere a un singolo errore del cluster
- N+2. Un servizio distribuito può resistere a due errori contemporaneamente. Ad esempio, un'interruzione pianificata e una non pianificata di un servizio Kubernetes in due cluster contemporaneamente.
Implementazioni e rollback. I servizi distribuiti, come i servizi Kubernetes, consentono implementazioni e rollback graduali. A differenza dei servizi Kubernetes, i servizi distribuiti consentono ai cluster di essere un'unità di deployment aggiuntiva come mezzo per apportare modifiche graduali. Anche i rollout e i rollback dipendono dal requisito del servizio. In alcuni casi, ad esempio per correggere un bug, potrebbe essere necessario eseguire l'upgrade del servizio su tutti i cluster contemporaneamente. In altri casi, potrebbe essere necessario implementare lentamente (o suddividere) la modifica un cluster alla volta. Questo implementazione graduale riduce il rischio per il servizio distribuito introducendo gradualmente modifiche al servizio. Tuttavia, l'operazione potrebbe richiedere più tempo a seconda del numero di cluster. Non esiste una strategia di upgrade migliore. Spesso vengono utilizzate più strategie di implementazione e di rollback a seconda dei requisiti del servizio distribuito. Il punto importante è che i servizi distribuiti devono consentire modifiche graduali e controllate nell'ambiente.
Continuità aziendale e ripristino di emergenza (BCDR). Questi termini vengono spesso utilizzati insieme. La continuità aziendale si riferisce alla prosecuzione dei servizi critici in caso di un evento grave (previsto o imprevisto), mentre il ripristino di emergenza si riferisce alle misure adottate o necessarie per riportare le operazioni aziendali al loro stato normale dopo questi eventi. Esistono molte strategie per la BCDR che non rientrano nell'ambito di questo documento. Il BCDR richiede un certo livello di ridondanza nei sistemi e nei servizi. Il presupposto fondamentale dei servizi distribuiti è che vengono eseguiti in più località (cluster, zone e regioni).
Le strategie di BCDR dipendono spesso dalle strategie di implementazione e rollback discusse in precedenza. Ad esempio, se le implementazioni vengono eseguite in modo graduale o controllato, l'effetto di un bug o di un push di configurazione errato può essere rilevato in anticipo senza che venga interessato un numero elevato di utenti. Su larga scala e in combinazione con un rapido tasso di cambiamento (ad esempio nelle pratiche CI/CD moderne), è normale che non a tutti gli utenti venga fornita la stessa versione di un servizio distribuito. La pianificazione e le strategie di BCDR nei sistemi e nei servizi distribuiti sono diverse dalle architetture monolitiche tradizionali. Nei sistemi tradizionali, una modifica viene apportata in blocco, influendo su un numero elevato di utenti o forse su tutti, pertanto è necessario disporre di un sistema di riserva o di backup in caso di effetti indesiderati di un implementazione. Nei sistemi e nei servizi distribuiti, quasi tutte le modifiche vengono apportate in modo graduale per interessare solo un numero limitato di utenti.
Gestione del ciclo di vita dei cluster. Come i rollout e i rollback controllati, i servizi distribuiti consentono la gestione del ciclo di vita del cluster controllata. I servizi distribuiti offrono resilienza a livello di cluster, pertanto i cluster possono essere rimossi dalla rotazione per la manutenzione. La gestione del ciclo di vita del cluster è un principio dei servizi distribuiti che non si applica ai servizi Kubernetes.
Il resto di questo documento si concentra sull'aspetto del ciclo di vita del cluster dei servizi distribuiti.
Gestione del ciclo di vita dei cluster GKE
La gestione del ciclo di vita del cluster può essere definita come le strategie e la pianificazione necessarie per mantenere un parco di cluster Kubernetes aggiornato e in buono stato senza violare gli SLO del servizio. Con strategie e pianificazione adeguate, la gestione del ciclo di vita dei cluster dovrebbe essere ordinaria, 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 di strategie e pianificazione per la gestione del ciclo di vita del cluster, è importante capire che cos'è un upgrade del cluster.
Un cluster contiene due componenti: i nodi del piano di controllo e i nodi worker. Un upgrade del cluster Kubernetes richiede l'upgrade di tutti i nodi alla stessa versione. Kubernetes segue uno schema di versionamento semantico.
Le versioni di Kubernetes
vengono espresse come X.Y.Z:, dove X è la versione principale, Y è la versione secondaria e Z è la versione patch. Le release secondarie vengono rilasciate ogni circa tre mesi (trimestrali) e il progetto Kubernetes gestisce i branch di release per le tre release secondarie più recenti. Ciò significa che una release secondaria di Kubernetes di nove mesi fa non è più supportata 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 pianificati di GKE trimestralmente o ogni due trimestri.
I cluster GKE supportano l'esecuzione di versioni Kubernetes di qualsiasi release secondaria supportata. In un determinato momento sono disponibili almeno due versioni minori.
GKE offre i seguenti tipi di disponibilità del cluster:
- Cluster a zona singola. Un singolo nodo del piano di controllo e tutti i pool di nodi si trovano in una singola zona di una singola regione.
- Cluster multizonali. Un singolo nodo del piano di controllo si trova in una zona e i pool di nodi si trovano in più zone di una singola regione.
- Cluster a livello di regione. Più nodi e pool di nodi del piano di controllo in più zone di una singola regione.
GKE è un servizio gestito e offre upgrade automatici sia per i nodi del piano di controllo sia per i nodi worker.
Aggiornamento automatico di GKE
L'upgrade automatico GKE è una strategia di ciclo di vita del cluster molto utilizzata e apprezzata. L'upgrade automatico di GKE offre un modo completamente gestito per mantenere aggiornati i cluster GKE alle versioni supportate. Gli upgrade automatici di GKE eseguono l'upgrade dei nodi del piano di controllo e dei nodi worker distintamente:
Gestisci gli upgrade automatici. Per impostazione predefinita, viene eseguito automaticamente l'upgrade dei nodi del piano di controllo GKE. I cluster di una sola zona e multi-zona hanno un unico 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 finché l'upgrade non è completato.
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 automatico 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 contemporaneamente, ma questa procedura può richiedere diverse ore a seconda del numero di nodi e delle relative configurazioni dei carichi di lavoro.
Strategia di ciclo di vita dell'upgrade automatico di GKE
Ti consigliamo di utilizzare l'upgrade automatico di GKE, se possibile. Gli upgrade automatici di GKE danno la priorità alla praticità rispetto al controllo. Tuttavia, gli upgrade automatici di GKE offrono molti modi per influire su quando e come viene eseguito l'upgrade dei cluster entro determinati parametri. Puoi influire sui periodi di manutenzione e sulle esclusioni di manutenzione. I canali di rilascio influiscono sulla selezione delle versioni e le strategie di upgrade dei nodi influiscono sull'ordine e sulla tempistica degli upgrade dei nodi. Nonostante questi controlli e i cluster regionali (con più piani di controllo Kubernetes), l'upgrade automatico di GKE non garantisce il tempo di attività 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 eseguire l'upgrade di GKE.
- Controlla la strategia di upgrade (discussa nella sezione successiva) per il tuo parco GKE.
Gestione del ciclo di vita multi-cluster di GKE
Questa sezione descrive varie strategie di gestione del ciclo di vita dei cluster GKE multi-cluster e come pianificarle.
Considerazioni su pianificazione e progettazione
L'architettura multi-cluster di GKE ha un ruolo nella selezione di una strategia di gestione del ciclo di vita dei cluster. Prima di discutere queste strategie, è importante discutere alcune decisioni di progettazione che potrebbero influire sulla strategia di gestione del ciclo di vita dei cluster o essere influenzate da essa.
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, per i quali viene eseguito l'upgrade automatico 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, il tipo di cluster scelto 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 di GKE a qualsiasi tipo di cluster.
Posizionamento e impronta del cluster
Quando decidi il posizionamento e l'impronta del cluster, prendi in considerazione i seguenti fattori:
- Zone e regioni in cui devono trovarsi i cluster.
- Numero e dimensioni dei cluster necessari.
Il primo fattore è in genere facile da gestire perché le zone e le regioni sono predeterminate dalla tua attività e dalle regioni in cui servi i tuoi utenti.
Il numero e le dimensioni dei cluster rientrano in genere 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 regionali e posizionare uno (o due) cluster regionali di grandi dimensioni per regione. Il vantaggio di questo approccio è l'onere operativo ridotto della gestione di più cluster. Lo svantaggio è che può interessare contemporaneamente un numero elevato di servizi a causa della sua vasta area di impatto.
- Numero elevato di piccoli cluster. Puoi creare un numero elevato di piccoli cluster per ridurre l'area di impatto del cluster, in quanto i servizi sono suddivisi in molti cluster. Questo approccio è ideale 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 più elevato perché sono presenti più cluster da eseguire l'upgrade. Inoltre, possono 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 all'altro; si tratta di opzioni. In alcuni casi, puoi scegliere entrambi i pattern di design 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 di ciclo di vita del cluster scelta. La pianificazione della capacità deve prendere in considerazione i seguenti eventi di carico e manutenzione del servizio normale:
- Eventi pianificati come gli upgrade dei cluster
- Eventi imprevisti come interruzioni del cluster, ad esempio push di configurazione e implementazioni errati
Quando pianifichi la capacità, devi prendere in considerazione eventuali interruzioni totali o parziali. Se la progettazione avviene solo per eventi di manutenzione pianificata, tutti i servizi distribuiti devono avere un cluster in più rispetto a quello necessario per poter rimuovere un cluster alla volta dalla rotazione per gli upgrade senza degradare il servizio. Questo approccio è noto anche 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 fornire la capacità prevista: uno per l'evento pianificato e uno per un evento non pianificato nel caso in cui si verifichi durante la periodo di manutenzione pianificata. Questo approccio è anche conosciuto come pianificazione delle capacità N+2.
Nelle architetture multi-cluster, spesso vengono utilizzati i termini svuotamento e sversamento. Questi termini si riferiscono al processo di rimozione (o svuotamento) del traffico da un cluster e di reindirizzamento (o sversamento) del traffico su altri cluster durante gli upgrade e gli eventi di manutenzione. Questa procedura viene eseguita utilizzando soluzioni di rete come Ingress multi-cluster o altri metodi di bilanciamento del carico. L'uso attento di svuotamento e sversamento è alla base di alcune strategie di gestione del ciclo di vita dei cluster. Quando pianifichi la capacità, devi considerare il drenaggio e lo sversamento. Ad esempio, quando un singolo cluster è esaurito, devi valutare se gli altri cluster hanno una capacità sufficiente per gestire il traffico aggiuntivo. Altri fattori da considerare includono una capacità sufficiente nella zona o nella regione o la necessità di inviare traffico a una regione diversa (se utilizzi un singolo cluster regionale per regione). Il seguente diagramma mostra il traffico che viene rimosso (a volte definito svuotamento di un cluster) da un cluster e inviato a un altro cluster che esegue lo stesso servizio distribuito.
Cluster e servizi distribuiti
La progettazione dei cluster basata sui servizi prevede che l'architettura del cluster (numero, dimensioni e posizione) sia determinata dai servizi che devono essere eseguiti sui cluster. Pertanto, il posizionamento dei cluster è dettato dalla necessità di avere i servizi distribuiti. Tieni presente quanto segue quando decidi il posizionamento dei servizi distribuiti:
- Requisito relativo alla località. In quali regioni deve essere fornito 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 guasti a livello di cluster, zonale o addirittura regionale?
Quando pianifichi gli upgrade dei cluster, devi considerare il numero di servizi interessati da un singolo cluster quando viene svuotato e devi tenere conto dello svuotamento di ciascuno di questi servizi in altri cluster appropriati. I cluster possono essere mono-o multi-tenant. I cluster monoutente pubblicano un solo servizio o un prodotto rappresentato da un insieme di servizi. I cluster monoutente non condividono il cluster con altri servizi o prodotti. I cluster multi-tenant possono eseguire molti prodotti e servizi che in genere sono suddivisi in spazi dei nomi.
Impatto sui team
Un evento di cluster non influisce solo sui servizi, ma può avere ripercussioni anche sui team. Ad esempio, il team DevOps potrebbe dover reindirizzare o interrompere le pipeline CI/CD durante un upgrade del cluster. Analogamente, i team di assistenza possono ricevere avvisi per le interruzioni pianificate. È necessario implementare l'Automation e gli strumenti per ridurre l'impatto su più team. Un upgrade di un cluster o di un parco risorse di cluster deve essere considerato come normale e senza problemi se tutti i team sono informati.
Tempistiche, pianificazione e coordinamento
Kubernetes rilascia una nuova versione secondaria trimestralmente e gestisce le ultime tre release. Devi pianificare attentamente i tempi e la programmazione degli upgrade dei cluster. Deve essere stipulato un accordo tra i proprietari, gli operatori e gli amministratori della piattaforma sui tempi di esecuzione di questi upgrade. Quando pianifichi gli upgrade, poniti le seguenti domande:
- Con quale frequenza esegui l'upgrade? Esegui l'upgrade ogni trimestre o con un altro piano?
- Quando esegui l'upgrade? Esegui l'upgrade all'inizio del trimestre quando l'attività rallenta o durante altri periodi di inattività dell'attività dovuti al tuo settore?
- Quando non dovresti eseguire l'upgrade? Hai una pianificazione chiara su quando non eseguire l'upgrade, ad esempio evitando eventi di picco come il Black Friday, il Cyber Monday o durante conferenze di alto profilo e altri eventi specifici del settore.
È importante adottare una strategia comunicata chiaramente ai proprietari di servizi, nonché ai team di operazioni e assistenza. Non deve esserci nessuna sorpresa e tutti devono sapere quando e come viene eseguito l'upgrade dei cluster. Ciò richiede un coordinamento chiaro con tutti i team coinvolti. Un singolo servizio ha più team che interagiscono con esso. In genere, questi team possono essere agrupati nelle seguenti categorie:
- Lo sviluppatore di servizi, che è responsabile della creazione e della programmazione della logica di business in un servizio.
- L'operatore del servizio, che è responsabile del funzionamento sicuro e affidabile del servizio. Gli operatori possono essere costituiti da più team, come amministratori di criteri o di sicurezza, amministratori di reti e team di assistenza.
Tutti devono essere in contatto durante gli upgrade del cluster per poter intraprendere le azioni appropriate in questo periodo. Un approccio è pianificare gli upgrade nello stesso modo in cui pianifichi un incidente di interruzione del servizio. Hai un Incident Commander, una chat room e una reintegrazione (anche se nessun utente è stato interessato). Per ulteriori informazioni, consulta la sezione Risposta agli incidenti.
Strategie di 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 di GKE. È importante tenere presente che una strategia non funziona per tutti gli scenari e che potresti scegliere più strategie per varie categorie di servizi e per le esigenze dell'attività.
Aggiornamenti in sequenza
Il seguente diagramma mostra la strategia di upgrade graduale.
Utilizzando un bilanciatore del carico, viene scaricato tutto il traffico da un cluster GKE e viene eseguito l'upgrade. Il carico del traffico drenato viene trasferito a un altro cluster GKE.
Gli upgrade incrementali sono la strategia più semplice ed economica tra quelle discusse in questo documento. Inizia con n cluster
che eseguono la versione old_ver (o la versione di produzione corrente). Poi svuoti m
cluster alla volta, dove m è inferiore a n. Poi 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 se consideri che i cluster siano un'infrastruttura immutabile. L'infrastruttura immutabile prevede che, anziché eseguire costantemente l'upgrade di un cluster, che potrebbe produrre risultati indesiderati nel tempo, crei nuovi cluster ed eviti qualsiasi deriva della configurazione imprevista.
Se utilizzi GKE, puoi creare un cluster GKE con un singolo comando o una chiamata API. La nuova strategia di cluster richiede che l'intera configurazione del cluster (manifest del cluster) sia archiviata al di fuori del cluster, in genere in Git. Puoi quindi utilizzare lo stesso modello di configurazione nel nuovo cluster. Se si tratta di un nuovo cluster, assicurati che le pipeline CI/CD rimandino al cluster corretto. Dopo aver configurato correttamente il cluster, puoi ritrasferire lentamente il traffico sul cluster monitorando gli SLO dei servizi.
La procedura viene ripetuta per tutti i cluster. A seconda della pianificazione della capacità, puoi eseguire l'upgrade di più cluster contemporaneamente senza violare gli SLO del servizio.
Se preferisci la semplicità e il costo alla resilienza, utilizza la strategia di upgrade graduali. Con questa strategia, non supererai mai la capacità richiesta dal fleet GKE per tutti i servizi distribuiti.
Il seguente diagramma mette a confronto la sequenza temporale e il requisito di capacità di servizio durante un upgrade del cluster GKE in un'architettura multi-cluster.
Il diagramma precedente mostra che durante la procedura di upgrade di GKE, la capacità di supportare i servizi non scende mai al di sotto di quella richiesta. Quando il cluster GKE di cui eseguire l'upgrade viene ritirato dalla rotazione, gli altri cluster vengono sottoposti a scale up 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, svuotando lentamente uno dei vecchi cluster finché non viene inviato alcun traffico. Il vecchio cluster completamente prosciugato può quindi essere rimosso. Puoi seguire la stessa procedura per gli altri cluster.
La strategia di upgrade blu/verde offre una maggiore resilienza.
Questa strategia è simile agli upgrade incrementali, ma è più costosa. L'unica
differenza è che, anziché svuotare prima i cluster esistenti,
crei prima i nuovi cluster m con la versione, dove m è
meno o uguale a n. Aggiungi i nuovi cluster alle pipeline CI/CD e poi trasferisci lentamente il traffico mentre monitori gli SLO di servizio. Quando i nuovi cluster assorbono completamente il traffico, puoi svuotare ed eliminare i cluster con la versione precedente.
La strategia blu/verde per l'upgrade dei cluster è simile a una strategia blu/verde tipicamente utilizzata per i servizi. La creazione di più nuovi cluster contemporaneamente aumenta il costo complessivo, ma offre il vantaggio di velocizzare il tempo 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 in primo luogo è che, in caso di errore, puoi eseguire il rollback. Puoi anche testare il nuovo cluster prima di inviarvi il traffico di produzione. Poiché questi cluster coesistono con le loro controparti della versione precedente per un breve periodo di tempo, i costi aggiuntivi sono minimi.
Se preferisci la semplicità e la resilienza al costo, utilizza la strategia di upgrade blu/verde. I cluster aggiuntivi vengono aggiunti per primi e superano la capacità richiesta del parco GKE per la durata degli upgrade.
Nel diagramma precedente, l'aggiunta di un nuovo cluster aumenta temporaneamente la capacità disponibile rispetto a quella richiesta, mentre un altro cluster nel parco risorse viene svuotato e rimosso dal parco risorse. Tuttavia, dopo aver rimosso uno dei vecchi cluster (completamente esauriti), la capacità torna a essere quella necessaria. Questa variazione di capacità è evidenziata perché con questo modello può verificarsi un aumento del costo, a seconda del numero e delle dimensioni dei cluster nel parco risorse.
Upgrade dei cluster canary
Un upgrade del cluster canary è la strategia più resiliente e complessa tra quelle discusse in questo documento. Questa strategia esegue l'astrazione completa della 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 graduale e blu/verde precedenti, gestivi l'intero parco risorse GKE su una singola versione. In questa strategia, gestisci 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 è svuotato (ovvero è stata eseguita la migrazione di tutti i servizi al successivo parco risorse GKE con versione), elimina il parco risorse.
Questa strategia richiede di gestire almeno due parchi GKE, uno per la produzione attuale e uno per la versione candidata di produzione successiva. Puoi anche gestire più di due parchi GKE. I parchi extra offrono maggiore flessibilità, ma anche i costi e l'overhead operativo aumentano. Questi parchi risorse aggiuntivi non sono come 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 gestione di più versioni del parco risorse GKE nell'ambiente di produzione. Questa strategia è simile alle strategie di versione canary spesso utilizzate dai servizi. Con i deployment dei servizi canari, il proprietario del servizio può sempre individuare i problemi relativi a una determinata versione del servizio. Con i cluster canary, il proprietario del servizio deve anche prendere in considerazione le versioni del parco GKE su cui vengono eseguiti i servizi. Una singola versione del servizio distribuita può essere eseguita su più versioni del parco risorse GKE. La migrazione di un servizio può avvenire gradualmente in modo da poterne vedere gli effetti sul nuovo parco prima di inviare tutto il traffico del servizio ai nuovi cluster con versione.
Il seguente diagramma mostra che la gestione di diversi parchi 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 di cluster GKE a quello successivo che esegue la nuova versione, fino a quando il parco precedente non viene completamente svuotato nel tempo. Una volta svuotato il parco risorse, puoi rimuoverlo e crearne uno nuovo. Tutti i servizi vengono migrati al parco successivo, rimuovendo i parchi precedenti man mano che vengono svuotati.
Se per te la resilienza è più importante di tutto il resto, utilizza la strategia di upgrade del cluster canary.
Scegliere una strategia di upgrade
Il seguente diagramma può aiutarti a determinare qual è 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 e sul momento esatto dell'upgrade, puoi scegliere la funzionalità di upgrade automatico disponibile in GKE.
- Se la tua priorità è il basso costo, puoi scegliere la strategia di upgrade graduale.
- Se la tua priorità è bilanciare costi e resilienza, puoi scegliere la strategia blu/verde.
- Se la tua priorità è la resilienza rispetto al costo, puoi scegliere la strategia di upgrade del cluster canary.
Utilizzo di Ingress multi-cluster per la gestione del ciclo di vita dei cluster GKE
Quasi tutte le strategie dipendono dalla possibilità di scaricare e reindirizzare il traffico verso altri cluster durante gli upgrade. Una soluzione che fornisce questa funzionalità di ingress multi-cluster è Ingress multi-cluster. Ingress multi-cluster è un controller di ingressi multi-cluster ospitato su Google Cloud per 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 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, ovvero servizi Kubernetes in esecuzione su più cluster GKE. Per il traffico tra servizi tra cluster, puoi utilizzare tecnologie di mesh di servizi come Cloud Service Mesh o Istio, che forniscono funzionalità simili tra servizi distribuiti.
Per gli ambienti GKE multi-cluster, puoi utilizzare Ingress multi-cluster per manipolare il traffico verso più cluster per le strategie di gestione del ciclo di vita del cluster discusse in precedenza. Puoi seguire un tutorial sull'utilizzo di Ingress multi-cluster per gli upgrade di GKE utilizzando la strategia blue-green.
Passaggi successivi
- Scopri di più su Ingress multi-cluster.
- Scopri come eseguire il deployment di Ingress multi-cluster in più cluster.