Eseguire la migrazione da AWS a Google Cloud: migrare da Amazon EKS a GKE

Last reviewed 2024-08-02 UTC

Google Cloud fornisce strumenti, prodotti, indicazioni e servizi professionali per eseguire 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 inoltre indicazioni se stai valutando la possibilità di eseguire la migrazione e vuoi esplorare come potrebbe essere. Oltre a essere eseguito su Amazon Elastic Compute Cloud (Amazon EC2), Amazon EKS offre alcune altre opzioni di deployment, come Amazon EKS su output AWS e Amazon EKS ovunque. Questo documento è incentrato 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. Inoltre, fornisce funzionalità che ti aiutano a gestire il tuo 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 ulteriori informazioni, consulta Versioni di GKE.
  • Due modalità di funzionamento: Standard e Autopilot. Con la modalità Standard, gestisci l'infrastruttura di base 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, sicurezza di base e configurazione di rete. Per ulteriori informazioni sulle modalità di funzionamento di GKE, consulta Scegliere una modalità di funzionamento GKE.
  • Accordo sul livello del servizio per i pod unico nel settore 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 altamente disponibili per i tuoi carichi di lavoro.

Per saperne di più su GKE, consulta Panoramica di GKE.

Per questa migrazione a Google Cloud, ti consigliamo di seguire il framework di migrazione descritto in Eseguire la migrazione a Google Cloud: inizia.

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

Percorso di migrazione con quattro fasi.

Potresti eseguire la migrazione dal tuo ambiente di origine a Google Cloud in una serie di iterazioni, ad esempio potresti eseguire la migrazione di alcuni carichi di lavoro prima e di altri più tardi. Per ogni iterazione di migrazione distinta, segui le fasi del framework di migrazione generale:

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

Per saperne di più sulle fasi di questo framework, consulta Eseguire la migrazione a Google Cloud: inizia.

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 aiutarti a convalidare il piano di migrazione, consulta Eseguire la migrazione a Google Cloud: best practice per convalidare un piano di migrazione.

Valutare l'ambiente di origine

Nella fase di valutazione, devi determinare i requisiti e le dipendenze per eseguire la migrazione dell'ambiente di origine a Google Cloud.

La fase di valutazione è fondamentale per la buona riuscita della migrazione. Devi acquisire conoscenze approfondite sui carichi di lavoro di cui vuoi eseguire la migrazione, sui relativi requisiti, sulle dipendenze e sul tuo ambiente attuale. Per pianificare ed eseguire correttamente una migrazione a Google Cloud, devi conoscere il punto di partenza.

La fase di valutazione è composta dalle seguenti attività:

  1. Crea un inventario completo dei tuoi workload.
  2. Cataloga 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 e le tempistiche della migrazione.
  9. Convalida il piano di migrazione.

Per ulteriori informazioni sulla fase di valutazione e su queste attività, consulta Eseguire la migrazione a Google Cloud: valutare e rilevare i carichi di lavoro. Le sezioni seguenti si basano sulle informazioni contenute in questo documento.

Creare gli inventari

Per definire l'ambito della migrazione, crei 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 le procedure di deployment e operative 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, prendi in considerazione quanto segue per ogni cluster:

  • Numero e tipo di nodi. Quando conosci il numero di nodi e le caratteristiche di ciascun nodo nel tuo ambiente attuale, puoi determinare le dimensioni dei cluster quando passi a GKE. I nodi nel nuovo ambiente potrebbero essere eseguiti su un'architettura hardware o su una generazione diversa da quelle utilizzate nel tuo ambiente. Il funzionamento di ogni architettura e generazione è diverso, pertanto il numero di nodi di cui hai bisogno nel nuovo ambiente potrebbe essere diverso da quello dell'ambiente attuale. Valuta qualsiasi tipo di hardware in uso nei tuoi nodi, ad esempio dispositivi di archiviazione ad alte prestazioni, GPU e TPU. Valuta quale immagine del sistema operativo stai utilizzando sui tuoi nodi.
  • Cluster interno o esterno. Valuta a quali agenti, 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 cluster.
  • Multi-tenancy. Se gestisci cluster multi-tenant nel tuo ambiente, valuta se funzionano nel nuovo ambiente Google Cloud. Ora è un buon momento per valutare come migliorare i tuoi cluster multi-tenant, perché la tua strategia di multitenancy influisce sul modo in cui crei la tua base su Google Cloud.
  • Versione di Kubernetes. Raccogli informazioni sulla versione Kubernetes dei tuoi cluster per valutare se esiste una mancata corrispondenza tra queste versioni e quelle disponibili in GKE. Se utilizzi una versione precedente di Kubernetes o una 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, scopri come gestisci gli upgrade di Kubernetes e come 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 in che modo questi raggruppamenti corrispondono al concetto di pool di nodi in GKE, in quanto i tuoi criteri di raggruppamento potrebbero non essere adatti a GKE.
  • Inizializza il nodo. Valuta come viene inizializzato 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, la loro allocazione degli indirizzi IP, la modalità di configurazione dei plug-in di rete, la modalità di configurazione dei server DNS e dei fornitori di servizi DNS, se hai configurato qualsiasi forma di NAT o SNAT per questi cluster e se fanno parte di un ambiente multi-cluster.
  • Conformità: valuta eventuali requisiti di conformità e normativi che i tuoi cluster devono soddisfare e se li stai soddisfacendo.
  • Quote e limiti. Valuta in che modo hai configurato 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 gli eventuali metadati applicati 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 su 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 perché hai creato questa separazione. Ad esempio, potresti utilizzare gli spazi dei nomi come parte della tua strategia di multitenancy. Potresti avere carichi di lavoro di cui è stato eseguito il deployment in spazi dei nomi riservati per i componenti di sistema 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 ClusterRoleBindings che hai configurato nei tuoi cluster.
  • Norme della 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.
  • Account di servizio. Se un processo nel cluster interagisce con il server API Kubernetes, acquisisci informazioni sugli account di servizio in uso.

