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

Last reviewed 2023-09-30 UTC

Google Cloud offre strumenti, prodotti, indicazioni e servizi di servizi 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 di migrazione da Amazon EKS a GKE. Il presente documento fornisce inoltre se stai valutando l'opportunità di eseguire la migrazione e vuoi esplorare come potrebbe essere una migrazione. 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 eseguire il deployment e gestire applicazioni containerizzate su larga scala dell'infrastruttura e offre funzionalità utili per la gestione ad esempio:

  • Due versioni: GKE Standard e GKE Enterprise. Con GKE Standard, hai accesso a un livello Standard di core le funzionalità di machine learning. Con GKE Enterprise, hai accesso a tutte le le funzionalità di GKE. Per ulteriori informazioni, vedi Versioni di GKE.
  • Due modalità operative: standard e Autopilot. Con Standard, è l'utente a gestire l'infrastruttura sottostante configurazione di ogni nodo nel tuo cluster GKE. Con Autopilot, GKE gestisce all'infrastruttura sottostante, come configurazione dei nodi, aggiornamenti automatici, sicurezza di base e configurazione di rete. Per ulteriori informazioni informazioni sulle modalità operative di GKE, vedi Scegli una modalità operativa di GKE.
  • Accordo sul livello del servizio specifico di settore per i pod quando si usa Autopilot in più zone.
  • Creazione ed eliminazione automatizzati di pool di nodi con il provisioning automatico dei nodi.
  • Networking multi-cluster gestito da Google per aiutarti a progettare e implementare architetture distribuite ad alta disponibilità per i tuoi carichi di lavoro.

Per ulteriori informazioni su GKE, consulta Panoramica di GKE.

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

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

Percorso di migrazione con quattro fasi.

Puoi eseguire la migrazione da Kubernetes a GKE in una serie Ad esempio, potresti eseguire la migrazione di alcuni carichi di lavoro prima e di altri in un secondo momento. Per ogni singola iterazione della migrazione, segui le fasi del framework per la migrazione:

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

Per ulteriori informazioni 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 assicurarti di avere una strategia di rollback. Per aiutarti a convalidare di migrazione, consulta 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, stabilisci i requisiti e le dipendenze di eseguire la migrazione dell'ambiente di origine in Google Cloud.

La fase di valutazione è fondamentale per il successo della migrazione. Devi conoscere a fondo i carichi di lavoro di cui vuoi eseguire la migrazione, i loro requisiti dalle loro dipendenze e dal tuo ambiente attuale. Devi comprendere il tuo punto di partenza per pianificare ed eseguire con successo un progetto Google Cloud migrazione.

La fase di valutazione è composta dalle seguenti attività:

  1. Crea un inventario completo dei tuoi carichi di lavoro.
  2. Cataloga i carichi di lavoro in base alle loro proprietà e dipendenze.
  3. Addestra e forma 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 per primi i carichi di lavoro di cui vuoi eseguire la migrazione.

Per ulteriori informazioni sulla fase di valutazione e su queste attività, consulta: Esegui la migrazione a Google Cloud: valuta e individua i tuoi carichi di lavoro. Le sezioni seguenti si basano sulle informazioni contenute nel documento.

Creare gli inventari

Per definire l'ambito della migrazione, puoi creare due inventari:

  1. L'inventario dei tuoi cluster.
  2. L'inventario dei carichi di lavoro di cui viene eseguito il deployment nei cluster.

Dopo aver creato questi inventari:

  1. Valuta i processi operativi e di deployment per la tua origine completamente gestito di Google Cloud.
  2. Valuta i servizi di supporto e le dipendenze esterne.

Crea l'inventario dei tuoi cluster

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

  • Numero e tipo di nodi. Quando sai quanti nodi e caratteristiche di ciascun nodo nel tuo ambiente attuale, per dimensionare i cluster quando passi a GKE. I nodi nel nuovo ambiente potrebbero essere eseguiti su un'architettura hardware diversa o una generazione di testi rispetto a quelle che usi nel tuo ambiente. La le prestazioni di ogni architettura e generazione sono diverse, quindi il numero di nodi nel nuovo ambiente potrebbero essere diversi completamente gestito di Google Cloud. 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 quali attori, interno al tuo ambiente o esterno, a cui è esposto ciascun cluster. Per supportare i tuoi casi d'uso, questa valutazione include i carichi di lavoro in esecuzione nel cluster interfacce che interagiscono con i tuoi cluster.
  • Multitenancy. Se gestisci cluster multi-tenant in dell'ambiente, valuta se funziona nel tuo nuovo Google Cloud completamente gestito di Google Cloud. È un buon momento per valutare come migliorare multi-tenant perché la tua strategia multi-tenancy influenza il modo in cui per creare le tue basi su Google Cloud.
  • Versione Kubernetes. Raccogliere informazioni su Kubernetes dei cluster per valutare se c'è una mancata corrispondenza queste versioni quelle disponibili in GKE. Se esegui una versione di Kubernetes precedente o rilasciata di recente, potrebbero utilizzare funzionalità non disponibili in GKE. La potrebbero essere deprecate oppure la versione di Kubernetes che le fornisce non ancora disponibile in GKE.
  • Ciclo di upgrade di Kubernetes. Per mantenere un ambiente affidabile, a capire come gestisci gli upgrade di Kubernetes e come il ciclo di upgrade riguarda Upgrade di GKE.
  • Pool di nodi. Se utilizzi una qualsiasi forma di raggruppamento dei nodi, potrebbe essere utile considerare come questi raggruppamenti siano mappati al concetto di pool di nodi in GKE perché i criteri di raggruppamento potrebbero non essere adatti con GKE.
  • Inizializzazione dei nodi. Valuta come inizializzare ciascun nodo prima contrassegnandolo come disponibile per l'esecuzione dei tuoi carichi di lavoro, così potrai portarli di inizializzazione delle procedure su GKE.
  • Configurazione di rete. Valuta la configurazione di rete del tuo cluster, l'allocazione degli indirizzi IP, come hai configurato plug-in di rete, configurazione dei server DNS e del servizio DNS di rete, se per questi cluster hai configurato una qualsiasi forma di NAT o SNAT, e se fanno parte di un ambiente multi-cluster.
  • Conformità: valuta gli eventuali requisiti normativi e di conformità che il tuo cluster sono tenuti a soddisfare e se li soddisfi i tuoi requisiti.
  • Quote e limiti. Valuta come hai configurato quote e limiti per cluster. Ad esempio, quanti pod può eseguire ogni nodo? Quanti nodi può di un cluster Kubernetes?
  • Etichette e tag. Valuta tutti i metadati che hai applicato ai cluster, pool e nodi e come li utilizzi. Ad esempio, potresti generando report con un'attribuzione dei costi dettagliata basata sulle etichette.

