Migrazione dei container in Google Cloud: migrazione da Kubernetes a GKE

Last reviewed 2024-06-22 UTC

Questo documento ti aiuta a pianificare, progettare e implementare la migrazione da un un ambiente Kubernetes autogestito Google Kubernetes Engine (GKE) Se questa operazione non è corretta, lo spostamento delle app da un ambiente all'altro può essere è un'attività complessa, quindi devi pianificare ed eseguire la migrazione con attenzione.

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

Questo documento è utile se hai intenzione di eseguire la migrazione da un ambiente autogestito da Kubernetes a GKE. Il tuo ambiente potrebbe essere in esecuzione in un ambiente on-premise, in un ambiente di hosting privato con un altro cloud provider. Questo documento è utile anche se stai valutando le opportunità di migrazione e vogliamo vedere come potrebbe essere.

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 il tuo ambiente

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 il deployment e i processi operativi 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 le procedure di inizializzazione 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, ai nodi 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.

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.

Migrazione dei dati ed 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:

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 è più difficile da utilizzare 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 cui 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.

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

Autore: Marco Ferrari | Cloud Solutions Architect