Quando crei l'inventario dei tuoi cluster Kubernetes, potresti scoprire che alcuni devono essere dismessi nell'ambito della migrazione. Assicurati che il 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 aver valutato la sicurezza del tuo ambiente, crea l'inventario dei workload 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 determinare le dimensioni dei cluster nel nuovo ambiente, valuta quante istanze di ciascun carico di lavoro hai disegnato 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 utilizzi?
  • Job e CronJobs. I tuoi cluster e carichi di lavoro potrebbero dover eseguire job o CronJob nell'ambito delle procedure di inizializzazione o di funzionamento. Valuta quante istanze di job e CronJob hai disegnato, nonché le responsabilità e i criteri di completamento per ogni istanza.
  • Autoscaler di Kubernetes. Per eseguire la migrazione dei criteri 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 con stato salvano i dati per un utilizzo successivo. 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 del cluster, puoi sapere quale versione di Kubernetes viene eseguita su ciascun cluster. Esamina le note di rilascio di ogni versione di Kubernetes per sapere quali funzionalità sono incluse e quali sono ritirate. Poi valuta i tuoi carichi di lavoro in base alle funzionalità di Kubernetes di cui hai bisogno. Lo scopo di questa attività è sapere se stai utilizzando funzionalità deprecate o non ancora disponibili in GKE. Se trovi funzionalità non disponibili, esegui la migrazione dalle funzionalità ritirate e adotta le nuove quando sono disponibili in GKE.
  • Spazio di 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 ai PersistentVolume. Per tenere conto della crescita futura, valuta se devi estendere qualsiasi PersistenceVolumeClaim.
  • Configurazione e inserimento di secret. Per evitare di ricostruire gli artefatti di cui è possibile eseguire il deployment ogni volta che si verifica una modifica nella 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. I tuoi carichi di lavoro probabilmente non funzionano in isolamento. Potrebbero avere dipendenze interne al cluster o da sistemi esterni. Per ogni carico di lavoro, acquisisci le dipendenze e verifica se i carichi di lavoro hanno una tolleranza per i casi in cui le dipendenze non sono disponibili. Ad esempio, le dipendenze comuni includono file system distribuiti, database, piattaforme di distribuzione di secret, sistemi di gestione dell'identità e dell'accesso, meccanismi di Service Discovery e qualsiasi altro sistema esterno.
  • Servizi Kubernetes. Per esporre i tuoi carichi di lavoro ai client interni ed esterni, utilizza Servizi. Per ogni servizio, devi conoscere il relativo tipo. Per i servizi esposti all'esterno, valuta come 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 di ingressi hai disegnato nei tuoi cluster?
  • Mesh di servizi. Se utilizzi un'infrastruttura mesh di servizi nel tuo ambiente, valutane la configurazione. Devi anche sapere quanti cluster coprono, 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 tuoi cluster Kubernetes. Queste proprietà possono anche fornirti informazioni su possibili configurazioni non omogenee di nodi o pod e possono indicare che i pod, i nodi o entrambi devono essere valutati con particolare attenzione. Ad esempio, se hai configurato un determinato insieme di pod per essere pianificato solo su determinati nodi del tuo cluster Kubernetes, potrebbe significare che i pod richiedono risorse specializzate disponibili solo su quei nodi.
  • Autenticazione: valuta in che modo i tuoi carichi di lavoro si autenticano rispetto alle risorse nel cluster e alle risorse esterne.

Valutare 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 della tua infrastruttura, ad esempio:

  • StorageClasses e PersistentVolumes. Valuta in che modo la tua infrastruttura supporta i PersistentVolumeClaim elencando StorageClasses per il provisioning dinamico e i volumi permanenti con provisioning statico.PersistentVolumes Per ogni PersistentVolume, prendi in considerazione quanto segue: capacità, modalità del volume, modalità di accesso, classe, criterio di recupero, opzioni di montaggio e affinità dei nodi.
  • VolumeSnapshots e VolumeSnapshotContents. Per ogni PersistentVolume, valuta se hai configurato un VolumeSnapshot e se devi eseguire la migrazione di eventuali VolumeSnapshotContents esistenti.
  • Driver Container Storage Interface (CSI). Se sono implementati nei tuoi cluster, valuta se questi driver sono compatibili con GKE e se è necessario adattare la configurazione dei volumi in modo che funzionino con driver CSI compatibili con GKE.
  • Spazio di archiviazione dei dati. Se hai bisogno di sistemi esterni per eseguire il provisioning di PersistentVolumes, fornisci ai carichi di lavoro nel tuo ambiente GKE un modo per utilizzare questi sistemi. La localizzazione dei dati influisce sul rendimento dei carichi di lavoro con stato, perché la latenza tra i sistemi esterni e l'ambiente GKE è proporzionale alla distanza tra loro. Per ogni sistema di archiviazione dei dati esterni, valutane il tipo, ad esempio volumi a blocchi, archiviazione di file o archiviazione di oggetti, nonché eventuali requisiti di prestazioni e disponibilità che deve soddisfare.
  • Risorse personalizzate e componenti aggiuntivi Kubernetes. Raccogli informazioni su eventuali risorse Kubernetes personalizzate e su eventuali componenti aggiuntivi Kubernetes che potresti aver disegnato 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 come esegui il backup della configurazione dei tuoi cluster e dei dati dei carichi di lavoro con stato nell'ambiente di origine.

Valuta le procedure di deployment e operative

È importante avere una comprensione chiara del funzionamento delle procedure di deployment e operative. Queste procedure sono una parte fondamentale delle pratiche che preparano e gestiscono l'ambiente di produzione e i relativi carichi di lavoro.

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

Oltre al tipo di elemento, valuta come completare le seguenti attività:

  • Sviluppa i tuoi carichi di lavoro. Valuta le procedure messe in atto dai team di sviluppo per creare i carichi di lavoro. Ad esempio, in che modo i tuoi team di sviluppo progettano, codificano e testano i carichi di lavoro?
  • Genera gli elementi da eseguire nel tuo 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 personalizzare artefatti esistenti, come immagini del sistema operativo di terze parti, installando e configurando il software. Raccogliere informazioni su come generi questi elementi ti aiuta a verificare che siano adatti per il deployment in Google Cloud.

  • Archivia gli elementi. Se produci artefatti che memorizzi in un registro di artefatti nel tuo ambiente di origine, devi renderli disponibili nel tuo ambiente Google Cloud. Puoi farlo adottando strategie come le seguenti:

    • Stabilisci un canale di comunicazione tra gli ambienti: rendi accessibili gli elementi dell'ambiente di origine dall'ambiente Google Cloud di destinazione.
    • Esegui il refactoring del processo di compilazione degli elementi: completa un refactoring minore dell'ambiente di origine in modo da poter archiviare gli elementi sia nell'ambiente di origine sia nell'ambiente di destinazione. Questo approccio supporta la migrazione creando un'infrastruttura come un repository di elementi prima di dover implementare le procedure di compilazione degli elementi nell'ambiente Google Cloud di destinazione. Puoi implementare questo approccio direttamente o puoi basarti sull'approccio precedente di stabilire prima un canale di comunicazione.

    Avere gli elementi disponibili sia nell'ambiente di origine sia in quello di destinazione ti consente di concentrarti sulla migrazione senza dover implementare le procedure di compilazione degli elementi nell'ambiente Google Cloud di destinazione nell'ambito della migrazione.

  • Scansiona e firma il codice. Nell'ambito delle procedure di compilazione degli elementi, potresti utilizzare la scansione del codice per proteggerti da vulnerabilità comuni e dall'esposizione involontaria alla rete, nonché la firma del codice per assicurarti che nei tuoi ambienti venga eseguito solo codice attendibile.

  • Esegui il deployment degli elementi nell'ambiente di origine. Dopo aver generato gli elementi di deployment, potresti eseguirne il deployment nell'ambiente di origine. Ti consigliamo di valutare ogni processo di implementazione. La valutazione consente di verificare che i processi di implementazione siano compatibili con Google Cloud. Inoltre, ti aiuta a capire lo sforzo necessario per eseguire il refactoring delle procedure. Ad esempio, se le tue procedure di implementazione lavorano solo con l'ambiente di origine, potresti doverle rifare in modo che abbiano come target il tuo ambiente Google Cloud.

  • Esegui l'iniezione della configurazione di runtime. Potresti iniettare la configurazione di runtime per cluster, ambienti di runtime o deployment dei carichi di lavoro specifici. La configurazione potrebbe inizializzare le variabili di ambiente e altri valori di configurazione come secret, credenziali e chiavi. Per contribuire a garantire che le procedure di inserimento della configurazione di runtime funzionino su Google Cloud, ti consigliamo di valutare la modalità di configurazione dei carichi di lavoro eseguiti nel tuo ambiente di origine.

  • Logging, monitoraggio e profilazione. Valuta le procedure di registrazione, monitoraggio e profiling che hai implementato per monitorare lo stato di integrità del tuo ambiente di origine, le metriche di interesse e il modo in cui utilizzi i dati forniti da queste procedure.

  • Autenticazione. Valuta la modalità di autenticazione rispetto all'ambiente di origine.

  • Esegui il provisioning e configura le risorse. Per preparare l'ambiente di origine, potresti aver progettato e implementato procedure di provisioning e configurazione delle risorse. Ad esempio, potresti utilizzare Terraform insieme a strumenti di gestione della configurazione per eseguire il provisioning e configurare le risorse nel tuo ambiente di origine.