I seguenti elementi valutati nel tuo inventario sono incentrati sulla sicurezza della tua infrastruttura e dei cluster Kubernetes:

  • Spazi dei nomi. Se usi Kubernetes Spazi dei nomi nei tuoi cluster per separare logicamente le risorse, si trovano in ogni spazio dei nomi e capirai perché l'hai creato la separazione degli utenti. Ad esempio, potresti utilizzare gli spazi dei nomi come parte una strategia multi-tenancy. Il deployment dei carichi di lavoro negli spazi dei nomi potrebbe essere per i componenti di sistema Kubernetes e potresti non avere in GKE.
  • Controllo controllo dell'accesso basato sui ruoli (RBAC) Se utilizzi Autorizzazione RBAC nei tuoi cluster, elenca una descrizione di tutti i ClusterRoles ClusterRoleBinding che hai configurato nei tuoi cluster.
  • Criteri di rete. Elenca tutti norme della rete configurato nei tuoi cluster e comprendere come funzionano i criteri di rete in GKE.
  • Contesto di sicurezza dei pod. Acquisisci informazioni su il Contesto di sicurezza dei pod configurato nei tuoi cluster scopri come funzionano in GKE.
  • Account di servizio. Se un processo nel cluster interagisce con il server API di Kubernetes, acquisire informazioni account di servizio che stanno usando.

Quando crei l'inventario dei tuoi cluster Kubernetes, potresti scoprire che alcuni cluster devono essere dismessi durante la migrazione. Marca che il piano di migrazione includa il ritiro di queste risorse.

Creare l'inventario dei carichi di lavoro Kubernetes

