Migrazione dei container in Google Cloud: migrazione a un ambiente GKE multi-cluster

Last reviewed 2023-05-08 UTC

Questo documento ti aiuta a pianificare, progettare e implementare la migrazione da un ambiente Google Kubernetes Engine (GKE) a un nuovo ambiente GKE. Se eseguito in modo errato, spostare le app da un ambiente all'altro può essere impegnativo. Pertanto, devi pianificare ed eseguire la migrazione con attenzione.

Questo documento fa parte di una serie in più parti sulla migrazione a Google Cloud. Per una panoramica della serie, vedi Migrazione a Google Cloud: scegliere il percorso di migrazione.

Questo documento fa parte di una serie che illustra la migrazione dei containers a Google Cloud:

Questo documento è utile se stai pianificando di eseguire la migrazione da un ambiente GKE a un altro ambiente GKE. Questo documento è utile anche se stai valutando l'opportunità di eseguire la migrazione e vuoi vedere come potrebbe essere.

I motivi per eseguire la migrazione da un ambiente GKE a un altro ambiente GKE possono includere quanto segue:

  • Abilitazione delle funzionalità GKE disponibile solo durante la creazione del cluster. GKE è in costante evoluzione, con nuove funzionalità e correzioni di sicurezza. Per trarre vantaggio dalla maggior parte delle nuove funzionalità e correzioni, potrebbe essere necessario eseguire l'upgrade dei cluster e dei pool di nodi GKE a una versione GKE più recente, tramite upgrade automatico o manualmente.

    Alcune nuove funzionalità GKE non possono essere abilitate su cluster esistenti e richiedono la creazione di nuovi cluster GKE con le nuove funzionalità abilitate. Ad esempio, puoi abilitare il networking nativo di VPC in GKE, Dataplane V2 o l'occultamento dei metadati solo quando crei nuovi cluster. Non puoi aggiornare la configurazione dei cluster esistenti per abilitare queste funzionalità dopo la loro creazione.

  • Implementare un processo automatizzato di provisioning e configurazione per l'infrastruttura. Se esegui manualmente il provisioning e la configurazione dell'infrastruttura, puoi progettare e implementare un processo automatizzato per il provisioning e la configurazione dei cluster GKE, anziché utilizzare metodi manuali e soggetti a errori.

Quando progetti l'architettura del tuo nuovo ambiente, ti consigliamo di considerare un ambiente GKE multi-cluster. Se esegui il provisioning e la configurazione di più cluster GKE nel tuo ambiente, puoi:

  • Riduci le possibilità di introdurre un single point of failure nella tua architettura. Ad esempio, se un cluster subisce un'interruzione, altri cluster possono assumere il controllo.
  • Sfrutta la maggiore flessibilità offerta da un ambiente multi-cluster. Ad esempio, se applichi modifiche a un sottoinsieme dei tuoi cluster, puoi limitare l'impatto dei problemi causati da modifiche errate alla configurazione. Puoi quindi convalidare le modifiche prima di applicarle ai cluster rimanenti.
  • Consenti ai carichi di lavoro di comunicare tra i cluster. Ad esempio, i carichi di lavoro di cui è stato eseguito il deployment in un cluster possono comunicare con quelli di cui è stato eseguito il deployment in un altro cluster.

Le indicazioni contenute in questo documento sono applicabili anche a un ambiente GKE a cluster singolo. Quando esegui la migrazione a un ambiente GKE a cluster singolo, la gestione del tuo ambiente è meno complessa rispetto a quella di un ambiente multi-cluster. Tuttavia, un ambiente a cluster singolo non trae vantaggio dalla maggiore flessibilità, affidabilità e resilienza di un ambiente GKE multi-cluster.

Il seguente diagramma illustra il percorso del tuo percorso di migrazione.

Percorso di migrazione diviso in quattro fasi.

Il framework illustrato nel diagramma precedente prevede le seguenti fasi, definite in Migrazione a Google Cloud: guida introduttiva:

  1. Valutazione e rilevamento dei carichi di lavoro.
  2. Pianificare e costruire le basi.
  3. Deployment dei carichi di lavoro.
  4. Ottimizzazione dell'ambiente.

Segui le fasi precedenti durante ogni passaggio della migrazione. Questo documento si basa anche sui concetti discussi in Migrazione di container in Google Cloud: migrazione da Kubernetes a GKE. Ove appropriato, include i link.