Strumenti per creare l'inventario del tuo ambiente di origine

Per creare l'inventario dei tuoi cluster Amazon EKS, ti consigliamo di utilizzare Migration Center, la piattaforma unificata di Google Cloud che ti consente di accelerare il tuo percorso verso il cloud end-to-end dall'ambiente attuale a Google Cloud. Migration Center ti consente di importare i 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 e che si basano su API AWS, strumenti per sviluppatori AWS e sull'interfaccia a riga di comando AWS.

Oltre ai dati che ottieni da Migration Center, tieni conto dei 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:
    • 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 Amazon personalizzate in EKS
    • Utilizzo di Amazon EKS Fargate
    • Utilizzo di Prometheus gestito da Amazon EKS
    • Configurazione dell'autenticazione OpenID Connect
  • Valuta come esegui l'autenticazione nei tuoi cluster Amazon EKS e come hai configurato AWS Identity and Access Management (IAM) per Amazon EKS.
  • Valuta la configurazione di rete dei tuoi cluster Amazon EKS.

Pianifica e crea le basi

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

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

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

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

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

Le seguenti sezioni integrano le considerazioni riportate in Eseguire la migrazione a Google Cloud: pianificare e creare le basi.

Pianifica il multitenancy

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

  • Creare un progetto Google Cloud 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 esigenze di isolamento, complessità e scalabilità. Ad esempio, avere un progetto per tenant li isola 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 piano di controllo 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 progetto Google Cloud e dei relativi cluster utilizzando il RBAC. Per ulteriori informazioni, consulta 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 un cluster, ti consigliamo di valutare il modello di rete GKE, le best practice per il networking di 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 trovare aree di miglioramento. GKE offre integrazioni profonde con l'osservabilità di Google Cloud, pertanto puoi ottenere informazioni su logging, monitoraggio e profilazione dei tuoi cluster e workload GKE all'interno di questi cluster.

Esegui la migrazione dei dati e il deployment dei carichi di lavoro

Nella fase di deployment, svolgi le seguenti operazioni:

  1. Esegui il provisioning e la configurazione dell'ambiente GKE.
  2. Configura i tuoi cluster GKE.
  3. Esegui il refactoring dei carichi di lavoro.
  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 nel tuo ambiente GKE.
  7. Convalida i carichi di lavoro e l'ambiente GKE.
  8. Esponi i workload in esecuzione su GKE.
  9. Shift il traffico dall'ambiente di origine all'ambiente GKE.
  10. Esegui il ritiro dell'ambiente di origine.

Esegui il provisioning e configura l'ambiente Google Cloud

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à nei cluster esistenti, ma alcune potrebbero essere abilitabili solo al momento della creazione del cluster. Per aiutarti a 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, potrebbe essere necessario eliminare e ricreare i cluster nel caso in cui le funzionalità di 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:

  • Il numero di cluster, il numero di nodi per cluster, i tipi di cluster, la configurazione di ciascun cluster e di ciascun nodo e i piani di scalabilità di ciascun cluster.
  • La modalità di funzionamento di ciascun cluster. GKE offre due modalità di funzionamento per i cluster: GKE Autopilot e GKE Standard.
  • Il numero di cluster privati.
  • La scelta tra networking VPC nativo o basato su router.
  • Le versioni e i canali di rilascio di Kubernetes di cui hai bisogno nei tuoi cluster GKE.
  • I pool di nodi per raggruppare logicamente i nodi nei cluster GKE e se devi creare automaticamente i pool di nodi con il provisioning automatico dei nodi.
  • Le procedure di inizializzazione che puoi trasferire dal tuo ambiente all'ambiente GKE e le nuove procedure che puoi implementare. Ad esempio, puoi avviare automaticamente i nodi GKE implementando una o più procedure di inizializzazione, eventualmente privilegiate, per ogni nodo o pool di nodi nei tuoi cluster.
  • I piani di scalabilità per ogni cluster.
  • Le funzionalità GKE aggiuntive di cui hai bisogno, ad esempio Cloud Service Mesh, e i componenti aggiuntivi GKE, ad esempio Backup for GKE.

Per ulteriori informazioni sul provisioning dei cluster GKE, consulta:

Gestione del parco risorse

Quando esegui il provisioning dei cluster GKE, potresti scoprire di ne avere bisogno di un gran numero 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 i servizi tra team o aree geografiche. Per ulteriori informazioni, consulta i casi d'uso multi-cluster.

Con l'aumento del numero di cluster, l'ambiente GKE potrebbe diventare più difficile da gestire perché la gestione di un numero elevato di cluster comporta notevoli sfide di scalabilità e operatività. GKE fornisce strumenti e funzionalità per aiutarti a gestire i parchi risorse, un raggruppamento logico di cluster Kubernetes. Per saperne di più, consulta Gestione del parco risorse.

Networking multi-cluster

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

Per saperne di più sulla migrazione da un ambiente GKE a un cluster singolo a un ambiente GKE multi-cluster, consulta 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 workload o di eseguire la migrazione dei dati, devi configurare gli spazi dei nomi, il RBAC, i criteri di rete, gli account di servizio 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 ai cluster nell'ambiente di origine e 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. Ristruttura qualsiasi oggetto incompatibile per renderlo compatibile con GKE o ritiralo.
  4. Crea questi oggetti nei tuoi cluster GKE.
  5. Configura eventuali oggetti aggiuntivi di cui hai bisogno nei tuoi 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 si espande, 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 ulteriori informazioni, consulta la Architettura di Config Sync.

Policy Controller

Policy Controller ti aiuta ad applicare e fare rispettare i criteri programmabili per contribuire a garantire l'esecuzione sicura e conforme dei tuoi cluster e carichi di lavoro GKE. Man mano che l'ambiente GKE si espande, puoi utilizzare Policy Controller per applicare automaticamente criteri, bundle di criteri e limitazioni a tutti i tuoi cluster GKE. Ad esempio, puoi limitare i repository da cui è possibile estrarre le immagini container o richiedere che ogni spazio dei nomi abbia almeno un'etichetta per assicurarti un monitoraggio accurato del consumo delle risorse.

Per ulteriori informazioni, consulta Controller dei criteri.

Esegui il refactoring dei carichi di lavoro

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

Sebbene tu possa eseguire la migrazione della maggior parte dei carichi di lavoro così come sono su GKE, potresti dover fare un ulteriore sforzo per eseguire il refactoring dei carichi di lavoro che dipendono da funzionalità specifiche dell'ambiente, al fine di ridurre al minimo queste dipendenze, passando eventualmente ad alternative disponibili su GKE.

Per eseguire il refactoring dei carichi di lavoro prima di eseguirne la migrazione a GKE, svolgi quanto segue:

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

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 soluzioni GKE alternative idonee.
  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 la possibilità di ritirare una di queste funzionalità specifiche dell'ambiente di origine.
  • Valuta quanto sia fondamentale una funzionalità specifica dell'ambiente di origine per il buon esito della migrazione.

Adotta soluzioni GKE alternative idonee

Dopo aver esaminato le funzionalità specifiche dell'ambiente di origine e averle mappate a soluzioni alternative GKE adatte, adotta 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 intendi ritirare.
  • Concentrati sull'adozione di soluzioni GKE alternative per le funzionalità specifiche dell'ambiente di origine più critiche e pianifica progetti di migrazione dedicati per il resto.

Esegui il refactoring dei carichi di lavoro

Sebbene la maggior parte dei carichi di lavoro possa funzionare così com'è in GKE, potresti dover 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 delle immagini container, come Dockerfile e Containerfile.
  • Codice sorgente dei carichi di lavoro.

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

Ristrutturare i processi di deployment e operativi

Dopo aver sottoposto a refactoring i carichi di lavoro, esegui il refactoring delle procedure di deployment e operative per:

  • Esegui il provisioning e la configurazione delle risorse nel tuo ambiente Google Cloud instead of provisioning resources in your source environment.
  • Crea e configura i carichi di lavoro ed esegui il loro deployment in Google Cloud instead of in the source environment.

Hai raccolto informazioni su queste procedure durante la fase di valutazione in precedenza in questa procedura.

Il tipo di refactoring da prendere in considerazione per queste procedure dipende da come le hai progettate e implementate. Il refactoring dipende anche da quale stato finale vuoi per ogni processo. Ad esempio, prendi in considerazione quanto indicato di seguito:

  • Potresti aver implementato queste procedure nel tuo ambiente di origine e intendi progettare e implementare procedure simili in Google Cloud. Ad esempio, puoi eseguire il refactoring di queste procedure per utilizzare Cloud Build, Cloud Deploy e Infrastructure Manager.
  • Potresti aver implementato queste procedure in un altro ambiente di terze parti al di fuori dell'ambiente di origine. In questo caso, devi eseguire il refactoring di queste procedure in modo che abbiano 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 un impegno significativo. Se provi a eseguire queste attività nell'ambito della migrazione del workload, la migrazione del workload può diventare più complessa e può esporre a rischi. Dopo aver valutato i processi di implementazione e operativi, probabilmente hai compreso il loro design e la loro complessità. Se ritieni di dover impiegare molto impegno per eseguire il refactoring delle procedure di implementazione e operative, ti consigliamo di valutare la possibilità di eseguire il refactoring di queste procedure nell'ambito di un progetto dedicato e separato.

Per ulteriori informazioni su come progettare e implementare i processi di deployment su Google Cloud, consulta:

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

  1. Esegui il provisioning dei repository di elementi su Google Cloud. Ad esempio, puoi utilizzare Artifact Registry per archiviare gli artefatti e creare dipendenze.
  2. Esegui il refactoring delle procedure di compilazione per archiviare gli artefatti sia nell'ambiente di origine sia in Artifact Registry.
  3. Esegui il refactoring delle procedure di deployment per distribuire i carichi di lavoro nell'ambiente Google Cloud di destinazione. Ad esempio, puoi iniziare a eseguire il deployment di un piccolo sottoinsieme dei tuoi workload in Google Cloud utilizzando gli elementi archiviati in Artifact Registry. Poi, aumenta gradualmente il numero di workload di cui viene eseguito il deployment in Google Cloud, fino a quando tutti i workload di cui vuoi eseguire la migrazione non vengono eseguiti su Google Cloud.
  4. Esegui il refactoring delle procedure di compilazione per archiviare gli artefatti solo in Artifact Registry.
  5. Se necessario, esegui la migrazione delle versioni precedenti degli elementi da eseguire il deployment dai repository nell'ambiente di origine ad Artifact Registry. Ad esempio, puoi copiare le immagini container in Artifact Registry.
  6. Esegui la disattivazione dei repository nell'ambiente di origine quando non li necessiti più.

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

Sebbene potrebbe non essere fondamentale per la riuscita di una migrazione, potresti dover eseguire la migrazione delle versioni precedenti degli elementi dall'ambiente di origine ai repository di elementi su Google Cloud. Ad esempio, per supportare il rollback dei workload a punti in tempo arbitrari, potresti dover eseguire la migrazione delle versioni precedenti degli elementi in Artifact Registry. Per ulteriori informazioni, consulta Eseguire la migrazione delle immagini da un registry di terze parti.

Se utilizzi Artifact Registry per archiviare gli elementi, ti consigliamo di configurare i controlli per proteggere i repository degli elementi, ad esempio il controllo dell'accesso dell'accesso, la prevenzione dell'esfiltrazione di dati, analisi delle vulnerabilità e l'Autorizzazione binaria. Per ulteriori informazioni, consulta Controllare l'accesso e proteggere gli elementi.

Migrazione dei dati

GKE supporta diversi servizi di archiviazione dati, come archiviazione a blocchi, archiviazione a blocchi non elaborati, archiviazione di file e archiviazione degli oggetti. Per ulteriori informazioni, consulta la panoramica dell'archiviazione per i cluster GKE.

Per eseguire la migrazione dei dati nel tuo ambiente GKE:

  1. Esegui il provisioning e configura tutta l'infrastruttura di archiviazione necessaria.
  2. Configura StorageClass provisioner, nei tuoi cluster GKE. Non tutti i provisioning di StorageClass sono compatibili con tutti gli ambienti. Prima di eseguire il deployment di un provisioning StorageClass, ti consigliamo di valutarne la compatibilità con GKE e le relative dipendenze.
  3. Configura le classi di archiviazione.
  4. Configura i volumi permanenti e le richieste di volumi permanenti per archiviare i dati da migrare.
  5. Esegui la migrazione dei dati dal tuo ambiente di origine a questi PersistentVolume. Le specifiche 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 Migrazione a Google Cloud: trasferimento di set di dati di grandi dimensioni.

Eseguire la migrazione dei dati da EKS a GKE

AWS offre diverse opzioni di archiviazione dei 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 GKEPersistentVolume.
  • Copia i dati dai volumi Amazon EBS in Amazon S3 o in Cloud Storage, quindi esegui la migrazione dei dati alle risorse GKEPersistentVolume.
Esegui la migrazione dei dati dai volumi Amazon EBS ai volumi permanenti GKE

Puoi eseguire la migrazione dei dati dai volumi Amazon EBS alle risorse GKEPersistentVolume 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 Compute Engine con dischi permanenti vuoti con capacità sufficiente per archiviare i dati di cui eseguire la migrazione.
    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. Esegui la dismissione delle istanze Compute Engine.
    6. Configura i dischi permanenti come risorse GKEPersistentVolume.
  • 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 su Compute Engine con Migrate for Virtual Machines.
    3. Scollega i dischi permanenti dalle istanze Compute Engine.
    4. Esegui la dismissione delle istanze Compute Engine.
    5. Configura i dischi permanenti come risorse GKEPersistentVolume.

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

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

Copia i dati dai volumi Amazon EBS su un supporto intermedio e esegui la migrazione a PersistentVolume di GKE

Anziché eseguire la migrazione dai volumi Amazon EBS alle risorse GKEPersistentVolume direttamente, puoi utilizzare un mezzo intermedio come un PersistentVolumearchivio 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 dai media intermedi 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 sicurezza. Ad esempio, puoi caricare inizialmente i dati in un bucket S3, quindi copiarli dal bucket S3 in un bucket Cloud Storage e infine scaricarli nei volumi permanenti. Indipendentemente dall'approccio scelto, per garantire una transizione senza problemi e tenere conto di considerazioni importanti, ti consigliamo di esaminare la pagina Eseguire la migrazione da AWS a Google Cloud: migrare 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 le seguenti considerazioni:

  • La quantità di dati di cui devi eseguire la migrazione.
    • 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 rapida, ma potrebbe non essere adatta per una grande quantità di dati.
    • Se hai una grande quantità di dati da migrare, valuta la possibilità di utilizzare Esegui la migrazione a macchine virtuali per eseguire la migrazione dei dati a Compute Engine. Questa opzione è più complessa rispetto alla 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 tue 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 i tempi non sono stretti, puoi anche valutare la possibilità di utilizzare un Transfer Appliance per spostare i dati da AWS a Google Cloud.

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

Esegui il deployment dei carichi di lavoro

Quando le procedure di deployment sono pronte, esegui il deployment dei carichi di lavoro su GKE. Per ulteriori informazioni, consulta Panoramica del deployment dei carichi di lavoro.

Per preparare i carichi di lavoro da eseguire per GKE, ti consigliamo di analizzare i descrittori Kubernetes perché alcune risorse Google Cloud che GKE esegue automaticamente sono configurabili utilizzando i tag e le annotations Kubernetes, anziché dover eseguire il provisioning manuale di queste risorse. Ad esempio, puoi eseguire il provisioning di un bilanciatore del carico interno invece di uno esterno aggiungendo un'annotazione a un servizio LoadBalancer.

Convalida i carichi di lavoro

Dopo aver eseguito il deployment dei carichi di lavoro nel tuo ambiente GKE, ma prima di esporli agli utenti, ti consigliamo di eseguire verifiche e test approfonditi. Questi test possono aiutarti a verificare che i 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 ad assicurarti che i carichi di lavoro funzionino entro i parametri previsti e in base alle specifiche.
  • Esamina i log, le metriche e i report sugli errori in Google Cloud Observability per identificare eventuali potenziali problemi e individuare le tendenze per anticipare i problemi prima che si verifichino.

Per ulteriori informazioni sulla convalida dei carichi di lavoro, consulta Test di affidabilità.

Esporre i carichi di lavoro

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

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

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

Shift il traffico nell'ambiente Google Cloud

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

A seconda di come hai progettato il tuo ambiente GKE, hai diverse opzioni per implementare un meccanismo di bilanciamento del carico che trasferisca gradualmente il traffico dall'ambiente di origine a quello di destinazione. Ad esempio, puoi implementare un criterio di risoluzione DNS che risolva i record DNS in base a un criterio per risolvere una determinata 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 taglio, ovvero sposti tutto il traffico dall'ambiente di origine all'ambiente GKE.

Per ulteriori informazioni sul bilanciamento del carico, consulta Bilanciamento del carico nella parte anteriore.

Eseguire il ritiro dell'ambiente di origine

Dopo che i carichi di lavoro nel tuo ambiente GKE hanno iniziato a gestire correttamente le richieste, puoi ritirare l'ambiente di origine.

Prima di iniziare a dismettere le risorse nell'ambiente di origine, ti consigliamo di procedere nel seguente modo:

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

Per eseguire il ritiro dell'ambiente di origine:

  1. Esegui la disattivazione dei carichi di lavoro in esecuzione nei cluster del tuo ambiente di origine.
  2. Elimina i cluster nell'ambiente di origine.
  3. Elimina le risorse associate a questi cluster, ad esempio gruppi di sicurezza, bilanciatori del carico e reti virtuali.

Per evitare di lasciare risorse orfane, è importante l'ordine in cui esegui il ritiro delle risorse nell'ambiente di origine. Ad esempio, alcuni fornitori richiedono di ritirare i servizi Kubernetes che generano la creazione di bilanciatori del carico prima di poter ritirare le reti virtuali contenenti questi bilanciatori.

Ottimizza il tuo ambiente Google Cloud

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 il tuo ambiente, i tuoi team e il tuo ciclo di ottimizzazione attuale.
  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 raggiungi i tuoi obiettivi di ottimizzazione.

Per ulteriori informazioni sull'ottimizzazione dell'ambiente Google Cloud, consulta Esegui la migrazione a Google Cloud: ottimizza l'ambiente e Procedura di ottimizzazione delle prestazioni.

Le sezioni seguenti integrano le considerazioni riportate in Esegui la migrazione a Google Cloud: ottimizza l'ambiente.

Stabilisci i requisiti di ottimizzazione

I requisiti di ottimizzazione ti consentono di restringere l'ambito dell'attuale iterazione di ottimizzazione. Per saperne di più sui requisiti e sugli obiettivi di ottimizzazione, consulta Definire i requisiti e gli obiettivi di ottimizzazione.

Per stabilire i requisiti di ottimizzazione per il tuo ambiente GKE, inizia tenendo conto dei 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 delle risorse e la spesa risultante 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à

Affidabilità

  • Migliora l'affidabilità dei tuoi cluster. Per aiutarti a progettare un GKE più resiliente a interruzioni zonali improbabili, preferisci i cluster a livello di regione rispetto a quelli a livello di zona o multizonali.
  • 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 del costo dell'ambiente GKE, consulta:

Efficienza operativa

Per aiutarti a evitare problemi che interessano il tuo ambiente di produzione, ti consigliamo di:

  • Progetta i tuoi cluster GKE in modo che siano fungibili. Se consideri i tuoi cluster come fungibili e ne automatizzi il provisioning e la configurazione, puoi semplificare e generalizzare i processi operativi per gestirli 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 il provisioning e la configurazione automatici di un nuovo cluster di cui è stato eseguito l'upgrade, eseguire automaticamente il deployment dei workload nel nuovo cluster e ritirare il vecchio cluster GKE obsoleto.
  • Monitora le metriche che ti interessano. Assicurati che tutte le metriche di interesse relative ai tuoi carichi di lavoro e cluster vengano raccolte correttamente. Inoltre, verifica che tutti gli avvisi pertinenti che utilizzano queste metriche come input siano impostati e funzionino.

Per ulteriori informazioni sulla configurazione di monitoraggio, logging e profilazione nel tuo ambiente GKE, consulta:

Ottimizzazione delle prestazioni

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

Passaggi successivi

Collaboratori

Autori: