Migrazione da AWS a Google Cloud: migrazione da Amazon EKS a GKE

Last reviewed 2024-08-02 UTC

Google Cloud fornisce strumenti, prodotti, indicazioni e servizi professionali per la migrazione da Amazon Elastic Kubernetes Service (Amazon EKS) a Google Kubernetes Engine (GKE). Questo documento ti aiuta a progettare, implementare e convalidare un piano per la migrazione da Amazon EKS a GKE. Questo documento fornisce anche indicazioni se stai valutando l'opportunità di eseguire la migrazione e vuoi esplorare come potrebbe essere. Oltre a essere eseguito su Amazon Elastic Compute Cloud (Amazon EC2), Amazon EKS offre altre opzioni di deployment, come Amazon EKS su output AWS e Amazon EKS ovunque. Questo documento si concentra su Amazon EKS su EC2.

Questo documento fa parte di una serie in più parti sulla migrazione da AWS a Google Cloud che include i seguenti documenti:

GKE è un servizio Kubernetes gestito da Google che puoi utilizzare per eseguire il deployment e gestire applicazioni containerizzate su larga scala utilizzando l'infrastruttura di Google e fornisce funzionalità che ti aiutano a gestire l'ambiente Kubernetes, ad esempio:

  • Due versioni: GKE Standard e GKE Enterprise. Con GKE Standard, hai accesso a un livello standard di funzionalità di base. Con GKE Enterprise, hai accesso a tutte le funzionalità di GKE. Per maggiori informazioni, consulta Versioni di GKE.
  • Due modalità di funzionamento: Standard e Autopilot. Con Standard, gestisci l'infrastruttura sottostante e la configurazione di ogni nodo nel cluster GKE. Con Autopilot, GKE gestisce l'infrastruttura di base, ad esempio configurazione dei nodi, scalabilità automatica, upgrade automatici, configurazione di base della sicurezza e della rete. Per ulteriori informazioni sulle modalità operative di GKE, consulta Scegliere una modalità operativa di GKE.
  • Accordo sul livello del servizio unico nel settore per i pod quando utilizzi Autopilot in più zone.
  • Creazione ed eliminazione automatiche pool di nodi con il provisioning automatico dei nodi.
  • Networking multi-cluster gestito da Google per aiutarti a progettare e implementare architetture distribuite e a disponibilità elevata per i tuoi carichi di lavoro.

Per maggiori informazioni su GKE, consulta Panoramica di GKE.

Per questa migrazione a Google Cloud, ti consigliamo di seguire il framework di migrazione descritto in Migrazione a Google Cloud: Guida introduttiva.

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

Percorso di migrazione con quattro fasi.

Potresti eseguire la migrazione dall'ambiente di origine a Google Cloud in una serie di iterazioni. Ad esempio, potresti eseguire la migrazione di alcuni workload prima e di altri in un secondo momento. Per ogni iterazione di migrazione separata, segui le fasi del framework di migrazione generale:

  1. Valuta e scopri i tuoi workload e i tuoi dati.
  2. Pianifica e crea una base su Google Cloud.
  3. Esegui la migrazione dei carichi di lavoro e dei dati a Google Cloud.
  4. Ottimizza il tuo ambiente Google Cloud .

Per maggiori informazioni sulle fasi di questo framework, consulta la pagina Eseguire la migrazione a Google Cloud: guida introduttiva.

Per progettare un piano di migrazione efficace, ti consigliamo di convalidare ogni passaggio del piano e di assicurarti di avere una strategia di rollback. Per convalidare il piano di migrazione, consulta la pagina Eseguire la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione.

Valuta l'ambiente di origine

Nella fase di valutazione, determini i requisiti e le dipendenze per migrare l'ambiente di origine a Google Cloud.

La fase di valutazione è fondamentale per il successo della migrazione. Devi acquisire una conoscenza approfondita dei carichi di lavoro di cui vuoi eseguire la migrazione, dei loro requisiti, delle loro dipendenze e del tuo ambiente attuale. Devi comprendere il tuo punto di partenza per pianificare ed eseguire correttamente una Google Cloud migrazione.

La fase di valutazione è costituita dalle seguenti attività:

  1. Crea un inventario completo dei tuoi workload.
  2. Catalogare i carichi di lavoro in base alle loro proprietà e dipendenze.
  3. Forma e istruisci i tuoi team su Google Cloud.
  4. Crea esperimenti e proof of concept su Google Cloud.
  5. Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
  6. Scegli la strategia di migrazione per i tuoi workload.
  7. Scegli gli strumenti di migrazione.
  8. Definisci il piano di migrazione e le tempistiche.
  9. Convalida il piano di migrazione.

Per saperne di più sulla fase di valutazione e su queste attività, vedi Migrazione a Google Cloud: valutazione e individuazione dei carichi di lavoro. Le sezioni seguenti si basano sulle informazioni contenute in questo documento.

Creare gli inventari

Per definire l'ambito della migrazione, crea due inventari:

  1. L'inventario dei tuoi cluster.
  2. L'inventario dei carichi di lavoro di cui è stato eseguito il deployment in questi cluster.

Dopo aver creato questi inventari, puoi:

  1. Valuta i processi di deployment e operativi per l'ambiente di origine.
  2. Valuta i servizi di supporto e le dipendenze esterne.

Crea l'inventario dei tuoi cluster

Per creare l'inventario dei tuoi cluster, considera quanto segue per ciascun cluster:

  • Numero e tipo di nodi. Quando sai quanti nodi e le caratteristiche di ciascun nodo che hai nel tuo ambiente attuale, puoi dimensionare i cluster quando passi a GKE. I nodi nel tuo nuovo ambiente potrebbero essere eseguiti su un'architettura hardware o una generazione diversa da quelle utilizzate nel tuo ambiente. Le prestazioni di ogni architettura e generazione sono diverse, quindi il numero di nodi necessari nel nuovo ambiente potrebbe essere diverso da quello del tuo ambiente. Valuta qualsiasi tipo di hardware che utilizzi nei tuoi nodi, ad esempio dispositivi di archiviazione ad alte prestazioni, GPU e TPU. Valuta l'immagine del sistema operativo che utilizzi sui tuoi nodi.
  • Cluster interno o esterno. Valuta a quali attori, interni o esterni al tuo ambiente, è esposto ogni cluster. Per supportare i tuoi casi d'uso, questa valutazione include i carichi di lavoro in esecuzione nel cluster e le interfacce che interagiscono con i tuoi cluster.
  • Multi-tenancy. Se gestisci cluster multi-tenant nel tuo ambiente, valuta se funziona nel nuovo ambiente Google Cloud. Ora è un buon momento per valutare come migliorare i cluster multi-tenant, perché la tua strategia multi-tenant influisce sul modo in cui crei le fondamenta su Google Cloud.
  • Versione di Kubernetes. Raccogli informazioni sulla versione di Kubernetes dei tuoi cluster per valutare se esiste una mancata corrispondenza tra queste versioni e quelle disponibili in GKE. Se esegui una versione di Kubernetes precedente o rilasciata di recente, potresti utilizzare funzionalità non disponibili in GKE. Le funzionalità potrebbero essere ritirate o la versione di Kubernetes che le include non è ancora disponibile in GKE.
  • Ciclo di upgrade di Kubernetes. Per mantenere un ambiente affidabile, comprendi come gestisci gli upgrade di Kubernetes e in che modo il tuo ciclo di upgrade si relaziona agli upgrade di GKE.
  • Pool di nodi. Se utilizzi qualsiasi forma di raggruppamento dei nodi, ti consigliamo di valutare la mappatura di questi raggruppamenti al concetto di node pool in GKE, perché i tuoi criteri di raggruppamento potrebbero non essere adatti a GKE.
  • Inizializzazione del nodo. Valuta come inizializzi ogni nodo prima di contrassegnarlo come disponibile per l'esecuzione dei tuoi carichi di lavoro, in modo da poter trasferire queste procedure di inizializzazione a GKE.
  • Configurazione di rete. Valuta la configurazione di rete dei tuoi cluster, l'allocazione degli indirizzi IP, la configurazione dei plug-in di rete, la configurazione dei server DNS e dei fornitori di servizi DNS, se hai configurato una forma di NAT o SNAT per questi cluster e se fanno parte di un ambiente multicluster.
  • Conformità: valuta i requisiti normativi e di conformità che i tuoi cluster devono soddisfare e se li stai rispettando.
  • Quote e limiti. Valuta la configurazione di quote e limiti per i tuoi cluster. Ad esempio, quanti pod può eseguire ogni nodo? Quanti nodi può avere un cluster?
  • Etichette e tag. Valuta i metadati che hai applicato a cluster, pool di nodi e nodi e il modo in cui li utilizzi. Ad esempio, potresti generare report con un'attribuzione dei costi dettagliata e basata sulle etichette.