Valutazione dell'ambiente in corso...

Nella fase di valutazione, raccogli informazioni sull'ambiente di origine e sui carichi di lavoro di cui vuoi eseguire la migrazione. Questa valutazione è fondamentale per la migrazione e per dimensionare le risorse necessarie per la migrazione e l'ambiente di destinazione. Nella fase di valutazione, devi:

  1. Crea un inventario completo delle tue app.
  2. Cataloga le tue app in base alle loro proprietà e dipendenze.
  3. Addestra e forma i tuoi team su Google Cloud.
  4. Crea un esperimento e una proof of concept su Google Cloud.
  5. Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
  6. Scegli per primi i carichi di lavoro di cui vuoi eseguire la migrazione.

Le sezioni seguenti si basano su Migrazione a Google Cloud: valutazione e individuazione dei carichi di lavoro. Tuttavia, forniscono informazioni specifiche per la valutazione dei carichi di lavoro di cui vuoi eseguire la migrazione ai nuovi cluster GKE.

In Migrazione di Kubernetes a GKE, la sezione Valutazione dell'ambiente descrive come valutare i cluster e le risorse Kubernetes, come ServiceAccounts e PersistentVolume. Le informazioni si applicano anche alla valutazione dell'ambiente GKE.

Creare gli inventari

Per definire l'ambito della migrazione, devi conoscere il tuo attuale ambiente GKE. Inizierai raccogliendo informazioni sui cluster, quindi ti concentrerai sui carichi di lavoro di cui è stato eseguito il deployment nei cluster e sulle dipendenze dei carichi di lavoro. Al termine della fase di valutazione, hai due inventari: uno per i cluster e uno per i carichi di lavoro di cui è stato eseguito il deployment nei cluster.

In Migrazione da Kubernetes a GKE, la sezione Creazione di inventari descrive come creare gli inventari per i cluster e i carichi di lavoro Kubernetes. È applicabile anche alla creazione degli inventari dei tuoi ambienti GKE. Prima di procedere con questo documento, segui le indicazioni per creare l'inventario dei tuoi cluster Kubernetes.

Dopo aver seguito le indicazioni sulla migrazione di Kubernetes a GKE per creare gli inventari, puoi perfezionare gli inventari. Per completare l'inventario dei cluster e dei pool di nodi GKE, considera gli aspetti e le funzionalità specifici di GKE per ogni cluster e pool di nodi, incluso quanto segue:

Quando crei l'inventario, potresti trovare alcuni cluster GKE che devono essere dismessi durante la migrazione. Alcune risorse Google Cloud non vengono eliminate quando elimini i cluster GKE che le hanno create. Assicurati che il tuo piano di migrazione includa il ritiro di queste risorse.

Per informazioni su altri potenziali aspetti e funzionalità specifici di GKE, consulta la documentazione di GKE.

Completa la valutazione

Dopo aver creato gli inventari relativi ai cluster GKE e ai carichi di lavoro, completa le altre attività della fase di valutazione in Migrazione dei container in Google Cloud: migrazione di Kubernetes a GKE.

Pianificare e costruire le basi

Nella fase di pianificazione, esegui il provisioning e la configurazione degli elementi di base, dell'infrastruttura cloud e dei servizi che supportano i carichi di lavoro su Google Cloud. Nella fase di pianificazione, esegui quanto segue:

  • Creare una gerarchia di risorse.
  • Configura la gestione di identità e accessi.
  • Configura la fatturazione.
  • Configura la connettività di rete.
  • Rafforza la tua sicurezza.
  • Configura il monitoraggio e gli avvisi.

Quando configuri la connettività di rete, assicurati di avere un numero sufficiente di indirizzi IP nelle subnet da allocare per nodi, pod e servizi. Quando configuri il networking per i cluster, pianifica con attenzione l'allocazione degli indirizzi IP. Ad esempio, puoi configurare IP pubblici utilizzati privatamente per GKE. Gli intervalli di indirizzi IP secondari impostati per pod e servizi sui cluster non possono essere modificati dopo l'allocazione. Presta particolare attenzione se allochi un pod o un intervallo di servizi di massimo /22 (1024 indirizzi). In caso contrario, potresti esaurire gli indirizzi IP per pod e servizi man mano che il cluster cresce. Per maggiori informazioni, consulta la pagina relativa alla pianificazione dell'intervallo di indirizzi IP.