Dopo aver completato l'inventario dei cluster Kubernetes e valutato la sicurezza il tuo ambiente, crea l'inventario dei carichi di lavoro di cui è stato eseguito il deployment cluster. Durante la valutazione dei carichi di lavoro, raccogli informazioni su quanto segue: aspetti:

  • Pod e controller. Per dimensionare i cluster nel nuovo ambiente, valuta quante di ogni carico di lavoro di cui hai eseguito il deployment e se utilizzi Quote delle risorse e limiti di consumo delle risorse di calcolo. Raccogli informazioni sui carichi di lavoro in esecuzione sul piano di controllo i nodi di ciascun cluster e i controller utilizzati da ciascun carico di lavoro. Per ad esempio, quanti Deployment stai usando? Quanti DaemonSets stai usando?
  • Job e CronJobs. I cluster e i carichi di lavoro potrebbero dover eseguire job o CronJob nelle procedure operative o di inizializzazione. Valuta il numero di istanze di job e CronJob di cui hai eseguito il deployment e responsabilità e criteri di completamento per ogni istanza.
  • Gestori della scalabilità automatica di Kubernetes. Per eseguire la migrazione dei criteri di scalabilità automatica nel nuovo ambiente, scopri come l'Horizontal Pod Autoscaler e Vertical Pod Autoscaler, per lavorare su GKE.
  • Carichi di lavoro stateless e stateful. I carichi di lavoro stateless non archiviano dati o lo stato nel cluster o nell'archiviazione permanente. stateful le applicazioni salvano dati per utilizzarli in un secondo momento. Per ogni carico di lavoro, valuta che sono stateless e che sono stateful, poiché la migrazione carichi di lavoro stateful in genere è più difficile della migrazione di quelle stateless.
  • Funzionalità di Kubernetes. Dall'inventario del cluster, sai quale Versione di Kubernetes eseguita da ciascun cluster. Esamina il note di rilascio di ogni versione di Kubernetes per sapere quali funzionalità vengono distribuite le funzionalità che ritira. Quindi valuta i carichi di lavoro rispetto le funzionalità di Kubernetes di cui hai bisogno. L'obiettivo di questa attività è conoscere se stai utilizzando funzionalità deprecate o non ancora disponibili in GKE. Se noti delle funzioni non disponibili, abbandona le funzionalità deprecate e adotta quelle nuove quando vengono disponibile in GKE.
  • Spazio di archiviazione. Per i carichi di lavoro stateful, valuta se utilizzano PersistenceVolumeClaims. Elencare i requisiti di archiviazione, come dimensioni e modalità di accesso, e come queste richieste di volumi PersistenceVolumeClaim vengono mappate a PersistenceVolumes. Per tenere conto della crescita futura, valuta se devi espandi qualsiasi PersistenceVolumeClaim.
  • Configurazione e inserimento di secret. Per evitare di ricreare di cui è possibile eseguire il deployment ogni volta che viene apportata una modifica alla configurazione il tuo ambiente, inserisci configurazione e secret nei pod utilizzando ConfigMaps e Secret. Per ogni carico di lavoro, valuta a quali oggetti ConfigMap e Secret corrisponde e come vengono compilati.
  • Dipendenze. È probabile che i carichi di lavoro non funzionino in modo isolato. Loro potrebbero avere dipendenze interne al cluster o dall'esterno sistemi diversi. Per ogni carico di lavoro, acquisisci le dipendenze e, dei carichi di lavoro tollerano quando le dipendenze non sono disponibili. Per Ad esempio, le dipendenze comuni includono file system distribuiti, database piattaforme di distribuzione dei segreti, sistemi di gestione di identità e accessi meccanismi di Service Discovery e qualsiasi altro sistema esterno.
  • Servizi Kubernetes. Per esporre i carichi di lavoro a risorse per i client esterni, utilizza Servizi. Devi conoscere il tipo di ogni servizio. Per esposizione esterna e servizi, valuta in che modo quel servizio interagisce con il resto dei tuoi servizi dell'infrastruttura. Ad esempio, in che modo la tua infrastruttura supporta Servizi LoadBalancer, Oggetti gateway, e Oggetti in entrata? Quale Controller Ingress hai eseguito il deployment nei tuoi cluster?
  • Mesh di servizi: Se nel tuo ambiente utilizzi un mesh di servizi, e valutarne la configurazione. Devi anche sapere quanti cluster intervalli, quali servizi fanno parte della mesh e come modifichi la topologia del mesh.
  • Incompatibilità e tolleranze e affinità e anti-affinità. Per ogni pod e nodo, valuta se hai configurato delle incompatibilità dei nodi, tolleranze o affinità per personalizzare la pianificazione dei pod cluster Kubernetes. Queste strutture potrebbero anche fornirti informazioni su possibili configurazioni non omogenee di nodi o pod e potrebbe significare che i pod, i nodi o entrambi devono essere valutati attenzione e cura. Ad esempio, se hai configurato un particolare insieme di pod essere pianificati solo su determinati nodi del tuo cluster Kubernetes, potrebbe significare che i pod necessitano di risorse specializzate disponibili solo nodi.
  • Autenticazione: valuta le modalità di autenticazione dei carichi di lavoro rispetto alle risorse nel cluster e rispetto a 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 aspetti e servizi di supporto all'interno della tua infrastruttura, ad esempio:

  • StorageClass e PersistentVolume. Valuta il modo in cui dell'infrastruttura supporta gli oggetti PersistentVolumeClaim StorageClasses della il provisioning dinamico, e provisioning statico PersistentVolumes. Per ogni PersistentVolume, considera quanto segue: capacità, modalità volume modalità di accesso, classe, criterio di recupero, opzioni di montaggio e affinità nodo.
  • VolumeSnapshots e VolumeSnapshotContents. Per ogni PersistentVolume, valuta se hai configurato VolumeSnapshot se devi eseguire la migrazione di VolumeSnapshotContents esistente.
  • Driver di Container Storage Interface (CSI). Se il deployment è stato eseguito nei tuoi cluster, valutare se questi driver sono compatibili con GKE devi adattare la configurazione dei volumi per lavorare Driver CSI compatibili con GKE.
  • Archiviazione dei dati. Se ti basi su sistemi esterni per eseguire il provisioning gli oggetti PersistentVolume, forniscono un modo per i carichi di lavoro dell'ambiente GKE per utilizzare questi sistemi. La località di dati ha un impatto sulle prestazioni dei carichi di lavoro stateful, poiché la latenza tra i sistemi esterni e l'ambiente GKE è proporzionale alla loro distanza. Per ogni unità di archiviazione dati esterna di sistema, considera il tipo, ad esempio volumi a blocchi, archiviazione di file o spazio di archiviazione ed eventuali requisiti di prestazioni e disponibilità soddisfare.
  • Risorse personalizzate e componenti aggiuntivi Kubernetes. Raccogli informazioni su qualsiasi risorse Kubernetes personalizzate ed eventuali componenti aggiuntivi di Kubernetes di cui potresti aver eseguito il deployment nei cluster, perché potrebbero non funzionare in GKE o potresti doverli modificare. Ad esempio, se un una risorsa personalizzata interagisce con un sistema esterno, tu valuti se si tratta applicabile al tuo ambiente Google Cloud.
  • Backup. Valuta il modo in cui esegui il backup della configurazione cluster e dati dei carichi di lavoro stateful nell'ambiente di origine.

Valuta il deployment e i processi operativi

È importante avere una chiara comprensione di come l'implementazione dei processi operativi. Questi processi sono una parte fondamentale che preparano e gestiscono l'ambiente di produzione e per i carichi di lavoro che vengono eseguiti lì.

I processi operativi e di deployment potrebbero creare gli artefatti per il corretto funzionamento dei carichi di lavoro. Pertanto, dovresti raccogliere informazioni su ogni tipo di artefatto. Ad esempio, un artefatto può essere un pacchetto del sistema operativo, un pacchetto di deployment delle applicazioni, un'immagine del sistema operativo, un'immagine container altro.

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

  • Sviluppa i tuoi carichi di lavoro. Valutare i processi seguiti dai team di sviluppo dei carichi di lavoro. Ad esempio, in che modo i team di sviluppo progettando, programmando e testando i carichi di lavoro?
  • Genera gli artefatti di cui esegui il deployment nel tuo ambiente di origine. A dei carichi di lavoro nell'ambiente di origine, potresti generare artefatti di cui è possibile eseguire il deployment, come immagini container o immagini del sistema operativo potresti personalizzare elementi esistenti, come la gestione le immagini di sistema installando e configurando il software. La raccolta di informazioni su come stai generando questi artefatti ti aiuta a per assicurarti che gli artefatti generati siano adatti al deployment in Google Cloud.

  • Archivia gli artefatti. Se produci artefatti che archivi in un Artifact Registry nel tuo ambiente di origine, devi rendere gli artefatti disponibili nel tuo ambiente Google Cloud. Puoi farlo utilizzando strategie come le seguenti:

    • Stabilisci un canale di comunicazione tra gli ambienti. Rendi il artefatti nel tuo ambiente di origine raggiungibili dalla destinazione nell'ambiente Google Cloud.
    • Esegui il refactoring del processo di creazione degli artefatti: completa un piccolo refactoring del tuo in modo da poter archiviare gli artefatti sia nell'ambiente di origine e l'ambiente di destinazione. Questo approccio supporta della migrazione creando un'infrastruttura come un repository di artefatti prima di implementare i processi di creazione degli artefatti nel Google Cloud completamente gestito di Google Cloud. Puoi implementare questo approccio direttamente o basarti su l'approccio precedente, che prevede per prima cosa un canale di comunicazione.

    La disponibilità degli artefatti sia nell'ambiente di origine che in quello di destinazione ti consente per concentrarsi sulla migrazione senza dover implementare i processi di creazione degli artefatti nell'ambiente Google Cloud di destinazione nell'ambito della migrazione.

  • Scansiona e firma il codice. Nell'ambito dei processi di build degli artefatti, potresti utilizzando la scansione del codice per proteggerti dalle vulnerabilità comuni per evitare un'esposizione accidentale della rete e la firma del codice per garantire che il codice attendibile viene eseguito nei tuoi ambienti.

  • Esegui il deployment degli artefatti nell'ambiente di origine. Dopo la generazione artefatti di cui è possibile eseguire il deployment, potresti eseguirne il deployment nel tuo ambiente di origine. Ti consigliamo di valutare ogni processo di deployment. La valutazione aiuta garantire che i processi di deployment siano compatibili con Google Cloud. Inoltre, ti aiuta a comprendere l'impegno necessario per e infine il refactoring dei processi. Ad esempio, se i tuoi processi di deployment funzionino solo con il tuo ambiente di origine, potresti dover eseguire il refactoring definire come target il tuo ambiente Google Cloud.

  • Inserisci la configurazione di runtime. È possibile che tu abbia inserito la configurazione di runtime per cluster, ambienti di runtime o deployment di carichi di lavoro specifici. La potrebbe inizializzare le variabili di ambiente e altre configurazioni come secret, credenziali e chiavi. Per garantire che i tuoi i processi di iniezione della configurazione runtime funzionano su Google Cloud, ti consigliamo di valutare le modalità di configurazione dei carichi di lavoro in esecuzione dell'ambiente di origine.

  • Logging, monitoraggio e profilazione. Valutare le attività di logging, monitoraggio i processi di profilazione in atto per monitorare l'integrità dei tuoi dell'ambiente di origine, le metriche di interesse e il modo in cui utilizzi i dati forniti da questi processi.

  • Autenticazione del cluster. Valuta la tua modalità di autenticazione rispetto al tuo nell'ambiente di origine.

  • Esegui il provisioning e la configurazione delle risorse AWS. Per preparare la fonte: di progettazione e implementazione di processi che e configurare le risorse. Ad esempio, potresti utilizzare Terraform oltre a strumenti di gestione della configurazione per il provisioning e la configurazione delle risorse nel tuo ambiente di origine.

Strumenti per creare l'inventario dell'ambiente di origine

Per creare l'inventario dei tuoi cluster Amazon EKS, ti consigliamo di utilizzare Centro di migrazione, La piattaforma unificata di Google Cloud che ti aiuta ad accelerare il processo end-to-end il percorso del cloud dal tuo ambiente attuale a Google Cloud. Il Centro di migrazione consente di importare dati da Amazon EKS e altre risorse AWS. Migration Center consiglia quindi Google Cloud pertinente da cui eseguire la migrazione.

Perfeziona l'inventario dei tuoi cluster e carichi di lavoro Amazon EKS

I dati forniti dal Centro di migrazione potrebbero non acquisire completamente le dimensioni che ti interessano. In questo caso, puoi integrare con i risultati di altri meccanismi di raccolta dati creati dall'utente si basano sulle API AWS, sugli strumenti per sviluppatori AWS e sull'interfaccia a riga di comando AWS.

Oltre ai dati ottenuti dal Centro di migrazione, considera i seguenti punti dati per ogni cluster Amazon EKS che vuoi migrare:

  • Valutare gli aspetti e le funzionalità specifici di Amazon EKS per ogni 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 personalizzate Amazon in EKS
    • Utilizzo di Amazon EKS Fargate
    • Utilizzo di Amazon EKS Managed Prometheus
    • Configurazione dell'autenticazione OpenID Connect
  • Valuta le tue modalità di autenticazione nei cluster Amazon EKS e hai configurato AWS Identity and Access Management (IAM) per Amazon EKS.
  • Valuta la configurazione di rete dei tuoi cluster Amazon EKS.

Pianifica e costruisci le tue basi

Nella fase di pianificazione e creazione, esegui il provisioning e la configurazione dell'infrastruttura procedi nel seguente modo:

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

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

  1. Creare 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 tua sicurezza.
  6. Configura il logging, il monitoraggio e gli avvisi.

Per ulteriori informazioni su ciascuna di queste attività, consulta Esegui la migrazione a Google Cloud: pianifica e costruisci le tue basi.

Le seguenti sezioni integrano le considerazioni in Migrate to Google Cloud: pianifica e crea le tue basi.

Pianifica la multitenancy

Per progettare una gerarchia di risorse efficiente, considera il modo in cui la tua azienda e le strutture organizzative sono mappate a Google Cloud. Ad esempio, se un ambiente multi-tenant su GKE, puoi scegliere tra le seguenti opzioni:

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

La scelta dipende dalle esigenze di isolamento, complessità e scalabilità. Per 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 molto e l'isolamento dei dati. Ad esempio, il piano di controllo potrebbe essere condiviso tra i tenant. Per ulteriori informazioni, vedi Multitenancy dei cluster.

Configura la gestione di identità e accessi

GKE supporta diverse opzioni per la gestione dell'accesso alle risorse all'interno del progetto Google Cloud e dei relativi cluster utilizzando RBAC. Per ulteriori informazioni, vedi Controllo dell'accesso.

Configura il networking GKE

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

Configura monitoraggio e avvisi

Avere un quadro chiaro delle prestazioni dell'infrastruttura e dei carichi di lavoro. è fondamentale per individuare le aree da migliorare. GKE ha profonde integrazioni con Google Cloud Observability, per ottenere informazioni sul logging, sul monitoraggio e sulla profilazione dei tuoi e i carichi di lavoro GKE all'interno di questi cluster.

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

Nella fase di deployment, devi:

  1. Esegui il provisioning e configura il tuo ambiente GKE.
  2. Configura i tuoi cluster GKE.
  3. Esegui il refactoring dei carichi di lavoro.
  4. Esegui il refactoring del deployment e dei processi operativi.
  5. Eseguire 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 carichi di lavoro in esecuzione su GKE.
  9. Shift il traffico dall'ambiente di origine all'ambiente GKE.
  10. Dismissione 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, il provisioning dei cluster GKE.

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

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

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

Per ulteriori informazioni sul provisioning dei cluster GKE, consulta:

Gestione del parco risorse

Quando esegui il provisioning dei tuoi cluster GKE, potresti renderti conto che ne servono una grande quantità per supportare tutti i casi d'uso del tuo ambiente. Ad esempio, potresti dover separare la produzione ambienti non di produzione o servizi separati 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 diventano più difficili da gestire perché la gestione di un gran numero di cluster grandi difficoltà operative e di scalabilità. GKE fornisce strumenti e funzionalità per aiutarti a gestire i parchi risorse, un raggruppamento logico di cluster. Per ulteriori informazioni, vedi Gestione della flotta.

Networking multi-cluster

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

  • Service Discovery multi-cluster, un meccanismo di rilevamento e chiamata di servizi tra cluster. I servizi sono rilevabili e accessibili in tutti i cluster GKE. Per ulteriori informazioni, vedi Scoperta dei servizi multi-cluster.
  • Gateway multi-cluster, un bilanciamento del carico del traffico in entrata tra cluster meccanismo di attenzione. Per ulteriori informazioni, vedi Deployment di gateway multi-cluster.
  • Mesh multi-cluster su Cloud Service Mesh gestito. Per ulteriori informazioni, vedi Configura una rete mesh multi-cluster.

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

Configura i tuoi cluster GKE

Dopo aver eseguito il provisioning dei cluster GKE e prima di eseguire il deployment carico di lavoro o migrazione dei dati, devi configurare spazi dei nomi, RBAC, criteri di rete account di servizio e altri oggetti Kubernetes e GKE cluster GKE.

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

  1. Assicurati di disporre delle credenziali e delle autorizzazioni necessarie per accedere a entrambi nei cluster nel tuo ambiente di origine e nel tuo cluster GKE completamente gestito di Google Cloud.
  2. Valuta se gli oggetti nei cluster Kubernetes del tuo ambiente di origine sono compatibili con GKE e come le implementazioni differiscono dall'ambiente di origine e da GKE.
  3. Esegui il refactoring di qualsiasi oggetto incompatibile per renderlo compatibile con GKE, o ritirarlo.
  4. Crea questi oggetti nei tuoi cluster GKE.
  5. Configura eventuali oggetti aggiuntivi di cui hai bisogno nel tuo GKE cluster.

Config Sync

Per aiutarti ad adottare GitOps best practice per gestire la configurazione dei tuoi cluster GKE in base alla scalabilità di GKE, ti consigliamo di usare Config Sync, un servizio GitOps per 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 applicare la configurazione.

Per ulteriori informazioni, vedi Architettura di Config Sync.

Policy Controller

Policy Controller consente di applicare e applicare i criteri programmabili per per assicurarti che i cluster e i carichi di lavoro GKE vengano eseguiti in un ambiente in modo conforme. Man mano che il tuo ambiente GKE scala, puoi utilizzare Policy Controller per applicare automaticamente criteri, pacchetti di criteri e vincoli a tutti i tuoi cluster GKE. Ad esempio, puoi limita i repository da cui è possibile estrarre le immagini container può richiedere che ogni spazio dei nomi abbia almeno un'etichetta per garantire il monitoraggio accurato del consumo di risorse.

Per ulteriori informazioni, vedi Policy Controller.

Esegui il refactoring dei carichi di lavoro

Una best practice per progettare carichi di lavoro containerizzati è evitare dipendenze la piattaforma di orchestrazione dei container. Questo potrebbe non essere sempre possibile in base ai requisiti e alla progettazione dei tuoi carichi di lavoro. Ad esempio: i carichi di lavoro potrebbero dipendere dalle funzionalità disponibili solo nel tuo ambiente di origine, ad esempio componenti aggiuntivi, estensioni e integrazioni.

Sebbene sia possibile eseguire la migrazione della maggior parte dei carichi di lavoro così com'è verso GKE, potresti dover dedicare del tempo a eseguire il refactoring carichi di lavoro che dipendono da caratteristiche specifiche dell'ambiente, per da queste dipendenze, passando poi ad alternative disponibili con GKE.

Per eseguire il refactoring dei carichi di lavoro prima di eseguirne la migrazione a GKE, devi le seguenti:

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

Rivedi le funzionalità specifiche dell'ambiente di origine

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

  1. Trova alternative adatte alle soluzioni GKE.
  2. Esegui il refactoring dei carichi di lavoro per usare l'alternativa le soluzioni GKE.

Nell'ambito di questa revisione, ti consigliamo di:

  • Valuta se puoi ritirare o meno queste specifiche dell'ambiente di origine le funzionalità di machine learning.
  • Valutare quanto sia fondamentale una funzionalità specifica dell'ambiente di origine per il successo della migrazione.

Adotta soluzioni GKE alternative adatte

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

  • Evita di adottare soluzioni GKE alternative per l'origine specifiche dell'ambiente che intendi ritirare.
  • Concentrati sull'adozione di soluzioni GKE alternative per funzionalità specifiche dell'ambiente di origine critica e pianifica una migrazione dedicata progetti per il resto.

Esegui il refactoring dei carichi di lavoro

Sebbene la maggior parte dei carichi di lavoro possa funzionare così come in GKE, potresti dover effettuare il refactoring di alcuni di essi, soprattutto se dipendevano specifiche dell'ambiente per le quali hai adottato le soluzioni GKE.

Questo refactoring potrebbe comportare:

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

Per semplificare le operazioni di refactoring, ti consigliamo di concentrarti sull'applicazione le modifiche necessarie per rendere i carichi di lavoro adatti GKE e correzioni di bug critici. Puoi pianificare altri miglioramenti modifiche nell'ambito di progetti futuri.

Esegui il refactoring del deployment e dei processi operativi

Dopo aver eseguito il refactoring dei carichi di lavoro, devi eseguire il refactoring del deployment e delle operazioni processi per:

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

Hai raccolto informazioni su questi processi durante la fase di valutazione nelle prime fasi di questo processo.

Il tipo di refactoring da considerare per questi processi dipende come li hai progettati e implementati. Il refactoring dipende anche da cosa lo stato finale di ogni processo. Ad esempio, considera quanto segue:

  • Probabilmente avete implementato questi processi nell'ambiente di origine e intendiamo progettare e implementare processi simili in Google Cloud. Per Ad esempio, puoi eseguire il refactoring di questi processi Cloud Build Cloud Deploy e Infrastructure Manager.
  • Potresti aver implementato questi processi in un altro ambiente di terze parti esterno all'ambiente di origine. In questo caso, è necessario eseguire il refactoring per scegliere come target il tuo ambiente Google Cloud anziché l'ambiente di origine completamente gestito di Google Cloud.
  • Una combinazione degli approcci precedenti.

Il refactoring del deployment e dei processi operativi può essere complesso e richiedere molto impegno. Se provi a eseguire queste attività nell'ambito del carico di lavoro una migrazione dei dati, la migrazione dei carichi di lavoro può diventare più complessa ai rischi. Dopo aver valutato i processi operativi e di deployment, probabilmente comprenderne il design e la complessità. Se ritieni di aver richiedono un impegno sostanziale per il refactoring del deployment e delle operazioni ti consigliamo di prendere in considerazione il refactoring dei processi nell'ambito un progetto separato e dedicato.

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

Esegui il refactoring dei processi di creazione delle immagini container

Potresti archiviare le immagini container che crei per i tuoi carichi di lavoro un registro di immagini container nel tuo ambiente di origine o in un Container Image Registry. Per questa migrazione a GKE, ti consigliamo di refactoring dei processi di creazione delle immagini container archiviare immagini container in Artifact Registry.

Per facilitare i rollback finali a causa di problemi imprevisti durante migrazione, puoi archiviare le immagini container sia nell'immagine container attuale nel registry e in Artifact Registry mentre è in corso la migrazione a GKE progressi. Infine, nell'ambito del ritiro dell'ambiente di origine, puoi eseguire il refactoring dei processi di creazione delle immagini container in Artifact Registry.

Per eseguire il deployment delle immagini container in GKE, devi configurare una corretta autenticazione. Per ulteriori informazioni, vedi di Artifact Registry in GKE.

Esegui la migrazione delle immagini container

Sebbene possa non essere fondamentale per il successo di una migrazione GKE, potresti dover eseguire la migrazione delle immagini container il registro delle immagini container esistente in Artifact Registry. Ad esempio, potresti aver bisogno è possibile eseguire il rollback dei deployment a punti arbitrari nel tempo, nel caso e inaspettati problemi di deployment. Per ulteriori informazioni, vedi Eseguire la migrazione di immagini da un registro di terze parti.

Migrazione dei dati

GKE supporta diversi servizi di archiviazione dati, come archiviazione a blocchi non elaborati, archiviazione di file e archiviazione di oggetti. Per ulteriori informazioni le informazioni, vedi Panoramica di Storage per i cluster GKE.

Per eseguire la migrazione dei dati nel tuo ambiente GKE, segui questi passaggi:

  1. Esegui il provisioning e la configurazione di tutta l'infrastruttura di archiviazione necessaria.
  2. Configura Provisioner di StorageClass, nei tuoi cluster GKE. Non tutti i provisioner StorageClass sono compatibili con tutti gli ambienti. Prima di eseguire il deployment di un oggetto StorageClass provisioner, ti consigliamo di valutarne la compatibilità di GKE e le sue dipendenze.
  3. Configurare StorageClass.
  4. Configurare oggetti PersistentVolume e PersistentVolumeClaim per archiviare i dati eseguire la migrazione.
  5. Esegui la migrazione dei dati dal tuo ambiente di origine a questi PersistentVolume. La e le specifiche di questa migrazione dei dati dipenderanno dalle caratteristiche dell'origine completamente gestito di Google Cloud.

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

Migrazione dei dati da EKS a GKE

AWS offre diverse opzioni di archiviazione dati per Amazon EKS. Questo documento è incentrato nei seguenti scenari di migrazione dei dati:

  • Migrazione dei dati da volumi Amazon EBS a GKE PersistentVolume risorse.
  • Copia i dati dai volumi Amazon EBS in Amazon S3 o in Cloud Storage, quindi esegui la migrazione dei dati in GKE PersistentVolume risorse.
Migrazione dei dati dai volumi Amazon EBS agli oggetti GKE PersistentVolume

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

  • Copia direttamente i dati dai volumi Amazon EBS su Compute Engine dei dischi permanenti:
    1. Esegui il provisioning delle istanze Amazon EC2 e collega i volumi Amazon EBS che che contengono i dati di cui eseguire la migrazione.
    2. Esegui il provisioning delle istanze di Compute Engine con valori permanenti vuoti con capacità sufficiente per archiviare i dati di cui eseguire la migrazione.
    3. Eseguire 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 di Compute Engine.
    5. Dismetti le istanze di Compute Engine.
    6. Configura i dischi permanenti come GKE PersistentVolume risorse.
  • Esegui la migrazione delle istanze Amazon EC2 e dei volumi Amazon EBS in Compute Engine:
    1. Esegui il provisioning delle istanze Amazon EC2 e collega i volumi Amazon EBS che che contengono i dati di cui eseguire la migrazione.
    2. Esegui la migrazione delle istanze Amazon EC2 e dei volumi Amazon EBS in Compute Engine con Migrate for Virtual Machines.
    3. Scollega i dischi permanenti dalle istanze di Compute Engine.
    4. Dismetti le istanze di Compute Engine.
    5. Configura i dischi permanenti come GKE PersistentVolume risorse.

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

Per ulteriori informazioni sull'uso dei dischi permanenti di Compute Engine Risorse GKE PersistentVolume, consulta Utilizzo di dischi permanenti preesistenti come volumi permanenti.

Copia i dati dai volumi Amazon EBS a un supporto temporaneo ed esegui la migrazione agli oggetti GKE PersistentVolume

Anziché eseguire la migrazione dai volumi Amazon EBS a GKE PersistentVolume risorse direttamente, puoi utilizzare media provvisori come archivio di oggetti:

  1. Caricare i dati dai volumi Amazon EBS su un supporto provvisorio come un nel bucket Amazon S3 o in un bucket Cloud Storage.
  2. Scarica i dati dai contenuti multimediali provvisori sul tuo Risorse PersistentVolume di GKE.

In alcuni scenari, l'utilizzo di più contenuti multimediali può semplificare il trasferimento di dati in base le configurazioni di rete e di sicurezza. Ad esempio, all'inizio puoi caricare i dati in un bucket S3, quindi copiarli dal bucket S3 nel bucket Cloud Storage e scaricare i dati nel bucket come i bilanciatori del carico e i volumi di archiviazione. Indipendentemente dall'approccio scelto, per garantire un'esperienza senza interruzioni transizione tenendo conto di importanti considerazioni, recensione Eseguire la migrazione da AWS a Google Cloud: eseguire la migrazione da Amazon S3 a Cloud Storage.

Scegliere un'opzione di migrazione

La migliore opzione di migrazione dipende dalle tue esigenze specifiche e di sicurezza, tra cui le seguenti considerazioni:

  • La quantità di dati di cui devi eseguire la migrazione.
    • Se hai una piccola quantità di dati da migrare, ad esempio file di dati, prendi in considerazione strumenti come rsync per copiare i dati direttamente dei dischi permanenti di Compute Engine. Questa opzione è relativamente ma potrebbe non essere adatto per una grande quantità di dati.
    • Se devi eseguire la migrazione di una grande quantità di dati, valuta la possibilità di utilizzare Eseguire la migrazione alle macchine virtuali per eseguire la migrazione dei dati in Compute Engine. Questa opzione offre 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 AWS EC2 e Compute Engine, potresti volere valuta di utilizzare Amazon S3 o Cloud Storage per archiviare i dati temporaneamente durante la migrazione su Compute Engine. Questa opzione potrebbe essere meno costoso perché non dovrai tenere di istanze di Compute Engine eseguite contemporaneamente.
  • Le tempistiche della migrazione.
    • Se la larghezza di banda della rete è limitata o viene e le tempistiche non sono comprensibili, 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 pubblicarlo. I test ti aiuteranno a identificare potenziali risolvere i problemi e 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 con GKE. Per ulteriori informazioni, vedi Panoramica del deployment dei carichi di lavoro.

Per preparare i carichi di lavoro per il deployment per GKE, ti consigliamo di di analizzare i descrittori Kubernetes, poiché alcune le risorse di cui GKE esegue automaticamente il provisioning configurabili tramite Kubernetes etichette e annotazioni, anziché dover eseguire manualmente il provisioning di queste risorse. Ad esempio, puoi eseguire il provisioning bilanciatore del carico interno anziché uno esterno, aggiungendo un'annotazione a un servizio LoadBalancer.

Convalida i carichi di lavoro

Dopo aver eseguito il deployment dei carichi di lavoro nell'ambiente GKE, ma prima di esporre questi carichi di lavoro agli utenti, ti consigliamo di di convalida e test approfonditi. Questi test possono aiutarti a verificare che i carichi di lavoro siano si comporta come previsto. Ad esempio, potresti:

  • Eseguire test di integrazione, test di carico, test di conformità, affidabilità test e altre procedure di verifica che ti aiutano ad assicurare che il tuo di carichi di lavoro operano all'interno dei parametri previsti e in base le relative specifiche.
  • Esamina i log, le metriche e i report sugli errori in Google Cloud Observability identificare i 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à.

Esponi i tuoi carichi di lavoro

Una volta completati i test di convalida dei carichi di lavoro in esecuzione dell'ambiente GKE, esponi i tuoi carichi di lavoro in modo da 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 carichi di lavoro in esecuzione su GKE, consulta:

Shift il traffico al tuo ambiente Google Cloud

Dopo aver verificato che i carichi di lavoro sono in esecuzione in GKE e, dopo averli esposti ai clienti, sposti il traffico dall'ambiente di origine all'ambiente GKE. Per aiutarti evitare migrazioni su larga scala e tutti i rischi correlati, di spostare gradualmente il traffico dall'ambiente di origine a GKE.

A seconda di come hai progettato il tuo ambiente GKE, devi diverse opzioni per implementare un meccanismo di bilanciamento del carico che cambia gradualmente il traffico proveniente dall'ambiente di origine a quello di destinazione. Ad esempio: potresti implementare un criterio di risoluzione DNS che risolva i record DNS in base a un criterio per risolvere una determinata percentuale di richieste a IP gli indirizzi IP che appartengono al tuo ambiente GKE. In alternativa, puoi implementare un meccanismo di bilanciamento del carico che utilizza indirizzi IP virtuali e carico di rete bilanciatori del carico e bilanciatori del carico.

Dopo aver iniziato a spostare gradualmente il traffico su GKE ti consigliamo di monitorare il comportamento dei carichi di lavoro il loro carico aumenta.

Infine, esegui una cutover, che si verifica quando sposti tutto il traffico dall'ambiente di origine all'ambiente GKE.

Per ulteriori informazioni sul bilanciamento del carico, vedi Bilanciamento del carico nel frontend.

Dismissione dell'ambiente di origine

Dopo che i carichi di lavoro nel tuo ambiente GKE gestiscono le richieste correttamente, dismetti l'ambiente di origine.

Prima di iniziare a ritirare le risorse nel tuo 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.
  • Invia una notifica agli utenti prima di ritirare l'ambiente.

Per ritirare l'ambiente di origine:

  1. Dismetti i carichi di lavoro in esecuzione nei cluster nell'origine completamente gestito di Google Cloud.
  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, l'ordine di ritiro delle risorse nel tuo ambiente di origine è importante. Ad esempio, alcune richiedono il ritiro dei servizi Kubernetes che portano e la creazione di bilanciatori del carico prima di poter che contengono questi bilanciatori del carico.

Ottimizza il tuo ambiente Google Cloud

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

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

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

Per saperne di più sull'ottimizzazione del tuo ambiente Google Cloud, consulta Eseguire la migrazione a Google Cloud: ottimizzare l'ambiente e Procedura di ottimizzazione del rendimento.

Le seguenti sezioni integrano le considerazioni in Migrate to Google Cloud: ottimizza il tuo ambiente.

Definisci i tuoi requisiti di ottimizzazione

I requisiti di ottimizzazione consentono di restringere l'ambito dell'ottimizzazione attuale dell'iterazione. Per ulteriori informazioni sui requisiti e sugli obiettivi di ottimizzazione, consulta Definisci i requisiti e gli obiettivi di ottimizzazione.

per definire i requisiti di ottimizzazione per GKE dell'ambiente di lavoro, considera innanzitutto i seguenti aspetti:

  • Sicurezza, privacy e conformità: consentono di migliorare il livello di sicurezza del tuo ambiente GKE.
  • Affidabilità: consentono di migliorare disponibilità, scalabilità e resilienza del tuo ambiente GKE.
  • Ottimizzazione dei costi: ti aiuta a ottimizzare il consumo di risorse e per il tuo ambiente GKE.
  • Efficienza operativa: ti aiuta a mantenere e gestire l'ambiente GKE in modo efficiente.
  • Ottimizzazione del rendimento: ti aiuta a ottimizzare il rendimento del per carichi di lavoro di cui è stato eseguito il deployment nel tuo ambiente GKE.

Sicurezza, privacy e conformità

  • Monitora la strategia di sicurezza dei tuoi cluster GKE. Puoi Usa la dashboard della security posture per ricevere consigli utili e pratici, che ti aiuteranno a migliorare della strategia di sicurezza per l'ambiente GKE.
  • Proteggi il tuo ambiente GKE. L'architettura Modello di sicurezza di GKE, e come rafforzare la protezione dei cluster GKE.
  • Implementa una catena di fornitura del software sicura. Per carichi di lavoro critici per la sicurezza, puoi implementare una fornitura software sicura con nei tuoi cluster GKE Software Delivery Shield (scudo di distribuzione del software).

Affidabilità

  • Migliora l'affidabilità dei cluster. Per aiutarti a progettare più resiliente a improbabili interruzioni a livello di zona, preferisca cluster regionali a livello di zona o multi-zona.
  • Backup e ripristino del carico di lavoro. Configura il backup e il ripristino di un carico di lavoro un flusso di lavoro con Backup per GKE.

Ottimizzazione dei costi

Per ulteriori informazioni sull'ottimizzazione dei costi di GKE vedi l'ambiente Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.

Efficienza operativa

Per evitare problemi che influiscono sul tuo ambiente di produzione, ti consigliamo che tu:

  • Progetta i tuoi cluster GKE in modo che siano fungibili. Considerando di replicare i cluster come fungibili e automatizzando il provisioning e la configurazione, puoi semplificare e generalizzare i processi operativi per mantenerli e semplificare le migrazioni future e gli upgrade dei cluster GKE. Ad esempio, se devi eseguire l'upgrade di un cluster GKE fungibile a un nuova versione di GKE, puoi eseguire il provisioning un nuovo cluster con upgrade eseguito, il deployment automatico dei carichi di lavoro nel nuovo cluster, e dismettere il vecchio cluster GKE obsoleto.
  • Monitora le metriche che ti interessano. Assicurati che tutte le metriche di interesse che i carichi di lavoro e i cluster vengano raccolti correttamente. Verifica inoltre che tutte le allarmi pertinenti che usano queste metriche come input in atto e funzionanti.

Per ulteriori informazioni sulla configurazione del monitoraggio, del logging e della profilazione in dell'ambiente GKE, consulta:

Ottimizzazione delle prestazioni

Per saperne di più, consulta Informazioni sulla scalabilità di GKE.

Passaggi successivi

Collaboratori

Autori: