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. 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 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 è necessario alcun trattamento speciale per alcun componente dell'infrastruttura perché i componenti 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 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 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. Anche i cluster Kubernetes sono spesso 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).
• Diritti di proprietà ed ambienti. I cluster Kubernetes sono progettati l'architettura multi-tenancy. Più team possono condividere un unico cluster per 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 rispettivi 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 altro hardware per cluster di istanze composti VM spot per 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 nel proprio cluster di amministrazione della piattaforma. 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 di 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 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 passa alla modalità offline, il 50% del traffico viene influenzato. 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, vengono utilizzati più cluster spesso utilizzato anche 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 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 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 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 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 dei 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 Multi Cluster Ingress o utilizzando il tuo bilanciatore del carico o la tua soluzione proxy esterni. Qualsiasi opzione tu scelga, deve darti il controllo su quando, dove e quanto traffico viene indirizzato a una determinata istanza di un servizio distribuito. Il seguente diagramma mostra un bilanciatore del carico che invia traffico a un servizio distribuitofrontend in esecuzione in due cluster GKE.

  

• Osservabilità. Utilizza strumenti per misurare gli SLO, in genere disponibilità e latenza, collettivamente per un servizio distribuito. Questa configurazione offre una visione globale delle prestazioni di ogni Servizio su più cluster. Sebbene il servizio distribuito non sia una risorsa ben definita nella maggior parte delle soluzioni di osservabilità, puoi raccogliere e combinare le metriche dei singoli servizi Kubernetes. 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 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 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 di più cluster in un'unica zona o di 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 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ò tollerare errori simultanei. Ad esempio, un'interruzione pianificata e un'interruzione 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 di Kubernetes I servizi, i servizi distribuiti, consentono ai cluster di essere un'unità aggiuntiva il deployment come mezzo per un cambiamento graduale. Anche i rollout e i rollback dipendono dal requisito 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, potrebbe essere necessario implementare lentamente (o suddividere) la modifica 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. Non esiste una strategia di upgrade 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 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 chiave della distribuzione I servizi sono eseguiti in più località (cluster, zone 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 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 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 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 è 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 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 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 uno schema di versionamento 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 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. 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 pool di nodi si trovano in una singola zona in 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 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 sia per i nodi worker.

Aggiornamento 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 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, 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 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, 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 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 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 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 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 GKE

Questa sezione descrive varie strategie di gestione del ciclo di vita dei cluster GKE multi-cluster e come pianificarle.

Considerazioni sulla pianificazione e sulla 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 o essere influenzate dalla strategia di gestione del ciclo di vita del 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, per i quali viene eseguito l'upgrade automatico uno alla volta, mentre i cluster di zona hanno un unico 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

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

• 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 è lo scarso overhead operativo della 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 è 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. 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 non consiglia un approccio rispetto all'altro; si tratta di opzioni. In alcuni casi, è possibile scegliere entrambi i pattern di progettazione per diverse categorie di i servizi di machine learning.

Le seguenti strategie funzionano con entrambe le scelte di design.

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 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 il tuo progetto prevede solo 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 è detta anche N+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 è anche conosciuto come pianificazione delle capacità N+2.

Nelle architetture multi-cluster, i termini drening e spilling sono spesso in uso. Questi termini si riferiscono al processo di rimozione (o drenaggio) del traffico da un cluster e di reindirizzamento (o svuotamento) del traffico su altri cluster durante gli upgrade e gli eventi di manutenzione. Questo processo si ottiene utilizzando soluzioni di networking come Ingress multi-cluster o altri metodi di bilanciamento del carico. L'uso attento 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 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. Prendi in considerazione i seguenti aspetti quando decidi posizionamento dei servizi distribuiti:

• Requisito relativo alla località. In quali regioni deve essere fornito il servizio?
• 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 fuoriuscite ciascuno di questi servizi ad altri cluster appropriati. I cluster possono essere mono-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 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'automazione 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 un'operazione di routine e senza problemi se 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 gli upgrade, poniti le seguenti domande:

• Con quale frequenza esegui l'upgrade? Esegui l'upgrade ogni trimestre o con un altro piano?
• Quando eseguire 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 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 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 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 room e una reintegrazione (anche se nessun utente è stato interessato). Per ulteriori informazioni, consulta la sezione Risposta agli incidenti.

Strategie di ciclo di vita del 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 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.

Aggiornamenti in sequenza

Il seguente diagramma mostra la strategia di upgrade in sequenza.

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 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. 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 per il cluster richiede che la configurazione del cluster sia completa (manifest del cluster) archiviati all'esterno del cluster, in genere in Git. Puoi quindi utilizzare lo stesso modello di configurazione nel nuovo cluster. Se si tratta di un nuovo 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.

La procedura viene ripetuta 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 preferisci la semplicità e il costo alla resilienza, utilizza la strategia di upgrade graduali. 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 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. 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 prosciugato può quindi essere rimosso. Puoi seguire la stessa procedura per gli altri cluster.

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, in caso di un errore, puoi eseguirne 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 attribuisci la priorità alla semplicità e alla resilienza rispetto al costo, utilizza l'upgrade blu/verde strategia. 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 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 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 incrementale e blu/verde precedenti, gestivi l'intera flotta 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 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 parchi GKE. I parchi veicoli aggiuntivi offrono maggiore flessibilità, ma anche i costi e il sovraccarico operativo aumentano. 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 per testare le funzionalità e i servizi Kubernetes con traffico non di produzione.

Questa strategia di utilizzo degli upgrade dei cluster canary richiede la gestione di più versioni del parco risorse GKE nell'ambiente di produzione. Questo è simili alle strategie di versione canary usate spesso 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 e prendono in considerazione anche le versioni del parco risorse GKE I servizi sono in esecuzione. Una singola versione del servizio distribuita può potenzialmente 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 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 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 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à è il basso costo, puoi scegliere la strategia di upgrade graduale.
• Se la tua priorità è bilanciare il costo e la 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. 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 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 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 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.