Ti consigliamo di utilizzare una subnet condivisa separata per i bilanciatori del carico interni che crei per il tuo ambiente GKE. Quando utilizzi un servizio Kubernetes di type: LoadBalancer, puoi specificare una subnet del bilanciatore del carico. Quando configuri bilanciatori del carico HTTP(S) interni, devi configurare una subnet solo proxy.

Per creare le basi del tuo ambiente GKE, completa le attività della fase di pianificazione e creazione in Migrazione dei container in Google Cloud: migrazione di Kubernetes a GKE.

deployment dei carichi di lavoro

Nella fase di deployment, devi:

  1. Esegui il provisioning e la configurazione dell'ambiente di destinazione.
  2. Esegui la migrazione dei dati dall'ambiente di origine all'ambiente di destinazione.
  3. Esegui il deployment dei carichi di lavoro nell'ambiente di destinazione.

Questa sezione fornisce informazioni specifiche per il deployment di carichi di lavoro in GKE. Si basa sulle informazioni contenute in Migrazione di Kubernetes a GKE: deployment dei carichi di lavoro.

Valuta la tua piattaforma di runtime e gli ambienti

Per un'infrastruttura più flessibile, affidabile e gestibile, ti consigliamo di progettare e implementare un'architettura multi-cluster. In un'architettura multi-cluster, nel tuo ambiente sono presenti più cluster GKE di produzione. Ad esempio, se esegui il provisioning di più cluster GKE nel tuo ambiente, puoi implementare strategie di ciclo di vita dei cluster avanzate, come gli upgrade in sequenza o gli upgrade blu/verde. Per ulteriori informazioni sui progetti di architetture GKE multi-cluster e sui relativi vantaggi, consulta Upgrade di GKE multi-cluster utilizzando Ingress multi-cluster.

Quando esegui il tuo ambiente su più cluster, devi prendere in considerazione altre sfide, ad esempio:

  • Devi adattare la gestione della configurazione, il rilevamento e la comunicazione dei servizi, le implementazioni delle applicazioni e il bilanciamento del carico per il traffico in entrata.
  • Probabilmente avrai bisogno di eseguire software aggiuntivo sul cluster e ulteriori funzionalità di automazione e infrastruttura.

Per affrontare queste sfide, potrebbero essere necessarie le pipeline di integrazione continua/deployment continuo (CI/CD) per aggiornare la configurazione dei cluster in sequenza per ridurre al minimo l'impatto degli errori. Potresti anche aver bisogno di bilanciatori del carico per distribuire il traffico da un cluster ad altri cluster.

La gestione manuale dell'infrastruttura è soggetta a errori ed espone problemi dovuti a errori di configurazione e alla mancanza di documentazione interna sullo stato attuale dell'infrastruttura. Per ridurre i rischi dovuti a questi problemi, ti consigliamo di applicare il pattern Infrastructure as Code. Quando applichi questo pattern, il provisioning dell'infrastruttura viene gestito allo stesso modo in cui gestisci il codice sorgente dei carichi di lavoro.

Esistono diverse opzioni di architettura per l'ambiente GKE multi-cluster, descritte più avanti in questa sezione. Scegliere un'opzione rispetto alle altre dipende da diversi fattori e nessuna opzione è intrinsecamente migliore delle altre. Ogni tipo ha i propri punti deboli e punti di forza. Per scegliere un tipo di architettura:

  1. Definisci un insieme di criteri per valutare i tipi di architetture degli ambienti GKE multi-cluster.
  2. Valuta ciascuna opzione in base ai criteri di valutazione.
  3. Scegli l'opzione più adatta alle tue esigenze.

