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

Autopilot . . Standard

---

Questo documento descrive come progettare, pianificare e implementare gli upgrade in un multi-cluster dell'ambiente Google Kubernetes Engine (GKE). Anche se questo documento utilizza Ingress multi-cluster per gli upgrade, i concetti possono essere applicati ad altre soluzioni, configurazione manuale di un bilanciatore del carico esterno. C'è un tutorial associato a questo documento che illustra come eseguire l'upgrade di un cluster Ambiente GKE con Ingress multi-cluster. Questo documento è è destinata agli amministratori di Google Cloud responsabili della per i cluster GKE.

La necessità di un'architettura multi-cluster

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

Kubernetes come infrastruttura

Questo documento considera i cluster Kubernetes come componenti dell'infrastruttura. L'infrastruttura è temporanea. Non deve essere dato alcun trattamento speciale a nessun dell'infrastruttura perché i componenti servono a uno scopo. La lo scopo di Kubernetes è fornire agli sviluppatori automazione e orchestrazione 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-infrastructure, esistono vari motivi per avere un ambiente multi-cluster:

• Area geografica. Molti servizi devono essere regioni. Mettere un Servizio più vicino al consumatore (nella sua regione) offre una un'esperienza migliore grazie a una latenza inferiore rispetto a quando il Servizio viene fornito da una in una singola regione. Un cluster Kubernetes viene eseguito in una singola regione. Per deployment multiregionali, più cluster Kubernetes in regioni sono obbligatorie. Anche gli ambienti cloud multi-cloud o ibridi richiedono in più cluster in ogni ambiente. Spesso, i cluster Kubernetes vengono in co-location con i Servizi (stateful). Determinate applicazioni potrebbe essere necessario trovarsi nella stessa località (regione e zona) un backend, ad esempio un sistema di gestione di database relazionali (RDBMS).
• Tenancy e ambienti. I cluster Kubernetes sono progettati l'architettura multi-tenancy. Più team possono condividere un unico cluster per il proprio ai rispettivi Servizi. Kubernetes fornisce risorse standard, spazi dei nomi, controllo dell'accesso basato su ruoli (RBAC), criteri di rete per l'autenticazione, per e configurare i controlli dell'accesso in ambienti multi-tenant. In alcuni casi, alcuni Servizi potrebbero non essere in grado di convivere in un cluster Servizi in conformità a norme aziendali, privacy, sicurezza o normative del settore. In questi casi, sono necessari più cluster per separare determinati tenant nei propri cluster. Ambienti (sviluppo, gestione temporanea e produzione) vengono spesso creati come cluster separati. L'ambito e i tipi di applicazioni installate in ambienti diversi, che deve essere mantenuto come cluster separato.
• Composizione e funzione. A volte viene creato un cluster per eseguire per 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 altro hardware per cluster di istanze composti VM spot per carichi di lavoro di analisi batch. Questi requisiti hardware potrebbero non applicarsi ad altri Servizi. Questi flussi di lavoro potrebbero non essere che eseguono l'attività e possono richiedere cluster temporanei (breve di cluster). I servizi condivisi, come l'osservabilità (logging, metriche e tracce) e gli strumenti CI/CD, sono più adatti all'amministratore di piattaforma in un cluster Kubernetes. Spesso vengono mostrati cluster distinti per funzioni flussi di lavoro non aziendali critici.
• Resilienza. Spesso vengono utilizzati più cluster per aumentare la resilienza in un ambiente. Ogni cluster ha un'area d'impatto. In questo contesto, impatto è il numero di Servizi che subiscono l'impatto a causa di un malfunzionamento o configurazione errata del cluster o perché il cluster diventa offline a causa di manutenzione pianificata o non pianificata. Se hai un gran numero di di grandi dimensioni, ne esiste 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 Il servizio era gestito da un unico cluster, qualsiasi evento su quel cluster poteva causare un'interruzione del 100% per quel servizio. Per questo motivo, vengono utilizzati più cluster spesso utilizzato anche 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 cluster Kubernetes. I servizi distribuiti sono servizi stateless e agiscono in modo identico in più cluster. Ciò significa che un servizio distribuito 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 eseguite. Se un cluster Kubernetes va offline, così anche Kubernetes assistenza. I servizi distribuiti sono astratti dai singoli servizi Kubernetes cluster. Se uno o più cluster Kubernetes non sono attivi, il servizio distribuito online e all'interno 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 è concettualmente rappresentato nel diagramma come uno strato che abbraccia livello dell'infrastruttura del cluster Kubernetes. Se uno dei singoli cluster stanno eseguendo, il servizio frontend non è disponibile, il frontend rimane online. Sono presenti servizi aggiuntivi in esecuzione su singoli cluster singoli: accounts e ledger Servizio. Il tempo di attività e la disponibilità dipendono l'uptime del cluster Kubernetes su cui risiedono.

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

• Networking multi-cluster. Puoi inviare il traffico destinato a distribuito ai cluster che eseguono quel servizio, utilizzando tecnologia Ingress multi-cluster, come Ingress multi-cluster oppure usando la tua soluzione proxy o il tuo bilanciatore del carico esterno. Qualsiasi cosa l'opzione utilizzata, deve consentirti di controllare quando, dove e quanto il traffico viene instradato a una determinata istanza di un servizio distribuito. La diagramma seguente mostra un bilanciatore del carico che invia traffico a un Servizio frontend in esecuzione in due cluster GKE.

  

• Osservabilità. Usa gli strumenti per misurare gli SLO, in genere disponibilità e 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 di osservabilità, puoi raccogliere e combinare singole soluzioni Metriche del servizio. Soluzioni come Cloud Monitoring o open source, come Grafana forniscono metriche di servizio Kubernetes. Soluzioni mesh di servizi come Istio e Cloud Service Mesh Forniscono inoltre metriche del servizio senza bisogno di alcuna strumentazione.

• Posizionamento del servizio. I servizi Kubernetes forniscono un errore a livello di nodo di sicurezza all'interno di un singolo cluster Kubernetes. Ciò significa che un cluster Kubernetes Il servizio può tollerare le interruzioni dei nodi. Durante le interruzioni dei nodi, un cluster Kubernetes il nodo del piano di controllo ripianifica automaticamente i pod su nodi integri. R offre una tolleranza di errore a livello di cluster. Ciò significa che un servizio distribuito può resistere alle interruzioni dei cluster. Quando disponi di capacità per la pianificazione di un servizio distribuito, devi considerare questo posizionamento di servizio. Non è necessario eseguire un servizio distribuito su tutti i cluster. I cluster su cui viene eseguito un servizio distribuito dipendono da quanto segue: 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 Servizio: cluster, a livello di zona o di regione? Ad esempio, hai bisogno più cluster in una singola zona o più cluster in più zone in una o più regioni?

  • Quale livello di interruzioni deve sostenere il servizio distribuito nello scenario peggiore? Le seguenti opzioni sono disponibili all'indirizzo a livello di cluster:

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

• Implementazioni e rollback. Servizi distribuiti, come Kubernetes per i servizi, consentono implementazioni e rollback graduali. A differenza di Kubernetes I servizi, i servizi distribuiti, consentono ai cluster di essere un'unità aggiuntiva il deployment come mezzo per un cambiamento graduale. Le implementazioni e i rollback dipendono dai requisiti del servizio. In alcuni casi, potrebbe essere necessario eseguire l'upgrade del servizio su tutti i cluster contemporaneamente, ad esempio correzione di bug. In altri casi, potresti dover implementare lentamente (o scaglionare) il e modificare un cluster alla volta. Questa implementazione graduale riduce il rischio 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, più implementazioni e rollback vengono utilizzate a seconda del servizio i tuoi requisiti. Il punto importante è che i servizi distribuiti devono consentono modifiche graduali e controllate dell'ambiente.

• Continuità aziendale e ripristino di emergenza (BCDR). Questi termini sono spesso utilizzati insieme. La continuità aziendale si riferisce alla continuazione di servizi nel caso di un evento importante (pianificato o non pianificato), mentre per ripristino di emergenza si intendono le azioni intraprese o necessarie per rimettere in sesto operazioni allo stato normale dopo tali eventi. Esistono molte strategie per BCDR che esulano dall'ambito di questo documento. Il BCDR richiede di ridondanza nei sistemi e nei servizi. Il presupposto chiave della distribuzione I servizi sono eseguiti in più località (cluster, zone regioni).

  Le strategie di BCDR spesso dipendono dai di lancio e rollback. Ad esempio, se le implementazioni vengono eseguite in modo sfalsato o controllato, l'effetto di un bug o di un il push della configurazione può essere intercettato subito senza influire su un gran numero utenti. Su larga scala e insieme a un rapido ritmo di cambiamento (ad esempio nelle moderne pratiche CI/CD), è comune che non a tutti gli utenti venga fornito la stessa versione di un servizio distribuito. Pianificazione e strategie del BCDR nel sistemi e servizi distribuiti differiscono dai sistemi diverse architetture. Nei sistemi tradizionali, il cambiamento avviene all'ingrosso, che interessano un gran numero di (o forse tutti) utenti, e quindi deve avere un ridondante o di backup in caso di effetti indesiderati implementazione. Nei sistemi e nei servizi distribuiti, quasi tutte le modifiche vengono apportate in modo graduale al fine di interessare solo un numero limitato di utenti.

• Gestione del ciclo di vita dei cluster. come le implementazioni controllate e rollback, i servizi distribuiti consentono un ciclo di vita dei cluster controllato gestione dei dispositivi. I servizi distribuiti forniscono resilienza a livello di cluster per possono essere tolti dalla rotazione per la manutenzione. Ciclo di vita del cluster è un principio di servizi distribuiti che non si applica i servizi Kubernetes.

Il resto di questo documento è incentrato sull'aspetto del ciclo di vita distribuiti in Google Cloud.

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 necessaria per mantenere un parco di cluster Kubernetes integro e aggiornato senza che violano gli SLO dei servizi. Dopo aver implementato le strategie e la pianificazione appropriate, raggruppa la gestione del ciclo di vita deve essere di routine, prevista e tranquilla.

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 per capire cosa costituisce un upgrade del cluster.

Un cluster contiene due componenti: i nodi del piano di controllo e i nodi worker. R L'upgrade dei cluster Kubernetes richiede l'upgrade di tutti i nodi allo stesso completamente gestita. Kubernetes segue controllo delle versioni semantico . Versioni di Kubernetes sono espressi come X.Y.Z: dove X è la versione principale, Y è la mentre Z è la versione patch. Minorenne le release avvengono all'incirca ogni tre mesi (trimestrale) e il progetto Kubernetes mantiene i rami di rilascio per le ultime tre uscite minori. Ciò significa che un bambino di nove mesi La release secondaria di Kubernetes non è più mantenuta e potrebbe richiedere modifiche all'API quando esegui l'upgrade alla versione più recente. Kubernetes gli upgrade devono essere pianificati con una cadenza regolare. Ti consigliamo di pianificare GKE esegue gli upgrade trimestrali o ogni due trimestri.

I cluster GKE supportano l'esecuzione di versioni Kubernetes da qualsiasi release secondaria supportata. Sono disponibili almeno due versioni secondarie nel tempo.

GKE ha i seguenti tipi di disponibilità dei cluster:

• Cluster a zona singola. Un singolo nodo del piano di controllo e tutti i nodi i pool si trovano in una zona singola all'interno di un'unica regione.
• Cluster multi-zona. Un singolo nodo del piano di controllo si trova in una zona i pool di nodi si trovano in più zone all'interno di un'unica regione.
• Cluster a livello di regione. Più nodi del piano di controllo e pool di nodi in 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

Upgrade automatico di GKE è una strategia di ciclo di vita dei cluster molto diffusa e spesso usata. L'upgrade automatico di GKE offre un modo completamente gestito per I cluster GKE sono stati aggiornati alle versioni supportate. GKE esegue gli upgrade automatici dei nodi e del worker del piano di controllo nodi separatamente:

• Esegui gli upgrade automatici principali. Per impostazione predefinita, il controllo GKE dei nodi del piano viene eseguito automaticamente. Zona singola e multi-zona i cluster hanno un singolo piano di controllo (nodo del piano di controllo). Durante il controllo degli upgrade dei nodi plane, i carichi di lavoro continuano a essere eseguiti. Tuttavia, non puoi eseguire il deployment nuovi carichi di lavoro, modificare carichi di lavoro esistenti o apportare altre modifiche del cluster fino al completamento dell'upgrade.

  I cluster a livello di regione hanno più repliche del piano di controllo 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 numero di nodi di cui viene eseguito l'upgrade contemporaneamente, ma questo processo può richiedere diverse ore a seconda del numero dei nodi e delle relative 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 periodi di manutenzione ed esclusioni di manutenzione. Canali di rilascio influenzare la selezione delle versioni strategie di upgrade dei nodi influenzano l'ordine e le tempistiche degli upgrade dei nodi. Nonostante questi controlli e a livello di regione (con più piani di controllo Kubernetes), L'upgrade automatico di GKE non garantisce i servizi il tempo di attività. Tu puoi scegliere di non utilizzare la funzionalità di upgrade automatico di GKE richiedono uno o più dei seguenti requisiti:

• Controllo della versione esatta dei cluster GKE.
• Controlla l'ora esatta per l'upgrade di GKE.
• Controllare la strategia di upgrade (trattata nella sezione successiva) per i tuoi del parco risorse GKE.

Gestione del ciclo di vita multi-cluster GKE

Questa sezione descrive i vari ciclo di vita multi-cluster GKE strategie di gestione e come pianificarle.

Considerazioni sulla pianificazione e sulla progettazione

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

Tipo di cluster

Se utilizzi l'upgrade automatico di GKE come cluster la strategia di gestione del ciclo di vita, 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 automaticamente uno alla volta, mentre i cluster di zona hanno un unico controllo del piano di controllo. Se non utilizzi l'upgrade automatico di GKE tutti i cluster Kubernetes come infrastrutture monouso, allora potrebbe a prescindere dal tipo di cluster che scegli decidendo una strategia di gestione del ciclo di vita del cluster. Puoi applicare strategie discusse nelle sezione successiva: Gestione del ciclo di vita multi-cluster GKE a qualsiasi tipo di cluster.

Posizionamento e utilizzo del cluster

Prendi in considerazione i seguenti fattori quando decidi il posizionamento del cluster impronta:

• Zone e regioni in cui i cluster devono trovarsi.
• Numero e dimensione dei cluster necessari.

Il primo fattore di solito è facile da risolvere perché le zone e le regioni sono dettati dalla tua attività e dalle regioni in cui servi gli utenti.

In genere, gestire il numero e le dimensioni dei cluster rientra nei seguenti 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 posizionarne uno (o due) di grandi dimensioni per regione. Il vantaggio di questo approccio è con il minimo overhead operativo associato alla gestione di più cluster. Lo svantaggio è che che può influire su un numero elevato di servizi contemporaneamente a causa delle sue l'area d'impatto.
• Numero elevato di piccoli cluster. Puoi creare un gran numero di piccoli cluster per ridurre l'area di impatto del cluster, sono suddivisi in più cluster. Questo approccio funziona bene anche cluster temporanei di breve durata (ad esempio, cluster che eseguono un carico di lavoro). Lo svantaggio di questo approccio è l'overhead operativo più elevato perché ci sono altri cluster di cui eseguire l'upgrade. Possono esserci anche ulteriori e i costi associati a un numero maggiore di nodi del piano di controllo. Puoi compensare i costi e l'overhead operativo elevato con l'automazione, un programma e una strategia prevedibili e un attento coordinamento tra i team e i servizi interessati.

Questo documento consiglia di non utilizzare un approccio rispetto all'altro. sono opzioni. In alcuni casi, è possibile scegliere entrambi i pattern di progettazione per diverse categorie di i servizi di machine learning.

Le seguenti strategie funzionano con entrambe le scelte di design.

Pianificazione della capacità

Quando si pianifica la capacità, è importante considerare il cluster scelto la strategia del ciclo di vita. La pianificazione della capacità deve considerare il seguente servizio normale di carico e manutenzione:

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

Quando pianifichi la capacità, devi prendere in considerazione eventuali interruzioni totali o parziali. Se per gli eventi di manutenzione pianificati, tutti i Servizi distribuiti Avere un cluster in più rispetto a quello richiesto, per poterne estrarre uno di rotazione alla volta per gli upgrade senza ridurre il servizio. Questo approccio è detta anche Non +1 pianificazione della capacità. Se progetti eventi di manutenzione pianificati e non pianificati, tutti devono avere due (o più) cluster aggiuntivi rispetto a quanto richiesto per la gestione capacità prevista: una per l'evento pianificato e una per un evento non pianificato in si verifica durante il periodo di manutenzione pianificato. Questo approccio denominato N+2 pianificazione della capacità.

Nelle architetture multi-cluster, i termini drening e spilling sono spesso in uso. Questi termini fanno riferimento al processo di rimozione (o svuotamento) del traffico da una cluster e il reindirizzamento (o sversamento) del traffico su altri cluster durante upgrade ed 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 dello svuotamento e del fuoriuscita è al centro del ciclo di vita di alcuni cluster per la gestione delle applicazioni. Quando pianifichi la capacità, devi considerare lo svuotamento e fuoriuscite. Ad esempio, quando viene svuotato un singolo cluster, devi valuta se gli altri cluster hanno capacità sufficiente ulteriore traffico fuoriuscito. Altre considerazioni includono una capacità sufficiente alla zona o alla regione o alla necessità di inviare traffico a una regione diversa (se utilizzi un a livello di singola regione per regione). Il seguente diagramma mostra il traffico proveniente rimosso (a volte indicato come svuotamento di un cluster) da un cluster e inviato in un altro cluster che esegue lo stesso servizio distribuito.

Cluster e servizi distribuiti

La progettazione dei cluster basata su servizi determina l'architettura del cluster (numero, dimensione, e località) è determinata dai Servizi che devono essere eseguiti sul cluster. Di conseguenza, il posizionamento dei cluster è dettato da dove sono necessari servizi distribuiti. Prendi in considerazione i seguenti aspetti quando decidi posizionamento di servizi distribuiti:

• Requisito per la località. In quali regioni deve essere il servizio da cui è stato pubblicato?
• Criticità. Quanto è critica la disponibilità di un servizio per il 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? Richiede a livello di cluster, zona o persino regione?

Quando pianifichi gli upgrade dei cluster, devi considerare il numero di Service come un il singolo cluster influisce sullo svuotamento e devi tenere conto del spilling ciascuno di questi servizi ad altri cluster appropriati. I cluster possono essere singoli tenant o multi-tenant. I cluster a tenant singolo gestiscono solo un servizio prodotto rappresentato da un insieme di Servizi. I cluster a tenant singolo non condividono nel cluster con altri servizi o prodotti. I cluster multi-tenant possono eseguire Servizi e prodotti che in genere sono partizionati in spazi dei nomi.

Impatto sui team

Un evento cluster non solo influisce sui servizi, ma può anche interessare i team. Per Ad esempio, il team DevOps potrebbe dover reindirizzare o arrestare le pipeline CI/CD durante l'upgrade di un cluster. Analogamente, i team di assistenza possono ricevere avvisi o in caso di interruzione del servizio. Devono essere implementati Automation e strumenti per contribuire a ridurre l'impatto più team. L'upgrade di un cluster o di un parco risorse di cluster deve essere considerato di routine e senza problemi quando tutti i team sono informati.

Tempistica, programmazione e coordinamento

Kubernetes rilascia una nuova versione secondaria ogni trimestre e mantiene le ultime tre nuove versioni. 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 di servizi e per gli amministratori di piattaforma quando verranno eseguiti questi upgrade. Quando pianifichi ti invitiamo a rispondere alle seguenti domande:

• Con quale frequenza esegui l'upgrade? L'upgrade viene eseguito ogni trimestre o in base a sequenza temporale?
• Quando eseguire l'upgrade? L'upgrade viene eseguito all'inizio del trimestre, quando l'attività rallenta o durante altri tempi di inattività legati alle attività settore?
• Quando conviene non eseguire l'upgrade? Hai una pianificazione chiara per quando per eseguire l'upgrade, ad esempio evitando eventi di picco come il Black Friday, lunedì o durante conferenze di alto profilo e altre conferenze eventi.

È importante implementare una strategia che venga comunicata in modo chiaro. con i proprietari dei servizi, nonché con i team operativi e di assistenza. Là non devono sorprendere e tutti devono sapere quando e come i cluster con upgrade eseguito. Ciò richiede un chiaro coordinamento con tutti i team coinvolti. Un singolo Il servizio ha diversi team che interagiscono con il servizio. In genere, questi team possono raggruppate nelle seguenti categorie:

• Lo sviluppatore del Servizio, responsabile della creazione e della programmazione del dalla logica di business a un servizio.
• L'operatore del servizio, responsabile dell'esecuzione sicura e affidabile il Servizio. Gli operatori possono essere costituiti da più team, ad esempio amministratore della sicurezza, amministratore di rete e team di assistenza.

Tutti devono comunicare durante gli upgrade del cluster per poter le azioni appropriate durante questo periodo. Un approccio è pianificare gli upgrade nello stesso modo per pianificare un'interruzione del servizio. Hai un incident Commander, una chat stanza virtuale e una retrospettiva (anche se nessun utente è stato interessato). Per ulteriori informazioni le informazioni, vedi Risposta agli incidenti.

Strategie del ciclo di vita dei cluster GKE

Questa sezione illustra spesso le principali strategie di gestione del ciclo di vita dei cluster utilizzata nell'architettura multi-cluster GKE. È importante una strategia non è efficace per tutti gli scenari e puoi scegliere più strategie per le varie categorie di servizi e le varie esigenze del business.

Upgrade in sequenza

Il seguente diagramma mostra la strategia di upgrade in sequenza.

Con un bilanciatore del carico, viene svuotato un cluster GKE di tutti traffico e l'upgrade è stato eseguito. Il carico di traffico svuotato viene riversato a un altro cluster GKE.

Gli upgrade in sequenza sono la strategia più semplice e conveniente tra le strategie descritte in questo documento. Inizi con un numero di cluster n che esegue la versione old_ver (o di produzione attuale). Quindi svuota m cluster alla volta, dove m è inferiore a n. Quindi, elimini e ricrei nuove con la nuova versione o esegui l'upgrade dei cluster svuotati.

La decisione tra l'eliminazione e l'upgrade di nuovi cluster dipende dalle dimensioni dei cluster e consideriamo che i cluster sono un'infrastruttura immutabile. Immutabile dell'infrastruttura richiede che, invece di eseguire continuamente l'upgrade di un cluster, potrebbe produrre risultati indesiderati nel tempo, potresti creare nuovi cluster ed evitare deviazioni impreviste della configurazione.

Se usi GKE, puoi un cluster GKE con un singolo comando o una chiamata API. La nuova strategia per il cluster richiede che la configurazione del cluster sia completa (manifest del cluster) archiviati all'esterno del cluster, in genere in Git. Puoi e poi utilizzare lo stesso modello di configurazione sul nuovo cluster. Se si tratta di un nuovo assicurati che le pipeline CI/CD puntino al cluster corretto. Dopo che il cluster è stato configurato correttamente, puoi inviare di nuovo il traffico lentamente il cluster, monitorando al tempo stesso la gestione SLO.

Il processo viene ripetuto per tutti i cluster. In base alla tua pianificazione della capacità, puoi eseguire l'upgrade di più cluster alla volta senza violare gli SLO di servizio.

Se consideri la semplicità e i costi più che la resilienza, utilizza gli upgrade in sequenza strategia. Durante questa strategia, non dovrai mai superare la capacità richiesta del parco risorse 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 dell'architettura.

Il diagramma precedente mostra che in GKE di upgrade, la capacità di supportare i servizi non va mai al di sotto obbligatorio. Quando il cluster GKE di cui eseguire l'upgrade viene estratto della 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, un nuovo cluster GKE che esegue viene aggiunta una nuova versione. Quindi viene utilizzato un bilanciatore del carico per inviare traffico alla nuova svuotando lentamente uno dei vecchi cluster finché non viene inviato traffico che le sono assegnati. Il vecchio cluster completamente svuotato può essere rimosso. Lo stesso processo può da seguire 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'unico la differenza è che, invece di svuotare 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 versare lentamente il traffico durante il monitoraggio degli SLO del servizio. Quando il nuovo utilizzano completamente il traffico, vengono svuotati ed eliminati i cluster con completamente gestita.

La strategia blu/verde per eseguire l'upgrade dei cluster è simile a una strategia blu/verde utilizzati generalmente per i Servizi. La creazione di più nuovi cluster alla volta aumenta il costo complessivo, ma offre il vantaggio di accelerare i tempi di upgrade del parco risorse. Il costo aggiuntivo si riferisce solo alla durata dell'upgrade quando cluster aggiuntivi . Il vantaggio della creazione di nuovi cluster è che, nel caso di un un errore, puoi eseguirne il rollback. Puoi anche testare il nuovo cluster prima di inviarlo e il traffico di produzione. Poiché questi cluster coesistono con la loro versione precedente per un breve periodo di tempo, i costi aggiuntivi sono minimi.

Se consideri la semplicità e la resilienza rispetto al costo, utilizza l'upgrade blu/verde strategia. Vengono aggiunti prima cluster aggiuntivi e superano la capacità richiesta del parco risorse GKE per la durata del upgrade.

Nel diagramma precedente, l'aggiunta di un nuovo cluster aumenta temporaneamente di capacità elevata rispetto alla capacità richiesta mentre un altro cluster della flotta vengono svuotati e rimossi dalla flotta. Tuttavia, dopo aver rimosso dei vecchi cluster (con svuotamento completo), la capacità torna a quella necessaria. Questa modifica della capacità è evidenziata perché potrebbe esserci un aumento del costo con questo modello, a seconda del numero e delle dimensioni dei cluster nel parco risorse.

Upgrade canary dei cluster

L'upgrade del cluster canary è la strategia più resiliente e complessa di queste trattati in questo documento. Questa strategia astrae completamente il cluster la gestione del ciclo di vita Gestione del ciclo di vita dei servizi, offrendo così il rischio più basso per i tuoi servizi. Nell'upgrade in sequenza e blu/verde precedente le tue strategie, mantieni il l'intero parco risorse GKE in un'unica versione. In questa strategia, due o forse tre gruppi di cluster GKE che eseguono versioni diverse. Anziché eseguire l'upgrade dei cluster, esegui la migrazione Servizi da un parco risorse di cluster all'altro nel tempo. Quando il parco risorse GKE meno recente viene svuotato (il che significa che tutti i servizi al parco risorse GKE con il successivo controllo delle versioni), della flotta.

Questa strategia richiede di mantenere un minimo di 2 Parco risorse GKE, uno per la produzione attuale e uno per successiva alla versione candidata alla produzione. Puoi anche gestire più di due dei parchi risorse GKE. I parchi risorse extra ti offrono maggiore flessibilità, aumentano anche i costi e i costi operativi generali. Queste flotte aggiuntive non sono è come avere cluster in ambienti diversi, ad esempio sviluppo, di gestione temporanea e di produzione. Gli ambienti non di produzione sono ideali testare le funzionalità e i servizi Kubernetes con traffico non di produzione.

Questa strategia di utilizzo di upgrade dei cluster canary richiede di mantenere Versioni del parco risorse GKE nell'ambiente di produzione. Questo è simili alle strategie di versione canary usate spesso dai Servizi. Con deployment canary, il proprietario del servizio può sempre individuare i problemi una determinata versione del servizio. Con i cluster canary, il proprietario del servizio deve e prendono in considerazione anche le versioni del parco risorse GKE I servizi sono in esecuzione. Una singola versione del servizio distribuito può vengono eseguite su più versioni del parco risorse GKE. La migrazione di un Il servizio può essere eseguito gradualmente per consentirti di vederne gli effetti su il nuovo parco risorse prima di inviare tutto il traffico per il servizio al nuovo parco risorse cluster.

Il seguente diagramma mostra che la gestione di diversi parchi risorse I cluster GKE possono 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 a quello successivo in esecuzione la nuova versione fino a quando il parco risorse precedente non sarà completamente svuotato nel tempo. Dopo il parco risorse è svuotato, può essere rimosso e viene creato un nuovo parco risorse. Tutti i servizi sono è stata eseguita la migrazione al parco risorse successivo, rimuovendo quelli meno recenti quando vengono svuotati.

Se consideri la resilienza più di tutto, utilizza l'upgrade del cluster canary strategia.

Scegli una strategia di upgrade

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

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

• Se non hai bisogno del controllo completo sul controllo esatto versione e ora dell'upgrade, puoi scegliere la funzione di upgrade automatico disponibili in GKE.
• Se la tua priorità è bassa, 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 tutte le strategie dipendono dalla capacità di svuotare e reinstradare il percorso ad altri cluster durante gli upgrade. Una soluzione che fornisce questo è la funzionalità Ingress multi-cluster Ingress multi-cluster. Ingress multi-cluster è un traffico in entrata multi-cluster ospitato su Google Cloud controller per cluster GKE che supporta il deployment di un carico condiviso di Google Cloud tra cluster e regioni. Il servizio Ingress multi-cluster è soluzione per ottenere il traffico client verso un servizio distribuito in esecuzione in molti cluster in molte regioni. Come Ingress per GKE, utilizza Cloud Load Balancing per inviare il traffico servizio di backend. Il servizio di backend è il servizio distribuito. Il servizio di backend invia il traffico verso più backend, ovvero i servizi Kubernetes in esecuzione su più GKE cluster. Per il traffico da Service-to-Service tra i cluster, puoi usare Service-to-Service tecnologie mesh 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 il traffico le strategie di gestione del ciclo di vita dei cluster. 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 distribuire Ingress multi-cluster in vari cluster.