I seguenti elementi che valuti nel tuo inventario si concentrano sulla sicurezza della tua infrastruttura e dei tuoi cluster Kubernetes:

  • Spazi dei nomi. Se utilizzi gli spazi dei nomi Kubernetes nei tuoi cluster per separare logicamente le risorse, valuta quali risorse si trovano in ogni spazio dei nomi e comprendi il motivo per cui hai creato questa separazione. Ad esempio, potresti utilizzare gli spazi dei nomi nell'ambito della tua strategia multi-tenant. Potresti avere carichi di lavoro di cui è stato eseguito il deployment in spazi dei nomi riservati ai componenti di sistema di Kubernetes e potresti non avere lo stesso controllo in GKE.
  • Controllo controllo dell'accesso basato sui ruoli (RBAC). Se utilizzi l'autorizzazione RBAC nei tuoi cluster, elenca una descrizione di tutti i ClusterRole e i ClusterRoleBinding che hai configurato nei tuoi cluster.
  • Norme di rete. Elenca tutti i criteri di rete che hai configurato nei tuoi cluster e scopri come funzionano i criteri di rete in GKE.
  • Contesti di sicurezza dei pod. Acquisisci informazioni sui contesti di sicurezza dei pod che hai configurato nei tuoi cluster e scopri come funzionano in GKE.
  • Service account. Se un processo nel cluster interagisce con il server API Kubernetes, acquisisci informazioni sugli account di servizio che utilizza.

Quando crei l'inventario dei tuoi cluster Kubernetes, potresti scoprire che alcuni dei cluster devono essere ritirati nell'ambito della migrazione. Assicurati che il tuo piano di migrazione includa il ritiro di queste risorse.

Crea l'inventario dei tuoi carichi di lavoro Kubernetes

Dopo aver completato l'inventario dei cluster Kubernetes e valutato la sicurezza del tuo ambiente, crea l'inventario dei carichi di lavoro di cui è stato eseguito il deployment in questi cluster. Quando valuti i tuoi carichi di lavoro, raccogli informazioni sui seguenti aspetti:

  • Pod e controller. Per dimensionare i cluster nel nuovo ambiente, valuta il numero di istanze di ogni carico di lavoro che hai implementato e se utilizzi quote di risorse e limiti di consumo delle risorse di calcolo. Raccogli informazioni sui workload in esecuzione sui nodi del piano di controllo di ciascun cluster e sui controller utilizzati da ciascun workload. Ad esempio, quanti Deployment utilizzi? Quanti DaemonSets stai utilizzando?
  • Job e CronJobs. I tuoi cluster e carichi di lavoro potrebbero dover eseguire job o CronJob nell'ambito delle procedure di inizializzazione o funzionamento. Valuta il numero di istanze di Job e CronJob che hai eseguito il deployment e le responsabilità e i criteri di completamento per ogni istanza.
  • Scalabilità automatica di Kubernetes. Per eseguire la migrazione delle tue norme di scalabilità automatica nel nuovo ambiente, scopri come funzionano Horizontal Pod Autoscaler e Vertical Pod Autoscaler su GKE.
  • Carichi di lavoro stateless e stateful. I carichi di lavoro stateless non archiviano dati o stato nel cluster o in uno spazio di archiviazione permanente. Le applicazioni stateful salvano i dati per un utilizzo futuro. Per ogni carico di lavoro, valuta quali componenti sono stateless e quali stateful, perché la migrazione dei carichi di lavoro stateful è in genere più difficile di quella dei carichi di lavoro stateless.
  • Funzionalità di Kubernetes. Dall'inventario dei cluster, sai quale versione di Kubernetes esegue ogni cluster. Consulta le note di rilascio di ogni versione di Kubernetes per sapere quali funzionalità include e quali funzionalità ritira. Poi valuta i tuoi workload in base alle funzionalità di Kubernetes di cui hai bisogno. Lo scopo di questa attività è sapere se utilizzi funzionalità deprecate o non ancora disponibili in GKE. Se trovi funzionalità non disponibili, esegui la migrazione dalle funzionalità obsolete e adotta quelle nuove quando saranno disponibili in GKE.
  • Archiviazione. Per i carichi di lavoro stateful, valuta se utilizzano PersistenceVolumeClaims. Elenca eventuali requisiti di archiviazione, come dimensioni e modalità di accesso, e come questi PersistentVolumeClaim vengono mappati a PersistentVolume. Per tenere conto della crescita futura, valuta se devi espandere PersistenceVolumeClaim.
  • Configurazione e inserimento dei secret. Per evitare di ricompilare gli artefatti deployable ogni volta che viene modificata la configurazione dell'ambiente, inserisci la configurazione e i secret nei pod utilizzando ConfigMaps e Secret. Per ogni carico di lavoro, valuta quali ConfigMap e Secret vengono utilizzati e come vengono compilati questi oggetti.
  • Dipendenze. Probabilmente i tuoi carichi di lavoro non funzionano in isolamento. Potrebbero avere dipendenze, interne al cluster o da sistemi esterni. Per ogni carico di lavoro, acquisisci le dipendenze e, se i tuoi carichi di lavoro hanno una tolleranza per quando le dipendenze non sono disponibili. Ad esempio, le dipendenze comuni includono file system distribuiti, database, piattaforme di distribuzione dei secret, sistemi di gestione dell'identità e dell'accesso, meccanismi di Service Discovery e qualsiasi altro sistema esterno.
  • Servizi Kubernetes. Per esporre i carichi di lavoro a client interni ed esterni, utilizza i servizi. Per ogni servizio, devi conoscere il tipo. Per i servizi esposti esternamente, valuta in che modo il servizio interagisce con il resto dell'infrastruttura. Ad esempio, in che modo la tua infrastruttura supporta i servizi LoadBalancer, gli oggetti Gateway e gli oggetti Ingress? Quali controller Ingress hai eseguito il deployment nei tuoi cluster?
  • Service Mesh. Se utilizzi un mesh di servizi nel tuo ambiente, valuta la sua configurazione. Devi anche sapere quanti cluster copre, quali servizi fanno parte del mesh e come modificare la topologia del mesh.
  • Incompatibilità e tolleranze e affinità e anti-affinità. Per ogni pod e nodo, valuta se hai configurato incompatibilità dei nodi, tolleranze dei pod o affinità per personalizzare la pianificazione dei pod nei cluster Kubernetes. Queste proprietà potrebbero anche fornirti informazioni su possibili configurazioni non omogenee di nodi o pod e potrebbero significare che i pod, i nodi o entrambi devono essere valutati con particolare attenzione e cura. Ad esempio, se hai configurato un determinato insieme di pod da pianificare solo su determinati nodi del cluster Kubernetes, potrebbe significare che i pod hanno bisogno di risorse specializzate disponibili solo su questi nodi.
  • Autenticazione: valuta in che modo i tuoi carichi di lavoro eseguono l'autenticazione rispetto alle risorse nel tuo cluster e rispetto alle risorse esterne.