Per stabilire i criteri per valutare i tipi di architettura degli ambienti GKE multi-cluster, utilizza la valutazione dell'ambiente che hai completato per identificare le funzionalità di cui hai bisogno. Ordina le caratteristiche in base all'importanza. Ad esempio, dopo aver valutato i carichi di lavoro e l'ambiente, potresti considerare i seguenti criteri di valutazione, elencati in potenziale ordine di importanza:

  1. Soluzione gestita da Google. Preferisci i servizi e i prodotti gestiti da Google o autogestiti?
  2. Interfacce per interagire con l'architettura. Esiste un'interfaccia leggibile dal computer con cui puoi interagire? L'interfaccia è definita come standard aperto? L'interfaccia supporta direttive dichiarative, imperative o entrambe?
  3. Esponi servizi al di fuori dell'ambiente GKE. L'architettura consente di esporre i carichi di lavoro all'esterno del cluster GKE in cui viene eseguito il deployment?
  4. Comunicazione tra cluster. L'architettura supporta canali di comunicazione tra cluster? I tuoi carichi di lavoro supportano un'architettura distribuita? Questo criterio è importante per supportare carichi di lavoro con una progettazione distribuita, come Jenkins.
  5. Gestione del traffico. L'architettura supporta funzionalità avanzate di gestione del traffico, ad esempio fault injection, traffic shifting, timeout e tentativi di richiesta, interruttori di sicurezza e Mirroring del traffico? Queste funzionalità sono pronte per l'uso o devi implementarle autonomamente?
  6. Esegui il provisioning e la configurazione di strumenti aggiuntivi. Hai bisogno di eseguire il provisioning e la configurazione di componenti hardware o software aggiuntivi?

Google Cloud offre le seguenti opzioni per progettare l'architettura di un ambiente GKE multi-cluster. Per scegliere l'opzione migliore per i tuoi carichi di lavoro, devi prima valutarli in base ai criteri di valutazione precedentemente stabiliti. Utilizza una scala ordinata arbitraria per assegnare a ogni opzione di progettazione un punteggio rispetto a ciascun criterio di valutazione. Ad esempio, puoi assegnare a ciascun ambiente un punteggio su una scala da 1 a 10 in base a ogni criterio di valutazione. Le seguenti opzioni vengono presentate in ordine crescente di quanto sforzo è necessario per gestire il nuovo ambiente GKE multi-cluster.

  1. Ingress multi-cluster e Scoperta dei servizi multi-cluster
  2. Ingress multi-cluster e Cloud Service Mesh
  3. Cloud Service Mesh
  4. Aggiornamenti dei record DNS autogestiti e di Kubernetes

Le seguenti sezioni descrivono in dettaglio queste opzioni e includono un elenco di criteri per valutare ciascuna opzione. Potresti riuscire ad assegnare punteggi in base ad alcuni criteri leggendo la documentazione del prodotto. Ad esempio, leggendo la documentazione, puoi valutare Cloud Service Mesh sulla base di alcuni dei criteri di valutazione che hai stabilito in precedenza. Tuttavia, per assegnare punteggi rispetto ad altri criteri, potrebbe essere necessario progettare ed eseguire benchmark e simulazioni più approfonditi. Ad esempio, potresti dover confrontare le prestazioni di diverse architetture GKE multi-cluster per valutare se sono adatte ai tuoi carichi di lavoro.

Ingress multi-cluster e scoperta del servizio multi-cluster

Ingress multi-cluster è un servizio gestito da Google che ti consente di esporre i carichi di lavoro indipendentemente dal cluster GKE in cui viene eseguito il deployment. Consente inoltre di configurare bilanciatori del carico condivisi nei cluster GKE e in più regioni. Per ulteriori informazioni su come utilizzare Ingress multi-cluster in un ambiente GKE multi-cluster, consulta Upgrade GKE multi-cluster con Ingress multi-cluster e Supporto della migrazione con l'espansione del mesh Istio.

Multi-Cluster Service Discovery è un meccanismo di rilevamento dei servizi e connettività tra cluster nativo di Kubernetes per GKE. Il rilevamento del servizio multi-cluster si basa sulla risorsa Servizio Kubernetes per aiutare le app a rilevare e connettersi tra loro oltre i confini del cluster. Per valutare Ingress multi-cluster e Multi-Cluster Service Discovery in base ai criteri stabiliti in precedenza, utilizza il seguente elenco, numerato in ordine di importanza relativa:

  1. Soluzione gestita da Google. Multi-Cluster Service Discovery è una funzionalità completamente gestita di GKE. che configura le risorse (zone e record di Cloud DNS, regole del firewall e Cloud Service Mesh) in modo che non sia necessario gestirle.
  2. Interfacce per interagire con l'architettura. I servizi vengono esportati in altri cluster utilizzando una risorsa Kubernetes dichiarativa denominata ServiceExport.
  3. Esponi servizi al di fuori dell'ambiente GKE. Quando utilizzi Ingress multi-cluster e il rilevamento dei servizi multi-cluster, puoi esporre i carichi di lavoro all'esterno dei cluster GKE, indipendentemente da dove ne hai eseguito il deployment.
  4. Comunicazione tra cluster. Puoi esportare i servizi esistenti in altri cluster GKE dichiarando un oggetto ServiceExport. I cluster GKE nello stesso parco risorse importano automaticamente i servizi che esporti utilizzando gli oggetti ServiceExport. Multi-Cluster Service Discovery configura un indirizzo IP virtuale per ogni servizio esportato. Service Discovery multi-cluster configura automaticamente le risorse Cloud Service Mesh, Cloud DNS e le regole del firewall per il rilevamento e la connessione ai servizi utilizzando una semplice variante della convenzione DNS di Kubernetes. Ad esempio, per raggiungere il servizio my-svc, puoi utilizzare il nome my-svc.my-ns.svc.clusterset.local.
  5. Gestione del traffico. Service Discovery multi-cluster configura la connettività di livello semplice 3/4 e si basa sul DNS per il rilevamento dei servizi. Non fornisce alcuna funzionalità di gestione del traffico.
  6. Esegui il provisioning e la configurazione di strumenti aggiuntivi. Puoi configurare Multi-Cluster Service Discovery abilitando le API di Google. Non richiede l'installazione di strumenti aggiuntivi. Per ulteriori informazioni, consulta Migrazione di container in Google Cloud: migrazione a un ambiente GKE multi-cluster con rilevamento servizi multi-cluster e Ingress multi-cluster

Ingress multi-cluster e mesh di servizi cloud

Un mesh di servizi è un pattern architetturale che aiuta a risolvere i problemi di rete delle app distribuite. Queste sfide includono Service Discovery, il bilanciamento del carico, la tolleranza di errore, il controllo del traffico, l'osservabilità, l'autenticazione, l'autorizzazione e la crittografia in transito. Le implementazioni tipiche del mesh di servizi consistono in un piano dati e un piano di controllo. Il piano dati è responsabile della gestione diretta del traffico e dell'inoltro ai carichi di lavoro di destinazione, di solito tramite proxy collaterali. Il piano di controllo si riferisce ai componenti che configurano il piano dati.

Quando implementi il pattern mesh di servizi nella tua infrastruttura, puoi scegliere tra due prodotti Google Cloud: Cloud Service Mesh e Cloud Service Mesh. Entrambi i prodotti forniscono un piano di controllo per configurare il networking a livello di applicazione (L7) su più cluster GKE. Cloud Service Mesh si basa su Istio e offre API open source dichiarative. Cloud Service Mesh si basa su una combinazione di funzionalità di bilanciamento del carico di Google e tecnologie open source e offre API di Google imperative.

Cloud Service Mesh è una suite di strumenti gestita da Google che consente di connettere, gestire, proteggere e monitorare i carichi di lavoro indipendentemente dal cluster GKE in cui viene eseguito il deployment e senza modificare il codice dell'app. Per ulteriori informazioni su come utilizzare Cloud Service Mesh per configurare una rete mesh che copre più cluster GKE, consulta Aggiungere cluster GKE a Cloud Service Mesh. Per valutare Ingress multi-cluster e Cloud Service Mesh in base ai criteri stabiliti in precedenza, utilizza il seguente elenco, numerato in ordine di importanza relativa:

  1. Soluzione gestita da Google. Sia Ingress multi-cluster che Cloud Service mesh sono prodotti completamente gestiti. Non devi eseguire il provisioning di questi prodotti, perché sono gestiti da Google.
  2. Interfacce per interagire con l'architettura. Cloud Service Mesh utilizza Istio come principale. L'API Cloud Service Mesh supporta la configurazione dichiarativa basata sul modello di risorse di Kubernetes.
  3. Esponi servizi al di fuori dell'ambiente GKE. I gateway Ingress in Ingress multi-cluster e Cloud Service Mesh ti consentono di esporre i carichi di lavoro all'esterno dei cluster GKE.
  4. Comunicazione tra cluster. Cloud Service Mesh configura canali di comunicazione sicuri direttamente tra i pod, indipendentemente dal cluster in cui sono in esecuzione. Questa configurazione consente di evitare di spendere ulteriori sforzi per eseguire il provisioning e la configurazione di questi canali di comunicazione. Cloud Service Mesh utilizza il concetto di parchi risorse e uguaglianza dei servizi per estendere il servizio di rilevamento dei servizi GKE a più cluster. Pertanto, non devi modificare i carichi di lavoro per scoprire carichi di lavoro in esecuzione su altri cluster nel mesh.
  5. Gestione del traffico. Cloud Service Mesh offre funzionalità avanzate di gestione del traffico che puoi utilizzare per controllare il modo in cui il traffico in entrata viene protetto e instradato ai carichi di lavoro. Ad esempio, Cloud Service Mesh supporta tutte le funzionalità di gestione del traffico di Istio, come: fault injection, timeout e tentativi di richiesta, interruttori di sicurezza, Mirroring traffico e spostamento del traffico. Puoi utilizzare queste funzionalità di gestione del traffico anche per semplificare la migrazione a un nuovo ambiente GKE. Ad esempio, puoi spostare gradualmente il traffico dal vecchio a quello nuovo.
  6. Esegui il provisioning e la configurazione di strumenti aggiuntivi. Per utilizzare Ingress multi-cluster, devi soddisfare i prerequisiti di rilevamento dei servizi multi-cluster, ma non devi installare strumenti aggiuntivi nei cluster GKE. Per utilizzare Cloud Service Mesh, devi installarlo nei tuoi cluster.

Cloud Service Mesh

Cloud Service Mesh è un piano di controllo gestito per il networking delle applicazioni. Consente di eseguire il provisioning e la configurazione di topologie mesh di servizi avanzate con funzionalità avanzate di osservabilità e gestione del traffico. Per ulteriori informazioni su Cloud Service Mesh, consulta la panoramica di Cloud Service Mesh e le funzionalità di Cloud Service Mesh. Per eseguire il provisioning e configurare un mesh di servizi che copre più cluster GKE, puoi utilizzare una configurazione Cloud Service Mesh multi-cluster o multi-ambiente. Per valutare Cloud Service Mesh in base ai criteri stabiliti in precedenza, utilizza il seguente elenco, numerato in ordine di importanza relativa:

  1. Soluzione gestita da Google. Cloud Service Mesh è un prodotto completamente gestito. Non devi eseguire il provisioning di questi prodotti, perché Google li gestisce per te.
  2. Interfacce per interagire con l'architettura. Puoi configurare Cloud Service Mesh utilizzando la console Google Cloud, Google Cloud CLI, l'API Traffic Director o strumenti come Terraform. Cloud Service Mesh supporta un modello di configurazione imperativo ed è basato su prodotti e tecnologie open source come xDS e gRPC.
  3. Esponi servizi al di fuori dell'ambiente GKE. Puoi utilizzare Cloud Load Balancing per inviare il traffico in entrata dall'esterno ai servizi nella rete di servizi.
  4. Comunicazione tra cluster. Il piano di controllo Cloud Service Mesh offre API che consentono di raggruppare gli endpoint (ad esempio pod GKE su più cluster) in backend di servizio. Questi backend sono quindi instradabili da altri client nel mesh. Cloud Service Mesh non è integrato direttamente con Service Discovery GKE, ma puoi facoltativamente automatizzare l'integrazione utilizzando un controller open source come gke-autoneg-controller. Facoltativamente, puoi utilizzare Multi-Cluster Service Discovery per estendere il rilevamento dei servizi GKE a più cluster.
  5. Gestione del traffico. Cloud Service Mesh offre funzionalità avanzate di gestione del traffico che puoi utilizzare per semplificare la migrazione a un nuovo ambiente GKE e migliorare l'affidabilità della tua architettura. Per informazioni sulla configurazione di funzionalità quali routing del traffico granulare, suddivisione del traffico basata sul peso, Mirroring del traffico e bilanciamento del carico ottimizzato, consulta Configurazione della gestione avanzata del traffico.
  6. Esegui il provisioning e la configurazione di strumenti aggiuntivi. Cloud Service Mesh non viene eseguito nei tuoi cluster GKE. Per informazioni sul provisioning e sulla configurazione di Cloud Service Mesh, consulta Preparazione per la configurazione di Cloud Service Mesh. Per configurare i pod collaterali di cui Cloud Service Mesh deve includere i carichi di lavoro nella rete di servizi, consulta Deployment di Cloud Service Mesh con Envoy sui pod GKE.

Aggiornamenti dei record DNS autogestiti e di Kubernetes

Se non vuoi installare software aggiuntivo nel tuo cluster e non hai bisogno delle funzionalità fornite da un mesh di servizi, puoi scegliere l'opzione per gli aggiornamenti dei record DNS autogestiti e di Kubernetes.

Sebbene sia possibile configurare il rilevamento e la connettività tra cluster utilizzando questa opzione, ti consigliamo di scegliere una delle altre opzioni descritte in questo documento. Lo sforzo necessario per gestire una soluzione autogestita supera enormemente i vantaggi che potresti ottenere in cambio. Considera anche le seguenti importanti limitazioni:

Quando crei un servizio type: LoadBalancer o un oggetto Ingress in un cluster GKE, GKE crea automaticamente bilanciatori del carico di rete e bilanciatori del carico HTTP(S per esporre il servizio utilizzando l'indirizzo IP del bilanciatore del carico. Puoi utilizzare gli indirizzi IP dei bilanciatori del carico per comunicare con i tuoi servizi. Tuttavia, ti consigliamo di evitare di dipendere dagli indirizzi IP mappando questi indirizzi IP ai record DNS utilizzando Cloud DNS o agli endpoint di Service Directory su cui puoi eseguire query utilizzando il DNS e di configurare i client in modo che utilizzino questi record DNS. Puoi eseguire il deployment di più istanze del servizio e mappare tutti gli indirizzi IP del bilanciatore del carico risultanti al record DNS o all'endpoint di Service Directory correlato.

Per ritirare un'istanza di un servizio, devi prima rimuovere l'indirizzo IP del bilanciatore del carico correlato dal record DNS o dall'endpoint di Service Directory pertinente. Quindi ti assicuri che la cache DNS dei client sia aggiornata e poi ritiri il servizio.

Puoi configurare i carichi di lavoro in modo che possano comunicare tra loro in diversi cluster GKE. Per farlo, devi prima esporre i servizi all'esterno del cluster utilizzando bilanciatori del carico TCP/UDP interni o bilanciatori del carico HTTP(S) interni. Quindi, devi mappare gli indirizzi IP dei bilanciatori del carico ai record DNS o agli endpoint di Service Directory. Infine, creerai servizi di type: ExternalName che puntano a quei record DNS o agli endpoint di Service Directory in ciascun cluster.

Facoltativamente, puoi utilizzare un controller Ingress aggiuntivo per condividere un singolo bilanciatore del carico e un record Cloud DNS o un endpoint Service Directory con più carichi di lavoro. Ad esempio, se esegui il provisioning di un controller Ingress in un cluster, puoi configurarlo in modo che reindirizzi le richieste in arrivo al bilanciatore del carico che GKE crea per quel controller Ingress a più servizi. L'utilizzo di un controller Ingress aggiuntivo consente di ridurre il numero di record DNS o di endpoint di Service Directory da gestire.

Per valutare gli aggiornamenti dei record DNS autogestiti e di Kubernetes in base ai criteri che hai stabilito in precedenza, utilizza il seguente elenco, numerato in ordine di importanza relativa:

  1. Soluzione gestita da Google. Gestisci autonomamente gli oggetti Kubernetes che fanno parte di questa soluzione. Cloud DNS, Service Directory e bilanciamento del carico sono servizi gestiti da Google.
  2. Interfacce per interagire con l'architettura. GKE utilizza Kubernetes come base e supporta modelli di configurazione sia imperativi che dichiarativi.
  3. Esponi servizi al di fuori dell'ambiente GKE. Puoi utilizzare record DNS, endpoint di Service Directory e bilanciatori del carico per esporre i servizi ai client esterni ai cluster GKE.
  4. Comunicazione tra cluster. I servizi di type: ExternalName consentono di definire endpoint che puntano ai servizi di cui è stato eseguito il deployment nell'altro cluster GKE. Questa configurazione consente ai servizi di comunicare tra loro come se fosse stato eseguito il deployment nello stesso cluster.
  5. Gestione del traffico. La soluzione non offre ulteriori funzionalità di gestione del traffico diverse da quelle già offerte da Kubernetes e GKE. Ad esempio, questa opzione non supporta il partizionamento del traffico tra cluster diversi.
  6. Esegui il provisioning e la configurazione di strumenti aggiuntivi. Questa opzione non richiede il provisioning e la configurazione di software aggiuntivo nei cluster GKE. Facoltativamente, puoi installare un controller Ingress.

Selezionare un'architettura

Dopo aver assegnato un valore a ogni criterio per ogni opzione, viene calcolato il punteggio totale di ogni opzione. Per calcolare il punteggio totale di ogni opzione, devi aggiungere tutte le valutazioni per l'opzione di progettazione in questione in base ai criteri. Ad esempio, se un ambiente ha ottenuto un punteggio pari a 10 rispetto a un criterio e 6 rispetto a un altro criterio, il punteggio totale di quell'opzione è 16.

Puoi anche assegnare ponderazioni diverse al punteggio in base a ciascun criterio, in modo da poter rappresentare l'importanza di ogni criterio per la valutazione. Ad esempio, se una soluzione gestita da Google è più importante del supporto di un'architettura di carichi di lavoro distribuita nella valutazione, potresti definire moltiplicatori che riflettano questo fatto: un moltiplicatore di 1,0 per la soluzione gestita da Google e un moltiplicatore di 0,7 per l'architettura dei carichi di lavoro distribuiti. Puoi quindi usare questi moltiplicatori per calcolare il punteggio totale di un'opzione.

Dopo aver calcolato il punteggio totale di ogni ambiente valutato, organizza gli ambienti in base al punteggio totale in ordine decrescente. Quindi, scegli l'opzione con il punteggio più alto come ambiente di scelta.

Esistono diversi modi per rappresentare questi dati, ad esempio puoi visualizzare i risultati con un grafico adatto a rappresentare dati multivariati, come un grafico radar.

Esegui la migrazione dei dati dal vecchio ambiente a quello nuovo

Per indicazioni sulla migrazione dei dati dal vecchio ambiente al nuovo ambiente, consulta Migrazione di Kubernetes a GKE, Eseguire la migrazione dei dati dal vecchio ambiente a quello nuovo.

Esegui il deployment dei carichi di lavoro

Per indicazioni sulla migrazione dei dati dal vecchio ambiente a quello nuovo, consulta Eseguire il deployment dei carichi di lavoro.

Tutte le architetture proposte in questo documento consentono di eseguire la migrazione dei carichi di lavoro da un ambiente GKE esistente a un nuovo ambiente multi-cluster senza tempi di inattività o finestre di migrazione completa. Per eseguire la migrazione dei carichi di lavoro senza tempi di inattività, segui questi passaggi:

  1. Integra temporaneamente i cluster GKE legacy nel nuovo ambiente GKE multi-cluster.
  2. Esegui il deployment delle istanze dei tuoi carichi di lavoro nel tuo nuovo ambiente multi-cluster.
  3. Esegui la migrazione graduale del traffico dall'ambiente esistente per poter eseguire la migrazione graduale dei carichi di lavoro nei nuovi cluster GKE e quindi ritirare i cluster GKE legacy.

Completa il deployment

Dopo aver eseguito il provisioning e la configurazione della piattaforma di runtime e degli ambienti, completa le attività descritte in Migrazione di Kubernetes a GKE, Deployment dei carichi di lavoro.

Ottimizzazione dell'ambiente

L'ottimizzazione è l'ultima fase della migrazione. In questa fase, rendi il tuo ambiente più efficiente di prima. Per ottimizzare l'ambiente, completa più iterazioni del seguente loop ripetibile finché l'ambiente non soddisfa i requisiti di ottimizzazione:

  1. Valutazione dell'ambiente attuale, dei team e del ciclo di ottimizzazione.
  2. Stabilire i requisiti e gli obiettivi di ottimizzazione.
  3. Ottimizzazione dell'ambiente e dei team.
  4. Ottimizzazione del loop di ottimizzazione.

Per eseguire l'ottimizzazione dell'ambiente GKE, consulta Eseguire l'ottimizzazione dell'ambiente sulla migrazione di Kubernetes a GKE.

Passaggi successivi