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 non eseguita correttamente, spostare app da un ambiente all'altro può risultare 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, consulta Migrazione a Google Cloud: scelta del percorso di migrazione.

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

Questo documento è utile se prevedi 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 esplorarne l'aspetto.

I motivi per eseguire la migrazione da un ambiente GKE a un altro ambiente GKE possono includere i seguenti:

  • Abilitazione delle funzionalità GKE disponibili solo al momento della creazione del cluster. GKE è in evoluzione costante con nuove funzionalità e correzioni di sicurezza. Per usufruire della maggior parte delle nuove funzionalità e correzioni, potresti dover 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 sui cluster esistenti e richiedono la creazione di nuovi cluster GKE con le nuove funzionalità abilitate. Ad esempio, puoi abilitare il networking nativo VPC in GKE, Dataplane V2 o Nascondi i metadati solo quando crei nuovi cluster. Non puoi aggiornare la configurazione dei cluster esistenti per abilitare queste funzionalità dopo la loro creazione.

  • Implementazione di un processo automatizzato di provisioning e configurazione per la tua infrastruttura. Se esegui il provisioning e la configurazione manuale dell'infrastruttura, puoi progettare e implementare un processo automatizzato per il provisioning e la configurazione dei tuoi cluster GKE, invece di utilizzare metodi manuali e soggetti a errori.

Quando progetti l'architettura del nuovo ambiente, ti consigliamo di prendere in considerazione un ambiente GKE multi-cluster. Se esegui il provisioning e la configurazione di più cluster GKE nel tuo ambiente, ottieni quanto segue:

  • Riduci le possibilità di introdurre un single point of failure nell'architettura. Ad esempio, se un cluster subisce un'interruzione, altri cluster possono prenderne il controllo.
  • Sfrutta la maggiore flessibilità offerta da un ambiente multi-cluster. Ad esempio, applicando 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 tuoi carichi di lavoro di comunicare tra cluster. Ad esempio, i carichi di lavoro di cui è stato eseguito il deployment in un cluster possono comunicare con i carichi di lavoro di cui è stato eseguito il deployment in un altro cluster.

Le indicazioni contenute in questo documento si applicano anche a un ambiente GKE a cluster singolo. Quando esegui la migrazione a un ambiente GKE a cluster singolo, il tuo ambiente è meno complesso da gestire rispetto a un ambiente multi-cluster. Tuttavia, un ambiente a cluster singolo non beneficia della 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 con quattro fasi.

Il framework illustrato nel diagramma precedente include le seguenti fasi, definite in Migrazione a Google Cloud: Introduzione:

  1. Valutazione e scoperta dei carichi di lavoro.
  2. Pianificazione e costruzione di fondamenta.
  3. Deployment dei carichi di lavoro.
  4. Ottimizzare l'ambiente.

Segui le fasi precedenti durante ogni passaggio della migrazione. Questo documento si basa inoltre sui concetti trattati nella sezione Migrazione dei container in Google Cloud: migrazione di Kubernetes a GKE. Ove opportuno, includono i link.

Valutazione dell'ambiente

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 correttamente le risorse necessarie per la migrazione e l'ambiente di destinazione. Nella fase di valutazione, esegui le seguenti operazioni:

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

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

In Migrazione di Kubernetes a GKE, Valutare l'ambiente descrive come valutare i cluster e le risorse Kubernetes, come ServiceAccounts e PersistentVolume. Le informazioni si applicano anche alla valutazione del tuo ambiente GKE.

Crea i tuoi inventari

Per definire l'ambito della migrazione, devi comprendere il tuo attuale ambiente GKE. Inizia raccogliendo informazioni sui cluster, per poi concentrarti sui carichi di lavoro di cui è stato eseguito il deployment in questi cluster e sulle dipendenze dei carichi di lavoro. Alla fine della fase di valutazione, avrai due inventari: uno per i cluster e uno per i carichi di lavoro di cui è stato eseguito il deployment nei cluster.

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

Dopo aver seguito le indicazioni sulla migrazione da Kubernetes a GKE per creare gli inventari, perfezionali. Per completare l'inventario dei tuoi cluster GKE e dei tuoi pool di nodi, considera aspetti e funzionalità specifici di GKE per ogni cluster e pool di nodi, tra cui:

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 aspetti e funzionalità potenziali specifici di GKE, consulta la documentazione di GKE.

Completa la valutazione

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

Pianificazione e costruzione delle basi

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

  • Creare una gerarchia di risorse.
  • Configurare 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 tuoi cluster, pianifica con attenzione le allocazioni degli indirizzi IP, ad esempio puoi configurare IP pubblici utilizzati privatamente per GKE. Gli intervalli di indirizzi IP secondari che imposti per pod e servizi nei tuoi cluster non possono essere modificati dopo l'allocazione. Fai attenzione se assegni un intervallo di pod o servizi di /22 (1024 indirizzi) o inferiore. In caso contrario, potresti esaurire gli indirizzi IP per pod e servizi man mano che il cluster cresce. Per maggiori informazioni, consulta la sezione 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 i 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, esegui queste operazioni:

  1. Eseguire il provisioning e configurare l'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 dei carichi di lavoro in GKE. Si basa sulle informazioni contenute in Migrazione da Kubernetes a GKE: deployment dei carichi di lavoro.

Valuta la piattaforma e gli ambienti di runtime

Per avere un'infrastruttura più flessibile, affidabile e gestibile, ti consigliamo di progettare e implementare un'architettura multi-cluster. In un'architettura multi-cluster, il tuo ambiente dispone di 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 upgrade in sequenza o upgrade blu/verde. Per ulteriori informazioni sulle progettazioni dell'architettura 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 ulteriori sfide, tra cui:

  • Occorre 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 dovrai eseguire software aggiuntivo sul cluster, oltre ad automazione e infrastruttura aggiuntivi.

Per affrontare queste sfide, potresti avere bisogno di pipeline di integrazione continua/deployment continuo (CI/CD) per aggiornare la configurazione dei cluster in modo sequenziale al fine di ridurre al minimo l'impatto degli errori. Inoltre, potrebbero essere necessari bilanciatori del carico per distribuire il traffico da un cluster ad altri.

La gestione manuale dell'infrastruttura è soggetta a errori ed espone a problemi dovuti a configurazioni errate 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 di Infrastructure as Code. Quando applichi questo pattern, il provisioning dell'infrastruttura viene trattato nello 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. Ciascun tipo ha i suoi punti di forza e di debolezza. Per scegliere un tipo di architettura, segui questi passaggi:

  1. Stabilire un insieme di criteri per valutare i tipi di architetture degli ambienti GKE multi-cluster.
  2. Valuta ogni 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 ordine potenziale 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. C'è un'interfaccia comprensibile con cui puoi interagire? L'interfaccia è definita come uno standard aperto? L'interfaccia supporta direttive dichiarative, istruzioni imperative o entrambe?
  3. Esponi i 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 i canali di comunicazione tra i cluster? I carichi di lavoro supportano un'architettura distribuita? Questo criterio è importante per supportare i carichi di lavoro con una progettazione distribuita, ad esempio Jenkins.
  5. Gestione del traffico. L'architettura supporta funzionalità avanzate di gestione del traffico, come fault injection, spostamento del traffico, timeout e nuovi tentativi, 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 precedenti criteri di valutazione che hai stabilito. Utilizza una scala ordinata e arbitraria per assegnare a ogni opzione di progettazione un punteggio per ciascun criterio di valutazione. Ad esempio, puoi assegnare a ogni ambiente un punteggio su una scala da 1 a 10 in base a ciascun criterio di valutazione. Le opzioni seguenti sono presentate in ordine crescente di quanta impegno è necessario per gestire il nuovo ambiente GKE multi-cluster.

  1. Ingress multi-cluster e Rilevamento di servizi multi-cluster
  2. Multi Cluster Ingress e Anthos Service Mesh
  3. Traffic Director
  4. Aggiornamenti dei record DNS autogestiti e di Kubernetes

Le seguenti sezioni descrivono dettagliatamente 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, leggi la documentazione, puoi valutare Anthos Service Mesh in base ad alcuni criteri di valutazione che hai stabilito in precedenza. Tuttavia, per assegnare i punteggi in base 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.

Scoperta di servizi multi-cluster e Ingress 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 regioni diverse. Per ulteriori informazioni su come utilizzare Ingress multi-cluster in un ambiente GKE multi-cluster, consulta gli articoli Upgrade di GKE multi-cluster utilizzando Ingress multi-cluster e Supporto della migrazione con l'espansione mesh di Istio.

Multi-Cluster Service Discovery è un meccanismo di connettività e rilevamento di servizi tra cluster nativo di Kubernetes per GKE. Multi-Cluster Service Discovery si basa sulla risorsa Servizio Kubernetes per consentire alle app di rilevare e connettersi tra loro attraverso i confini del cluster. Per valutare Ingress multi-cluster e il rilevamento di servizi multi-cluster 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. Configura le risorse (zone e record Cloud DNS, regole firewall e Traffic Director) in modo che tu non debba gestirle.
  2. Interfacce per interagire con l'architettura. I servizi vengono esportati in altri cluster utilizzando una risorsa Kubernetes dichiarativa denominata ServiceExport.
  3. Esponi i servizi al di fuori dell'ambiente GKE. Quando utilizzi Ingress multi-cluster e Multi-Cluster Service Discovery, puoi esporre i carichi di lavoro all'esterno dei cluster GKE, indipendentemente da dove ne hai eseguito il deployment.
  4. Comunicazione tra cluster. Per esportare i servizi esistenti in altri cluster GKE, devi dichiarare un oggetto ServiceExport. I cluster GKE nello stesso parco risorse importano automaticamente i servizi esportati utilizzando oggetti ServiceExport. Multi-Cluster Service Discovery configura un indirizzo IP virtuale per ogni servizio esportato. Multi-Cluster Service Discovery configura automaticamente le risorse Traffic Director, Cloud DNS e le regole firewall per rilevare e connettersi 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. Multi-Cluster Service Discovery configura una connettività di livello 3/4 semplice 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 saperne di più, consulta Migrazione dei container in Google Cloud: migrazione a un ambiente GKE multi-cluster con Multi-Cluster Service Discovery e Ingress multi-cluster

Ingress multi-cluster e Anthos Service Mesh

Un mesh di servizi è un modello di architettura che aiuta a superare le sfide di rete delle app distribuite. Queste sfide includono Service Discovery, bilanciamento del carico, tolleranza di errore, controllo del traffico, osservabilità, autenticazione, autorizzazione e crittografia in transito. Le tipiche implementazioni di mesh di servizi sono costituite da 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 utilizzando proxy sidecar. 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: Anthos Service Mesh e Traffic Director. Entrambi i prodotti forniscono un piano di controllo per la configurazione di networking a livello applicazione (L7) su più cluster GKE. Anthos Service Mesh è basato su Istio e offre API open source dichiarative. Traffic Director è basato su una combinazione di funzionalità di bilanciamento del carico di Google, tecnologie open source e offre le API di Google imperative.

Anthos Service Mesh è una suite di strumenti gestita da Google che ti consente di connettere, gestire, proteggere e monitorare i carichi di lavoro indipendentemente dal cluster GKE su cui viene eseguito il deployment e senza modificare il codice dell'app. Per saperne di più su come utilizzare Anthos Service Mesh per configurare un mesh che si estende su più cluster GKE, consulta Aggiungere cluster GKE ad Anthos Service Mesh. Per valutare Ingress multi-cluster e Anthos 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 Multi Cluster Ingress che Anthos Service Mesh sono prodotti completamente gestiti. Non è necessario eseguire il provisioning di questi prodotti, perché Google li gestisce per te.
  2. Interfacce per interagire con l'architettura. Anthos Service Mesh utilizza Istio al suo interno. L'API Anthos Service Mesh supporta la configurazione dichiarativa basata sul modello di risorse Kubernetes.
  3. Esponi i servizi al di fuori dell'ambiente GKE. I gateway in Ingress multi-cluster e Anthos Service Mesh ti consentono di esporre i carichi di lavoro al di fuori dei tuoi cluster GKE.
  4. Comunicazione tra cluster. Anthos Service Mesh configura canali di comunicazione sicuri direttamente tra i pod, indipendentemente dal cluster in cui vengono eseguiti. Questa configurazione consente di evitare di spendere ulteriori sforzi per eseguire il provisioning e la configurazione di questi canali di comunicazione. Anthos Service Mesh utilizza il concetto di parchi risorse e identicità dei servizi per estendere il rilevamento dei servizi GKE a più cluster. Pertanto, non devi modificare i carichi di lavoro per rilevare quelli in esecuzione su altri cluster nel mesh.
  5. Gestione del traffico. Anthos Service Mesh fornisce 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, Anthos Service Mesh supporta tutte le funzionalità di gestione del traffico di Istio, come: fault injection, timeout e nuovi tentativi, interruttori di sicurezza, Mirroring del 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 dall'ambiente precedente a quello nuovo.
  6. Esegui il provisioning e la configurazione di strumenti aggiuntivi. Per utilizzare Ingress multi-cluster, devi soddisfare i prerequisiti di Multi-Cluster Service Discovery, ma non è necessario installare ulteriori strumenti nei tuoi cluster GKE. Per utilizzare Anthos Service Mesh, devi installarlo nei tuoi cluster.

Traffic Director

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

  1. Soluzione gestita da Google. Traffic Director è un prodotto completamente gestito. Non è necessario eseguire il provisioning di questi prodotti, perché è Google che li gestisce per te.
  2. Interfacce per interagire con l'architettura. Puoi configurare Traffic Director utilizzando la console Google Cloud, Google Cloud CLI, l'API Traffic Director o strumenti come Terraform. Traffic Director supporta un modello di configurazione imperativo e basato su prodotti e tecnologie open source, come xDS e gRPC.
  3. Esponi i 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 Traffic Director offre API che ti consentono di raggruppare gli endpoint (ad esempio i pod GKE su più cluster) in backend di servizio. Questi backend sono quindi instradabili da altri client nel mesh. Traffic Director non è direttamente integrato con il Service Discovery GKE, ma, se vuoi, puoi 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. Traffic Director fornisce funzionalità avanzate di gestione del traffico che puoi utilizzare per semplificare la migrazione in un nuovo ambiente GKE e migliorare l'affidabilità della tua architettura. Per informazioni sulla configurazione di funzionalità come il routing del traffico granulare, la suddivisione del traffico in base ai pesi, il Mirroring del traffico e il bilanciamento del carico ottimizzato, consulta Configurare la gestione avanzata del traffico.
  6. Esegui il provisioning e la configurazione di strumenti aggiuntivi. Traffic Director non viene eseguito nei tuoi cluster GKE. Per informazioni sul provisioning e sulla configurazione di Traffic Director, consulta Preparazione per la configurazione di Traffic Director. Per configurare i pod collaterali necessari a Traffic Director per includere i tuoi carichi di lavoro nella rete di servizi, consulta Deployment di Traffic Director 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 Kubernetes e gli aggiornamenti dei record DNS autogestiti.

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. L'impegno necessario per utilizzare una soluzione autogestita supera di molto i vantaggi che potresti ottenere. Considera anche le seguenti importanti limitazioni:

Quando crei un servizio type: LoadBalancer o un oggetto In entrata 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 su record DNS utilizzando Cloud DNS o su endpoint di Service Directory su cui puoi eseguire query con il DNS e di configurare i tuoi client per l'utilizzo di 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 ritira il servizio.

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

Facoltativamente, puoi utilizzare un controller in entrata aggiuntivo per condividere un singolo bilanciatore del carico e un record Cloud DNS o un endpoint di 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 a più servizi le richieste provenienti dal bilanciatore del carico creato da GKE per quel controller Ingress. L'utilizzo di un controller Ingress aggiuntivo consente di ridurre il numero di record DNS o di endpoint di Service Directory che devi gestire.

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

  1. Soluzione gestita da Google. Sei tu a gestire gli oggetti Kubernetes che fanno parte di questa soluzione. Cloud DNS, Service Directory e il bilanciamento del carico sono servizi gestiti da Google.
  2. Interfacce per interagire con l'architettura. GKE utilizza Kubernetes al meglio e supporta sia i modelli di configurazione imperativi che quelli dichiarativi.
  3. Esponi i servizi al di fuori dell'ambiente GKE. Puoi utilizzare i record DNS, gli endpoint di Service Directory e i bilanciatori del carico per esporre i servizi ai client esterni ai tuoi 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 fossero stati distribuiti nello stesso cluster.
  5. Gestione del traffico. La soluzione non offre funzionalità di gestione del traffico aggiuntive oltre a 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, potresti installare un controller Ingress.

Selezionare un'architettura

Dopo aver assegnato un valore a ciascun criterio per ciascuna opzione, calcoli il punteggio totale di ciascuna opzione. Per calcolare il punteggio totale di ogni opzione, aggiungi tutte le valutazioni per quell'opzione di progettazione in base ai criteri. Ad esempio, se un ambiente ha ottenuto 10 punti per un criterio e 6 per un altro criterio, il punteggio totale dell'opzione è 16.

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

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

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 dei dati di Kubernetes a GKE, Eseguire la migrazione dei dati dal vecchio ambiente al nuovo ambiente.

Esegui il deployment dei carichi di lavoro

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

Tutte le architetture proposte in questo documento ti 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à:

  1. Integra temporaneamente i tuoi cluster GKE legacy esistenti nel nuovo ambiente GKE multi-cluster.
  2. Esegui il deployment delle istanze dei tuoi carichi di lavoro nel nuovo ambiente multi-cluster.
  3. Esegui la migrazione graduale del traffico dal tuo ambiente esistente, in modo da poter eseguire gradualmente la migrazione dei carichi di lavoro ai nuovi cluster GKE, per poi ritirare i cluster GKE legacy.

Completa il deployment

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

Ottimizzare l'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 loop di ottimizzazione.
  2. Stabilire i requisiti e gli obiettivi di ottimizzazione.
  3. Ottimizzazione del tuo ambiente e dei tuoi team.
  4. Ottimizzazione del loop di ottimizzazione.

Per eseguire l'ottimizzazione dell'ambiente GKE, consulta Migrazione di Kubernetes a GKE, Ottimizzazione dell'ambiente.

Passaggi successivi