Valuta i servizi di supporto e le dipendenze esterne

Dopo aver valutato i cluster e i relativi carichi di lavoro, valuta il resto dei servizi e degli aspetti di supporto nella tua infrastruttura, ad esempio:

  • StorageClasses e PersistentVolumes. Valuta in che modo la tua infrastruttura supporta PersistentVolumeClaim elencando le StorageClasses per il provisioning dinamico e i PersistentVolume PersistentVolumes. Per ogni PersistentVolume, considera quanto segue: capacità, modalità del volume, modalità di accesso, classe, criterio di recupero, opzioni di montaggio e affinità del nodo.
  • VolumeSnapshots e VolumeSnapshotContents. Per ogni PersistentVolume, valuta se hai configurato VolumeSnapshot e se devi eseguire la migrazione di eventuali VolumeSnapshotContents esistenti.
  • Driver Container Storage Interface (CSI). Se sono stati implementati nei tuoi cluster, valuta se questi driver sono compatibili con GKE e se devi adattare la configurazione dei volumi per funzionare con i driver CSI compatibili con GKE.
  • Archiviazione dati. Se dipendi da sistemi esterni per il provisioning di PersistentVolume, fornisci un modo per consentire ai workload nel tuo ambiente GKE di utilizzare questi sistemi. La località dei dati influisce sulle prestazioni dei carichi di lavoro stateful, perché la latenza tra i sistemi esterni e l'ambiente GKE è proporzionale alla distanza tra loro. Per ogni sistema di archiviazione di dati esterno, considera il tipo, ad esempio volumi a blocchi, archiviazione di file o archiviazione di oggetti, e tutti i requisiti di prestazioni e disponibilità che deve soddisfare.
  • Risorse personalizzate e componenti aggiuntivi di Kubernetes. Raccogli informazioni su eventuali risorse Kubernetes personalizzate e su eventuali componenti aggiuntivi Kubernetes che potresti aver eseguito il deployment nei tuoi cluster, perché potrebbero non funzionare in GKE o potresti doverli modificare. Ad esempio, se una risorsa personalizzata interagisce con un sistema esterno, valuta se è applicabile al tuo ambiente Google Cloud .
  • Backup. Valuta il backup della configurazione dei cluster e dei dati dei carichi di lavoro stateful nell'ambiente di origine.

Valuta i processi di deployment e operativi

È importante avere una chiara comprensione del funzionamento dei processi di deployment e operativi. Questi processi sono una parte fondamentale delle pratiche che preparano e mantengono il tuo ambiente di produzione e i workload che vengono eseguiti al suo interno.

I processi di deployment e operativi potrebbero creare gli artefatti necessari per il funzionamento dei tuoi workload. Pertanto, devi raccogliere informazioni su ogni tipo di artefatto. Ad esempio, un artefatto può essere un pacchetto del sistema operativo, un pacchetto di deployment dell'applicazione, un'immagine del sistema operativo, un'immagine container o qualcos'altro.

Oltre al tipo di artefatto, considera come completare le seguenti attività:

  • Sviluppa i tuoi carichi di lavoro. Valuta i processi che i team di sviluppo hanno in atto per creare i tuoi carichi di lavoro. Ad esempio, in che modo i tuoi team di sviluppo progettano, codificano e testano i tuoi carichi di lavoro?
  • Genera gli artefatti di cui esegui il deployment nell'ambiente di origine. Per eseguire il deployment dei tuoi workload nell'ambiente di origine, potresti generare artefatti di cui è possibile eseguire il deployment, come immagini container o immagini del sistema operativo, oppure potresti personalizzare artefatti esistenti, come immagini del sistema operativo di terze parti installando e configurando il software. La raccolta di informazioni su come generi questi artefatti ti aiuta a assicurarti che siano adatti al deployment in Google Cloud.

  • Archivia gli artefatti. Se produci artefatti che archivi in un registro degli artefatti nell'ambiente di origine, devi renderli disponibili nell'ambiente Google Cloud . Puoi farlo utilizzando strategie come le seguenti:

    • Stabilisci un canale di comunicazione tra gli ambienti: rendi gli artefatti nell'ambiente di origine raggiungibili dall'ambienteGoogle Cloud di destinazione.
    • Esegui il refactoring del processo di creazione degli artefatti: completa un refactoring secondario dell'ambiente di origine in modo da poter archiviare gli artefatti sia nell'ambiente di origine sia in quello di destinazione. Questo approccio supporta la migrazione creando un'infrastruttura come un repository di artefatti prima di dover implementare i processi di creazione degli artefatti nell'ambiente di destinazione. Google CloudPuoi implementare questo approccio direttamente oppure puoi basarti sull'approccio precedente di stabilire prima un canale di comunicazione.

    La disponibilità degli artefatti sia nell'ambiente di origine sia in quello di destinazione ti consente di concentrarti sulla migrazione senza dover implementare processi di compilazione degli artefatti nell'ambiente di destinazione Google Cloud nell'ambito della migrazione.

  • Scansiona e firma il codice. Nell'ambito dei processi di creazione degli artefatti, potresti utilizzare la scansione del codice per proteggerti da vulnerabilità comuni e dall'esposizione involontaria della rete, nonché la firma del codice per assicurarti che nei tuoi ambienti venga eseguito solo codice attendibile.

  • Esegui il deployment degli artefatti nell'ambiente di origine. Dopo aver generato gli artefatti di cui è possibile eseguire il deployment, potresti eseguirne il deployment nell'ambiente di origine. Ti consigliamo di valutare ogni processo di deployment. L'analisi aiuta a garantire che i processi di deployment siano compatibili con Google Cloud. Ti aiuta anche a comprendere l'impegno necessario per eventualmente eseguire il refactoring dei processi. Ad esempio, se i processi di deployment funzionano solo con l'ambiente di origine, potresti doverli refactorizzare per indirizzarli all'ambiente Google Cloud .

  • Inserisci la configurazione di runtime. Potresti inserire la configurazione di runtime per cluster, ambienti di runtime o deployment di workload specifici. La configurazione potrebbe inizializzare variabili di ambiente e altri valori di configurazione come secret, credenziali e chiavi. Per contribuire a garantire che i processi di inserimento della configurazione di runtime funzionino su Google Cloud, ti consigliamo di valutare come configuri i workload eseguiti nell'ambiente di origine.

  • Logging, monitoraggio e profilazione. Valuta i processi di logging, monitoraggio e profilazione che hai implementato per monitorare l'integrità del tuo ambiente di origine, le metriche di interesse e il modo in cui utilizzi i dati forniti da questi processi.

  • Autenticazione. Valuta l'autenticazione rispetto all'ambiente di origine.

  • Esegui il provisioning e la configurazione delle risorse. Per preparare l'ambiente di origine, potresti aver progettato e implementato processi che eseguono il provisioning e la configurazione delle risorse. Ad esempio, potresti utilizzare Terraform insieme a strumenti di gestione della configurazione per eseguire il provisioning e configurare le risorse nell'ambiente di origine.

Strumenti per creare l'inventario dell'ambiente di origine

Per creare l'inventario dei cluster Amazon EKS, ti consigliamo di utilizzare Migration Center, la piattaforma unificata diGoogle Cloudche ti consente di accelerare il percorso verso il cloud end-to-end dall'ambiente attuale a Google Cloud. Migration Center ti consente di importare dati da Amazon EKS e altre risorse AWS. Il Centro di migrazione consiglia quindi i servizi Google Cloud pertinenti a cui puoi eseguire la migrazione.

Perfeziona l'inventario dei cluster e dei workload Amazon EKS

I dati forniti da Migration Center potrebbero non acquisire completamente le dimensioni che ti interessano. In questo caso, puoi integrare questi dati con i risultati di altri meccanismi di raccolta dei dati che crei in base alle API AWS, agli strumenti per sviluppatori AWS e all'interfaccia a riga di comando AWS.

Oltre ai dati ottenuti da Migration Center, considera i seguenti punti dati per ogni cluster Amazon EKS di cui vuoi eseguire la migrazione:

  • Prendi in considerazione gli aspetti e le funzionalità specifici di Amazon EKS per ogni cluster Amazon EKS, tra cui quanto segue:
    • Cluster privati
    • Controllo dell'accesso agli endpoint del cluster
    • Crittografia dei secret
    • Gruppi di nodi gestiti e nodi autogestiti
    • Tag sulle risorse Amazon EKS
    • AMI personalizzate Amazon in EKS
    • Utilizzo di Amazon EKS Fargate
    • Utilizzo di Amazon EKS Managed Prometheus
    • Configurazione dell'autenticazione OpenID Connect
  • Valuta l'autenticazione rispetto ai cluster Amazon EKS e la configurazione di AWS Identity and Access Management (IAM) per Amazon EKS.
  • Valuta la configurazione di rete dei tuoi cluster Amazon EKS.

Pianificare e creare le basi

Nella fase di pianificazione e creazione, esegui il provisioning e la configurazione dell'infrastruttura per svolgere le seguenti operazioni:

  • Supporta i tuoi carichi di lavoro nel tuo ambiente Google Cloud .
  • Collega l'ambiente di origine e l'ambiente Google Cloud per completare la migrazione.

La fase di pianificazione e creazione è composta dalle seguenti attività:

  1. Crea una gerarchia delle risorse.
  2. Configura Identity and Access Management (IAM) di Google Cloud.
  3. Configura la fatturazione.
  4. Configura la connettività di rete.
  5. Rafforza la tua sicurezza.
  6. Configura logging, monitoraggio e avvisi.

Per maggiori informazioni su ciascuna di queste attività, consulta la sezione Eseguire la migrazione a Google Cloud: pianificare e creare le basi.

Le sezioni seguenti integrano le considerazioni in Esegui la migrazione a Google Cloud: pianifica e crea le basi.

Pianificare la multitenancy

Per progettare una gerarchia delle risorse efficiente, considera come le strutture aziendali e organizzative vengono mappate a Google Cloud. Ad esempio, se hai bisogno di un ambiente multi-tenant su GKE, puoi scegliere tra le seguenti opzioni:

  • Creazione di un Google Cloud progetto per ogni tenant.
  • Condivisione di un progetto tra tenant diversi e provisioning di più cluster GKE.
  • Utilizzo degli spazi dei nomi Kubernetes.

La scelta dipende dalle tue esigenze di isolamento, complessità e scalabilità. Ad esempio, avere un progetto per tenant isola i tenant l'uno dall'altro, ma la gerarchia delle risorse diventa più complessa da gestire a causa dell'elevato numero di progetti. Tuttavia, anche se la gestione degli spazi dei nomi Kubernetes è relativamente più semplice di una gerarchia di risorse complessa, questa opzione non garantisce lo stesso livello di isolamento. Ad esempio, il control plane potrebbe essere condiviso tra i tenant. Per maggiori informazioni, consulta Multitenancy del cluster.

Configura la gestione di identità e accessi

GKE supporta più opzioni per gestire l'accesso alle risorse all'interno del tuo progetto Google Cloud e dei relativi cluster utilizzando RBAC. Per saperne di più, vedi Controllo dell'accesso.

Configura il networking di GKE

La configurazione di rete è un aspetto fondamentale del tuo ambiente. Prima di eseguire il provisioning e configurare qualsiasi cluster, ti consigliamo di valutare il modello di rete GKE, le best practice per il networking GKE e come pianificare gli indirizzi IP durante la migrazione a GKE.

Configurare il monitoraggio e gli avvisi

Avere un quadro chiaro del rendimento dell'infrastruttura e dei carichi di lavoro è fondamentale per individuare le aree di miglioramento. GKE ha integrazioni profonde con Google Cloud Observability, in modo da ottenere informazioni su logging, monitoraggio e profilazione dei tuoi cluster GKE e dei workload all'interno di questi cluster.

Migrazione dei dati e deployment dei carichi di lavoro

Nella fase di deployment, devi:

  1. Esegui il provisioning e la configurazione dell'ambiente GKE.
  2. Configura i cluster GKE.
  3. Esegui il refactoring dei tuoi workload.
  4. Esegui il refactoring dei processi di deployment e operativi.
  5. Esegui la migrazione dei dati dal tuo ambiente di origine a Google Cloud.
  6. Esegui il deployment dei carichi di lavoro nell'ambiente GKE.
  7. Convalida i tuoi carichi di lavoro e l'ambiente GKE.
  8. Esporre i carichi di lavoro in esecuzione su GKE.
  9. Shift il traffico dall'ambiente di origine all'ambiente GKE.
  10. Ritira l'ambiente di origine.

Esegui il provisioning e la configurazione del tuo Google Cloud ambiente

Prima di spostare qualsiasi carico di lavoro nel nuovo ambiente Google Cloud , devi eseguire il provisioning dei cluster GKE.

GKE supporta l'abilitazione di determinate funzionalità sui cluster esistenti, ma potrebbero esserci funzionalità che puoi abilitare solo al momento della creazione del cluster. Per evitare interruzioni e semplificare la migrazione, ti consigliamo di attivare le funzionalità del cluster di cui hai bisogno al momento della creazione del cluster. In caso contrario, potresti dover eliminare e ricreare i cluster nel caso in cui le funzionalità del cluster di cui hai bisogno non possano essere attivate dopo la creazione di un cluster.

Dopo la fase di valutazione, ora sai come eseguire il provisioning dei cluster GKE nel nuovo ambiente Google Cloud per soddisfare le tue esigenze. Per eseguire il provisioning dei cluster, tieni presente quanto segue:

Per saperne di più sul provisioning dei cluster GKE, consulta:

Gestione del parco risorse

Quando esegui il provisioning dei cluster GKE, potresti renderti conto di averne bisogno di un numero elevato per supportare tutti i casi d'uso del tuo ambiente. Ad esempio, potresti dover separare gli ambienti di produzione da quelli non di produzione o separare i servizi tra team o aree geografiche. Per ulteriori informazioni, vedi Casi d'uso multi-cluster.

Man mano che il numero di cluster aumenta, il tuo ambiente GKE potrebbe diventare più difficile da gestire, perché la gestione di un numero elevato di cluster pone sfide operative e di scalabilità significative. GKE fornisce strumenti e funzionalità per aiutarti a gestire i parchi risorse, un raggruppamento logico di cluster Kubernetes. Per saperne di più, consulta Gestione della flotta.

Networking multi-cluster

Per migliorare l'affidabilità del tuo ambiente GKE e distribuire i carichi di lavoro su più cluster GKE, puoi utilizzare:

  • Service Discovery multi-cluster, un meccanismo di invocazione e rilevamento dei servizi tra cluster. I servizi sono rilevabili e accessibili nei cluster GKE. Per saperne di più, consulta Multi-Cluster Service Discovery.
  • Gateway multi-cluster, un meccanismo di bilanciamento del carico del traffico in entrata tra cluster. Per saperne di più, consulta la sezione Deployment di gateway multi-cluster.
  • Mesh multicluster su Cloud Service Mesh gestito. Per maggiori informazioni, consulta Configurare un mesh multicluster.

Per saperne di più sulla migrazione da un ambiente GKE a cluster singolo a un ambiente GKE multi-cluster, consulta la pagina Eseguire la migrazione al networking multi-cluster.

Configura i cluster GKE

Dopo aver eseguito il provisioning dei cluster GKE e prima di eseguire il deployment di qualsiasi carico di lavoro o migrazione dei dati, configura spazi dei nomi, RBAC, criteri di rete, service account e altri oggetti Kubernetes e GKE per ogni cluster GKE.

Per configurare gli oggetti Kubernetes e GKE nei cluster GKE, ti consigliamo di:

  1. Assicurati di disporre delle credenziali e delle autorizzazioni necessarie per accedere sia ai cluster nell'ambiente di origine sia nell'ambiente GKE.
  2. Valuta se gli oggetti nei cluster Kubernetes del tuo ambiente di origine sono compatibili con GKE e in che modo le implementazioni che supportano questi oggetti differiscono dall'ambiente di origine e da GKE.
  3. Esegui il refactoring di qualsiasi oggetto incompatibile per renderlo compatibile con GKE o ritiralo.
  4. Crea questi oggetti nei tuoi cluster GKE.
  5. Configura eventuali oggetti aggiuntivi necessari nei cluster GKE.

Config Sync

Per aiutarti ad adottare le best practice di GitOps per gestire la configurazione dei tuoi cluster GKE man mano che GKE viene scalato, ti consigliamo di utilizzare Config Sync, un servizio GitOps per eseguire il deployment delle configurazioni da una fonte attendibile. Ad esempio, puoi archiviare la configurazione dei tuoi cluster GKE in un repository Git e utilizzare Config Sync per applicarla.

Per saperne di più, vedi Architettura di Config Sync.

Policy Controller

Policy Controller ti aiuta ad applicare e far rispettare i criteri programmabili per garantire che i tuoi cluster e carichi di lavoro GKE vengano eseguiti in modo sicuro e conforme. Man mano che il tuo ambiente GKE viene scalato, puoi utilizzare Policy Controller per applicare automaticamente policy, bundle di policy e vincoli a tutti i tuoi cluster GKE. Ad esempio, puoi limitare i repository da cui è possibile estrarre le immagini container oppure puoi richiedere che ogni spazio dei nomi abbia almeno un'etichetta per aiutarti a garantire un monitoraggio accurato del consumo di risorse.

Per maggiori informazioni, vedi Policy Controller.

Refactoring dei workload

Una best practice per progettare carichi di lavoro containerizzati consiste nell'evitare dipendenze dalla piattaforma di orchestrazione dei container. Ciò potrebbe non essere sempre possibile in pratica a causa dei requisiti e della progettazione dei tuoi workload. Ad esempio, i tuoi carichi di lavoro potrebbero dipendere da funzionalità specifiche dell'ambiente disponibili solo nell'ambiente di origine, come componenti aggiuntivi, estensioni e integrazioni.

Anche se potresti essere in grado di eseguire la migrazione della maggior parte dei carichi di lavoro così com'è a GKE, potresti dover dedicare ulteriore impegno al refactoring dei carichi di lavoro che dipendono da funzionalità specifiche dell'ambiente, al fine di ridurre al minimo queste dipendenze, passando infine ad alternative disponibili su GKE.

Per eseguire il refactoring dei carichi di lavoro prima di eseguirne la migrazione a GKE, procedi nel seguente modo:

  1. Esamina le funzionalità specifiche dell'ambiente di origine, come componenti aggiuntivi, estensioni e integrazioni.
  2. Adotta soluzioni GKE alternative adatte.
  3. Esegui il refactoring dei tuoi workload.

Esamina le funzionalità specifiche dell'ambiente di origine

Se utilizzi funzionalità specifiche dell'ambiente di origine e i tuoi carichi di lavoro dipendono da queste funzionalità, devi:

  1. Trova alternative adatte alle soluzioni GKE.
  2. Esegui il refactoring dei carichi di lavoro per utilizzare le soluzioni GKE alternative.

Nell'ambito di questa revisione, ti consigliamo di procedere come segue:

  • Valuta se puoi ritirare una di queste funzionalità specifiche dell'ambiente di origine.
  • Valuta quanto sia critica una funzionalità specifica dell'ambiente di origine per il successo della migrazione.

Adotta soluzioni GKE alternative adeguate

Dopo aver esaminato le funzionalità specifiche dell'ambiente di origine e averle mappate a soluzioni alternative GKE adatte, adotti queste soluzioni nel tuo ambiente GKE. Per ridurre la complessità della migrazione, ti consigliamo di procedere come segue:

  • Evita di adottare soluzioni GKE alternative per le funzionalità specifiche dell'ambiente di origine che vuoi ritirare.
  • Concentrati sull'adozione di soluzioni GKE alternative per le funzionalità più critiche specifiche dell'ambiente di origine e pianifica progetti di migrazione dedicati per il resto.

Refactoring dei workload

Sebbene la maggior parte dei tuoi carichi di lavoro possa funzionare così com'è in GKE, potresti doverne eseguire il refactoring di alcuni, soprattutto se dipendevano da funzionalità specifiche dell'ambiente di origine per le quali hai adottato soluzioni GKE alternative.

Questo refactoring potrebbe comportare:

  • Descrittori di oggetti Kubernetes, come deployment e servizi, espressi in formato YAML.
  • Descrittori di immagini container, come Dockerfile e Containerfile.
  • Codice sorgente dei carichi di lavoro.

Per semplificare l'attività di refactoring, ti consigliamo di concentrarti sull'applicazione del minor numero di modifiche necessarie per rendere i tuoi carichi di lavoro adatti a GKE e sulle correzioni di bug critici. Puoi pianificare altri miglioramenti e modifiche nell'ambito di progetti futuri.

Riorganizzare i processi di deployment e operativi

Dopo aver eseguito il refactoring dei carichi di lavoro, esegui il refactoring dei processi di deployment e operativi per:

  • Esegui il provisioning e la configurazione delle risorse nel tuo Google Cloud ambiente anziché eseguire il provisioning delle risorse nell'ambiente di origine.
  • Crea e configura i carichi di lavoro e implementali in Google Cloud anziché nell'ambiente di origine.

Hai raccolto informazioni su questi processi durante la fase di valutazione precedente.

Il tipo di refactoring da considerare per questi processi dipende da come li hai progettati e implementati. Il refactoring dipende anche dallo stato finale che vuoi ottenere per ogni processo. Ad esempio, prendi in considerazione quanto segue:

  • Potresti aver implementato questi processi nell'ambiente di origine e intendi progettare e implementare processi simili in Google Cloud. Ad esempio, puoi eseguire il refactoring di questi processi per utilizzare Cloud Build, Cloud Deploy e Infrastructure Manager.
  • Potresti aver implementato questi processi in un altro ambiente di terze parti al di fuori dell'ambiente di origine. In questo caso, devi eseguire il refactoring di questi processi per scegliere come target l'ambiente Google Cloud anziché l'ambiente di origine.
  • Una combinazione degli approcci precedenti.

Il refactoring dei processi di deployment e operativi può essere complesso e richiedere uno sforzo significativo. Se provi a eseguire queste attività nell'ambito della migrazione del workload, quest'ultima può diventare più complessa ed esporti a rischi. Dopo aver valutato i processi di deployment e operativi, probabilmente hai una comprensione della loro progettazione e complessità. Se stimi che sia necessario un impegno notevole per eseguire il refactoring dei processi di deployment e operativi, ti consigliamo di prendere in considerazione il refactoring di questi processi nell'ambito di un progetto separato e dedicato.

Per saperne di più su come progettare e implementare le procedure di deployment su Google Cloud, consulta:

Questo documento si concentra sui processi di deployment che producono gli artefatti da eseguire il deployment e li esegue nell'ambiente di runtime di destinazione. La strategia di refactoring dipende molto dalla complessità di questi processi. Il seguente elenco descrive una possibile strategia di refactoring generale:

  1. Esegui il provisioning dei repository di artefatti su Google Cloud. Ad esempio, puoi utilizzare Artifact Registry per archiviare gli artefatti e creare dipendenze.
  2. Esegui il refactoring dei processi di build per archiviare gli artefatti sia nell'ambiente di origine sia in Artifact Registry.
  3. Esegui il refactoring dei processi di deployment per eseguire il deployment dei carichi di lavoro nell'ambiente di destinazione.Google Cloud Ad esempio, puoi iniziare eseguendo il deployment di un piccolo sottoinsieme dei tuoi carichi di lavoro in Google Cloud, utilizzando gli artefatti archiviati in Artifact Registry. Poi, aumenti gradualmente il numero di carichi di lavoro di cui è stato eseguito il deployment in Google Cloud, finché tutti i carichi di lavoro da migrare non vengono eseguiti su Google Cloud.
  4. Esegui il refactoring dei processi di build per archiviare gli artefatti solo in Artifact Registry.
  5. Se necessario, esegui la migrazione delle versioni precedenti degli artefatti da distribuire dai repository nell'ambiente di origine ad Artifact Registry. Ad esempio, puoi copiare le immagini container in Artifact Registry.
  6. Ritira i repository nell'ambiente di origine quando non ti servono più.

Per facilitare i rollback dovuti a problemi imprevisti durante la migrazione, puoi archiviare le immagini container sia nei repository di artefatti attuali in Google Cloud mentre la migrazione a Google Cloud è in corso. Infine, nell'ambito del ritiro dell'ambiente di origine, puoi eseguire il refactoring dei processi di creazione delle immagini container per archiviare gli artefatti solo in Google Cloud .

Sebbene non sia fondamentale per il successo di una migrazione, potresti dover eseguire la migrazione delle versioni precedenti degli artefatti dall'ambiente di origine ai repository di artefatti su Google Cloud. Ad esempio, per supportare il rollback dei workload a punti temporali arbitrari, potrebbe essere necessario migrare le versioni precedenti degli artefatti in Artifact Registry. Per maggiori informazioni, vedi Eseguire la migrazione delle immagini da un registro di terze parti.

Se utilizzi Artifact Registry per archiviare gli artefatti, ti consigliamo di configurare i controlli per proteggere i repository di artefatti, come icontrollo dell'accessolo dell'accesso, la prevenzione dell&#3esfiltrazione di datiti,analisi delle vulnerabilitàtà e l'autorizzazione binaria. Per saperne di più, consulta Controllare l'accesso e proteggere gli artefatti.

Migrazione dei dati

GKE supporta diversi servizi di archiviazione dati, come l'archiviazione a blocchi, l'archiviazione a blocchi non elaborati, l'archiviazione di file e l'archiviazione di oggetti. Per maggiori informazioni, consulta Panoramica dell'archiviazione per i cluster GKE.

Per eseguire la migrazione dei dati al tuo ambiente GKE:

  1. Esegui il provisioning e configura tutta l'infrastruttura di archiviazione necessaria.
  2. Configura i provisioner StorageClass nei tuoi cluster GKE. Non tutti i provisioner StorageClass sono compatibili con tutti gli ambienti. Prima di eseguire il deployment di un provisioner StorageClass, ti consigliamo di valutarne la compatibilità con GKE e le relative dipendenze.
  3. Configura StorageClasses.
  4. Configura PersistentVolume e PersistentVolumeClaim per archiviare i dati da migrare.
  5. Esegui la migrazione dei dati dal tuo ambiente di origine a questi PersistentVolume. I dettagli di questa migrazione dei dati dipendono dalle caratteristiche dell'ambiente di origine.

Per eseguire la migrazione dei dati dall'ambiente di origine all'ambiente Google Cloud, ti consigliamo di progettare un piano di migrazione dei dati seguendo le indicazioni riportate in Eseguire la migrazione a Google Cloud: trasferire set di dati di grandi dimensioni.

Eseguire la migrazione dei dati da EKS a GKE

AWS offre diverse opzioni di archiviazione dati per Amazon EKS. Questo documento si concentra sui seguenti scenari di migrazione dei dati:

  • Esegui la migrazione dei dati dai volumi Amazon EBS alle risorse GKE PersistentVolume.
  • Copia i dati dai volumi Amazon EBS ad Amazon S3 o a Cloud Storage, quindi esegui la migrazione dei dati alle risorse GKE PersistentVolume.
Migrazione dei dati dai volumi Amazon EBS ai PersistentVolumes di GKE

Puoi eseguire la migrazione dei dati dai volumi Amazon EBS alle risorse GKE PersistentVolume utilizzando uno dei seguenti approcci:

  • Copia direttamente i dati dai volumi Amazon EBS ai dischi permanenti di Compute Engine:
    1. Esegui il provisioning delle istanze Amazon EC2 e collega i volumi Amazon EBS che contengono i dati da migrare.
    2. Esegui il provisioning delle istanze di Compute Engine con dischi permanenti vuoti con capacità sufficiente per archiviare i dati da migrare.
    3. Esegui uno strumento di sincronizzazione dei dati, ad esempio rsync, per copiare i dati dai volumi Amazon EBS ai dischi permanenti di Compute Engine.
    4. Scollega i dischi permanenti dalle istanze Compute Engine.
    5. Ritira le istanze Compute Engine.
    6. Configura i dischi permanenti come risorse PersistentVolume GKE.
  • Esegui la migrazione delle istanze Amazon EC2 e dei volumi Amazon EBS a Compute Engine:
    1. Esegui il provisioning delle istanze Amazon EC2 e collega i volumi Amazon EBS che contengono i dati da migrare.
    2. Esegui la migrazione delle istanze Amazon EC2 e dei volumi Amazon EBS a Compute Engine con Migrate for Virtual Machines.
    3. Scollega i dischi permanenti dalle istanze Compute Engine.
    4. Ritira le istanze Compute Engine.
    5. Configura i dischi permanenti come risorse PersistentVolume GKE.

Per ulteriori informazioni sulla migrazione delle istanze Amazon EC2 a Compute Engine, consulta Migrazione da AWS a Google Cloud: esegui la migrazione da Amazon EC2 a Compute Engine.

Per ulteriori informazioni sull'utilizzo dei dischi permanenti di Compute Engine come risorse PersistentVolume di GKE, consulta Utilizzo di dischi permanenti preesistenti come PersistentVolume.

Copia i dati dai volumi Amazon EBS su un supporto intermedio e migra a PersistentVolumes di GKE

Anziché eseguire la migrazione dai volumi Amazon EBS alle risorse GKE PersistentVolume direttamente, puoi utilizzare un supporto intermedio come un archivio oggetti:

  1. Carica i dati dai volumi Amazon EBS su un supporto intermedio, ad esempio un bucket Amazon S3 o un bucket Cloud Storage.
  2. Scarica i dati dal supporto intermedio nelle tue risorse GKE PersistentVolume.

In alcuni scenari, l'utilizzo di più supporti può semplificare il trasferimento dei dati in base alle configurazioni di rete e di sicurezza. Ad esempio, puoi caricare inizialmente i dati in un bucket S3, quindi copiarli dal bucket S3 a un bucket Cloud Storage e infine scaricarli nei volumi permanenti. Indipendentemente dall'approccio che scegli, per garantire una transizione senza problemi e tenendo conto di considerazioni importanti, ti consigliamo di consultare Migrazione da AWS a Google Cloud: migrazione da Amazon S3 a Cloud Storage.

Scegliere un'opzione di migrazione

L'opzione di migrazione migliore per te dipende dalle tue esigenze e dai tuoi requisiti specifici, ad esempio:

  • La quantità di dati che devi migrare.
    • Se devi eseguire la migrazione di una piccola quantità di dati, ad esempio alcuni file di dati, valuta la possibilità di utilizzare strumenti come rsync per copiare i dati direttamente sui dischi permanenti di Compute Engine. Questa opzione è relativamente veloce, ma potrebbe non essere adatta a grandi quantità di dati.
    • Se devi eseguire la migrazione di una grande quantità di dati, valuta la possibilità di utilizzare Migrate to Virtual Machines per eseguire la migrazione dei dati a Compute Engine. Questa opzione è più complessa della copia diretta dei dati, ma è più affidabile e scalabile.
  • Il tipo di dati di cui devi eseguire la migrazione.
  • La connettività di rete tra gli ambienti di origine e di destinazione.
    • Se non riesci a stabilire una connettività di rete diretta tra le istanze AWS EC2 e Compute Engine, ti consigliamo di utilizzare Amazon S3 o Cloud Storage per archiviare temporaneamente i dati durante la migrazione a Compute Engine. Questa opzione potrebbe essere meno costosa perché non dovrai mantenere in esecuzione contemporaneamente le istanze EC2 e Compute Engine.
  • La cronologia della migrazione.
    • Se hai una larghezza di banda di rete limitata o una grande quantità di dati e la tua tempistica non è rigida, puoi anche prendere in considerazione l'utilizzo di Transfer Appliance per spostare i dati da AWS a Google Cloud.

Indipendentemente dall'opzione scelta, è importante testare la migrazione prima di renderla effettiva. I test ti aiuteranno a identificare eventuali problemi potenziali e a garantire la riuscita della migrazione.

Esegui il deployment dei carichi di lavoro

Quando i processi di deployment sono pronti, esegui il deployment dei carichi di lavoro su GKE. Per saperne di più, vedi Panoramica del deployment dei carichi di lavoro.

Per preparare i workload al deployment per GKE, ti consigliamo di analizzare i descrittori Kubernetes perché alcune risorse che GKE esegue automaticamente il provisioning per te sono configurabili utilizzando le etichette e le annotazioni di Kubernetes, anziché dover eseguire manualmente il provisioning di queste risorse. Google Cloud Ad esempio, puoi eseguire il provisioning di un bilanciatore del carico interno anziché di uno esterno aggiungendo un'annotazione a un servizio LoadBalancer.

Convalida i tuoi workload

Dopo aver eseguito il deployment dei carichi di lavoro nell'ambiente GKE, ma prima di esporli agli utenti, ti consigliamo di eseguire test e convalide approfonditi. Questi test possono aiutarti a verificare che i tuoi carichi di lavoro si comportino come previsto. Ad esempio, potresti:

  • Esegui test di integrazione, test di carico, test di conformità, test di affidabilità e altre procedure di verifica che ti aiutano a garantire che i tuoi carichi di lavoro operino entro i parametri previsti e in base alle loro specifiche.
  • Esamina log, metriche e report sugli errori in Google Cloud Observability per identificare eventuali problemi e individuare tendenze per anticipare i problemi prima che si verifichino.

Per maggiori informazioni sulla convalida del workload, consulta Test per l'affidabilità.

Esporre i carichi di lavoro

Una volta completati i test di convalida dei carichi di lavoro in esecuzione nel tuo ambiente GKE, esponi i carichi di lavoro per renderli raggiungibili.

Per esporre i carichi di lavoro in esecuzione nel tuo ambiente GKE, puoi utilizzare i servizi Kubernetes e unmesh di servizih.

Per ulteriori informazioni sull'esposizione dei workload in esecuzione in GKE, consulta:

Shift il traffico nel tuo Google Cloud ambiente

Dopo aver verificato che i carichi di lavoro vengono eseguiti nel tuo ambiente GKE e dopo averli esposti ai client, sposta il traffico dall'ambiente di origine all'ambiente GKE. Per aiutarti a evitare migrazioni su larga scala e tutti i rischi correlati, ti consigliamo di spostare gradualmente il traffico dall'ambiente di origine a GKE.

A seconda di come hai progettato l'ambiente GKE, hai diverse opzioni per implementare un meccanismo di bilanciamento del carico che sposta gradualmente il traffico dall'ambiente di origine a quello di destinazione. Ad esempio, puoi implementare una policy di risoluzione DNS che risolve i record DNS in base a una determinata policy per risolvere una certa percentuale di richieste agli indirizzi IP appartenenti al tuo ambiente GKE. In alternativa, puoi implementare un meccanismo di bilanciamento del carico utilizzando indirizzi IP virtuali e bilanciatori del carico di rete.

Dopo aver iniziato a spostare gradualmente il traffico nell'ambiente GKE, ti consigliamo di monitorare il comportamento dei carichi di lavoro man mano che aumentano.

Infine, esegui un cutover, ovvero il trasferimento di tutto il traffico dall'ambiente di origine all'ambiente GKE.

Per saperne di più sul bilanciamento del carico, consulta Bilanciamento del carico nel frontend.

Ritirare l'ambiente di origine

Dopo che i workload nell'ambiente GKE gestiscono correttamente le richieste, ritiri l'ambiente di origine.

Prima di iniziare il ritiro delle risorse nell'ambiente di origine, ti consigliamo di procedere nel seguente modo:

  • Esegui il backup di tutti i dati per ripristinare le risorse nell'ambiente di origine.
  • Informa gli utenti prima di ritirare l'ambiente.

Per ritirare l'ambiente di origine:

  1. Ritira i carichi di lavoro in esecuzione nei cluster nell'ambiente di origine.
  2. Elimina i cluster nell'ambiente di origine.
  3. Elimina le risorse associate a questi cluster, come gruppi di sicurezza, bilanciatori del carico e reti virtuali.

Per evitare di lasciare risorse orfane, è importante l'ordine in cui ritiri le risorse nell'ambiente di origine. Ad esempio, alcuni provider richiedono di ritirare i servizi Kubernetes che portano alla creazione di bilanciatori del carico prima di poter ritirare le reti virtuali che contengono questi bilanciatori del carico.

Ottimizzare l' Google Cloud ambiente

L'ottimizzazione è l'ultima fase della migrazione. In questa fase, esegui l'iterazione delle attività di ottimizzazione finché l'ambiente di destinazione non soddisfa i requisiti di ottimizzazione. I passaggi di ogni iterazione sono i seguenti:

  1. Valuta l'ambiente, i team e il ciclo di ottimizzazione attuali.
  2. Stabilisci i requisiti e gli obiettivi di ottimizzazione.
  3. Ottimizza il tuo ambiente e i tuoi team.
  4. Ottimizza il ciclo di ottimizzazione.

Ripeti questa sequenza finché non hai raggiunto gli obiettivi di ottimizzazione.

Per ulteriori informazioni sull'ottimizzazione dell'ambiente Google Cloud , vedi Migrazione a Google Cloud: ottimizza il tuo ambiente e Google Cloud Well-Architected Framework: ottimizzazione delle prestazioni.

Le sezioni seguenti integrano le considerazioni in Eseguire la migrazione a Google Cloud: ottimizzare l'ambiente.

Stabilire i requisiti di ottimizzazione

I requisiti di ottimizzazione ti aiutano a restringere l'ambito dell'iterazione di ottimizzazione attuale. Per ulteriori informazioni sui requisiti e sugli obiettivi di ottimizzazione, consulta Stabilire i requisiti e gli obiettivi di ottimizzazione.

Per stabilire i requisiti di ottimizzazione per l'ambiente GKE, inizia a considerare i seguenti aspetti:

  • Sicurezza, privacy e conformità: ti aiutano a migliorare la security posture del tuo ambiente GKE.
  • Affidabilità: ti aiuta a migliorare la disponibilità, la scalabilità e la resilienza del tuo ambiente GKE.
  • Ottimizzazione dei costi: ti aiuta a ottimizzare il consumo di risorse e le relative spese del tuo ambiente GKE.
  • Efficienza operativa: ti aiuta a gestire e utilizzare il tuo ambiente GKE in modo efficiente.
  • Ottimizzazione delle prestazioni: ti aiuta a ottimizzare le prestazioni dei carichi di lavoro di cui è stato eseguito il deployment nel tuo ambiente GKE.

Sicurezza, privacy e conformità

  • Monitora la postura di sicurezza dei tuoi cluster GKE. Puoi utilizzare la dashboard sulla postura di sicurezza per ricevere suggerimenti attendibili e strategici che ti aiutino a migliorare la postura di sicurezza del tuo ambiente GKE.
  • Proteggi l'ambiente GKE. Comprendi il modello di sicurezza di GKE e come proteggere i tuoi cluster GKE.
  • Proteggi la catena di fornitura del software. Per i carichi di lavoro critici per la sicurezza, Google Cloud fornisce un insieme modulare di prodotti che implementano le best practice per la sicurezza della catena di fornitura del software durante il ciclo di vita del software.

Affidabilità

  • Migliora l'affidabilità dei cluster. Per aiutarti a progettare un cluster GKE più resiliente a interruzioni di zona improbabili, preferisci i cluster regionali rispetto a quelli zonali o multizona.

  • Backup e ripristino dei carichi di lavoro. Configura un flusso di lavoro di backup e ripristino dei carichi di lavoro con Backup per GKE.

Ottimizzazione dei costi

Per ulteriori informazioni sull'ottimizzazione dei costi dell'ambiente GKE, consulta:

Efficienza operativa

Per aiutarti a evitare problemi che interessano l'ambiente di produzione, ti consigliamo di:

  • Progetta i tuoi cluster GKE in modo che siano fungibili. Se consideri i tuoi cluster fungibili e ne automatizzi il provisioning e la configurazione, puoi semplificare e generalizzare i processi operativi per mantenerli e semplificare anche le migrazioni future e gli upgrade dei cluster GKE. Ad esempio, se devi eseguire l'upgrade di un cluster GKE fungibile a una nuova versione di GKE, puoi eseguire automaticamente il provisioning e la configurazione di un nuovo cluster di cui è stato eseguito l'upgrade, eseguire automaticamente il deployment dei carichi di lavoro nel nuovo cluster e ritirare il vecchio cluster GKE obsoleto.
  • Monitora le metriche di interesse. Assicurati che tutte le metriche di interesse relative ai tuoi workload e cluster vengano raccolte correttamente. Inoltre, verifica che tutti gli avvisi pertinenti che utilizzano queste metriche come input siano attivi e funzionanti.

Per maggiori informazioni sulla configurazione del monitoraggio, del logging e della profilazione nel tuo ambiente GKE, consulta:

Ottimizzazione delle prestazioni

Per maggiori informazioni, consulta Informazioni sulla scalabilità di GKE.

Passaggi successivi

Collaboratori

Autori: