Questa pagina è stata tradotta dall'API Cloud Translation.

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 ambiente Kubernetes autogestito a 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 è utile se prevedi di eseguire la migrazione da un ambiente Kubernetes autonomo a GKE. L'ambiente potrebbe essere in esecuzione in un ambiente on-premise, in un ambiente di hosting privato o in un altro provider cloud. Questo documento è utile anche se stai valutando le opportunità di migrazione e vogliamo vedere come potrebbe essere.

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

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

Per ulteriori informazioni su GKE, consulta Panoramica di GKE.

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

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

Percorso di migrazione diviso in quattro fasi.

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

Valuta e individua i carichi di lavoro e i dati.
Pianifica e crea una base su Google Cloud.
Esegui la migrazione dei carichi di lavoro e dei dati in Google Cloud.
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, devi determinare i requisiti e le dipendenze per eseguire la migrazione dell'ambiente di origine a 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à:

Crea un inventario completo dei tuoi carichi di lavoro.
Cataloga i carichi di lavoro in base alle loro proprietà e dipendenze.
Forma e istruisci i tuoi team su Google Cloud.
Crea esperimenti e proof of concept su Google Cloud.
Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
Scegli la strategia di migrazione per i tuoi carichi di lavoro.
Scegli i tuoi strumenti di migrazione.
Definisci il piano di migrazione e le tempistiche.
Convalida il piano di migrazione.

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

Creare gli inventari

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

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

Dopo aver creato questi inventari, puoi:

Valuta le procedure di deployment e operative per l'ambiente di origine.
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 o su una generazione diversa da quelle utilizzate 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 e le interfacce che interagiscono con i cluster.
Multitenancy. Se gestisci cluster multi-tenant nel tuo ambiente, valuta se funzionano nel nuovo ambiente Google Cloud. Ora è un buon momento per valutare come migliorare i tuoi cluster multi-tenant, perché la tua strategia di multitenancy influisce sul modo in cui crei la tua base su Google Cloud.
Versione Kubernetes. Raccogli informazioni sulla versione Kubernetes dei tuoi cluster per valutare se esiste una mancata corrispondenza tra queste versioni e quelle disponibili in GKE. Se esegui una versione di Kubernetes precedente o rilasciata di recente, potrebbero utilizzare funzionalità non disponibili in GKE. Le funzionalità potrebbero essere ritirate o la versione di Kubernetes che le include non è ancora disponibile in GKE.
Ciclo di upgrade di Kubernetes. Per mantenere un ambiente affidabile, scopri come gestisci gli upgrade di Kubernetes e come il tuo ciclo di upgrade si relaziona agli upgrade di GKE.
Pool di nodi. Se utilizzi 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.
Inizializza il nodo. 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 eventuali requisiti di conformità e normativi che i tuoi cluster devono soddisfare e se li stai soddisfacendo.
Quote e limiti. Valuta come hai configurato quote e limiti per cluster. Ad esempio, quanti pod può eseguire ogni nodo? Quanti nodi può avere un cluster?
Etichette e tag. Valuta tutti i metadati che hai applicato ai cluster, pool e nodi e come li utilizzi. Ad esempio, potresti generare report con un'attribuzione dei costi dettagliata e basata su etichette.

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

Spazi dei nomi. Se utilizzi gli spazi dei nomi Kubernetes nei tuoi cluster per separare logicamente le risorse, valuta quali risorse si trovano in ogni spazio dei nomi e comprendi perché hai creato questa separazione. Ad esempio, potresti utilizzare gli spazi dei nomi come parte della tua strategia di multitenancy. Potresti avere carichi di lavoro di cui è stato eseguito il deployment in spazi dei nomi riservati per i componenti di sistema Kubernetes e potresti non avere lo stesso controllo in GKE.
Controllo controllo dell'accesso basato sui ruoli (RBAC) Se utilizzi 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.
Contesti di sicurezza dei pod. Acquisisci informazioni sui contesti di sicurezza dei pod che hai configurato nei tuoi cluster e scopri come funzionano in GKE.
Account di servizio. Se un processo nel cluster interagisce con il server API Kubernetes, acquisisci informazioni sugli account di servizio in uso.

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

Crea l'inventario dei tuoi carichi di lavoro Kubernetes

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

Pod e controller. Per dimensionare i cluster nel nuovo ambiente, valuta 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 DaemonSet utilizzi?
Job e CronJob. I tuoi cluster e carichi di lavoro potrebbero dover eseguire job o CronJob nell'ambito delle procedure di inizializzazione o di funzionamento. Valuta il numero di istanze di job e CronJob di cui hai eseguito il deployment e responsabilità e criteri di completamento per ogni istanza.
Autoscaler 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 stato nel cluster o in uno spazio di 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 le note di rilascio di ogni versione di Kubernetes per sapere quali funzionalità sono incluse e quali sono ritirate. Poi valuta i tuoi carichi di lavoro in base alle funzionalità di Kubernetes di cui hai bisogno. Lo scopo di questa attività è sapere se stai utilizzando funzionalità deprecate o non ancora disponibili in GKE. Se trovi funzionalità non disponibili, esegui la migrazione da quelle ritirate e adotta le nuove quando sono disponibili in GKE.
Spazio di archiviazione. Per i carichi di lavoro stateful, valuta se utilizzano PersistentVolumeClaims. 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 estendere qualsiasi PersistenceVolumeClaim.
Configurazione e inserimento di secret. Per evitare di ricostruire gli artefatti di cui è possibile eseguire il deployment ogni volta che si verifica una modifica nella configurazione del tuo ambiente, inserisci la configurazione e i secret nei pod utilizzando ConfigMap e Secret. Per ogni carico di lavoro, valuta quali ConfigMap e Secret vengono utilizzati e come vengono compilati questi oggetti.
Dipendenze. I tuoi carichi di lavoro probabilmente non funzionano in isolamento. Potrebbero avere dipendenze interne al cluster o da sistemi esterni. Per ogni carico di lavoro, acquisisci le dipendenze e, dei carichi di lavoro tollerano quando le dipendenze non sono disponibili. Ad esempio, le dipendenze comuni includono file system distribuiti, database, piattaforme di distribuzione di secret, sistemi di gestione dell'identità e dell'accesso, meccanismi di rilevamento dei servizi e qualsiasi altro sistema esterno.
Servizi Kubernetes. Per esporre i tuoi carichi di lavoro ai client interni ed esterni, utilizza Servizi. Per ogni servizio, devi conoscere il relativo tipo. Per 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 coprono, quali servizi fanno parte del mesh e come modificare la topologia del mesh.
Incompatibilità e tolleranze e affinità e anti-affinità. Per ogni pod e nodo, valuta se hai configurato incompatibilità dei nodi, tolleranze dei pod o affinità per personalizzare la pianificazione dei pod nei tuoi cluster Kubernetes. Queste proprietà possono anche fornirti informazioni su possibili configurazioni non omogenee di nodi o pod e indicare che i pod, i nodi o entrambi devono essere valutati con particolare attenzione. 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.

Valutare 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, prendi in considerazione quanto segue: capacità, modalità del volume, modalità di accesso, classe, criterio di recupero, opzioni di montaggio e affinità dei nodi.
VolumeSnapshots e VolumeSnapshotContents. Per ogni PersistentVolume, valuta se hai configurato VolumeSnapshot se devi eseguire la migrazione di VolumeSnapshotContents esistente.
Driver di Container Storage Interface (CSI). Se sono implementati nei tuoi cluster, valuta se questi driver sono compatibili con GKE e se è necessario adattare la configurazione dei volumi in modo che funzionino con driver CSI compatibili con GKE.
Archiviazione dei dati. Se hai bisogno di sistemi esterni per eseguire il provisioning di PersistentVolumes, fornisci ai carichi di lavoro nel tuo ambiente GKE un modo per utilizzare questi sistemi. La 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, devi raccogliere informazioni su ogni tipo di elemento. Ad esempio, un elemento può essere un pacchetto del sistema operativo, un pacchetto di deployment dell'applicazione, un'immagine del sistema operativo, un'immagine del contenitore o qualcos'altro.

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

Sviluppa i tuoi carichi di lavoro. Valuta le procedure messe in atto dai team di sviluppo per creare i carichi di lavoro. Ad esempio, in che modo i team di sviluppo progettando, programmando e testando i carichi di lavoro?
Genera gli elementi da eseguire 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 memorizzi in un registro di artefatti nel tuo ambiente di origine, devi renderli 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 compilazione degli elementi: completa un refactoring minore dell'ambiente di origine in modo da poter archiviare gli elementi sia nell'ambiente di origine sia nell'ambiente di destinazione. Questo approccio supporta la migrazione creando un'infrastruttura come un repository di elementi prima di dover implementare le procedure di compilazione degli elementi nell'ambiente Google Cloud di destinazione. Puoi implementare questo approccio direttamente o puoi basarti sull'approccio precedente di stabilire prima un canale di comunicazione.
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 delle procedure di compilazione degli elementi, potresti utilizzare la scansione del codice per proteggerti da vulnerabilità comuni e dall'esposizione involontaria alla rete, nonché la firma del codice per assicurarti che nei tuoi ambienti venga eseguito solo codice attendibile.
Esegui il deployment degli elementi nell'ambiente di origine. Dopo 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 implementazione. La valutazione aiuta garantire che i processi di deployment siano compatibili con Google Cloud. Inoltre, ti aiuta a comprendere lo sforzo necessario per e infine il refactoring dei processi. Ad esempio, se le tue procedure di implementazione funzionano solo con l'ambiente di origine, potresti doverle eseguire il refactoring per scegliere come target il tuo ambiente Google Cloud.
Esegui l'iniezione della configurazione di runtime. Potresti iniettare la configurazione di runtime per cluster, ambienti di runtime o deployment dei carichi di lavoro specifici. La potrebbe inizializzare le variabili di ambiente e altre configurazioni come secret, credenziali e chiavi. Per contribuire a garantire che le procedure di inserimento della configurazione di runtime funzionino su Google Cloud, ti consigliamo di valutare la modalità di configurazione dei carichi di lavoro eseguiti nel tuo ambiente di origine.
Logging, monitoraggio e profilazione. Valuta le procedure di registrazione, monitoraggio e profiling che hai implementato per monitorare lo stato di integrità del tuo ambiente di origine, le metriche di interesse e il modo in cui utilizzi i dati forniti da queste procedure.
Autenticazione cluster. Valuta la tua modalità di autenticazione rispetto al tuo dell'ambiente di origine.
Esegui il provisioning e configura le risorse. Per preparare l'ambiente di origine, potresti aver progettato e implementato processi che eseguono il provisioning e la configurazione delle risorse. Ad esempio, potresti utilizzare Terraform 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 segui questi passaggi:

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à:

Crea una gerarchia di risorse.
Configurare Identity and Access Management (IAM) di Google Cloud.
Configura la fatturazione.
Configura la connettività di rete.
Rafforza la sicurezza.
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 riportate in Esegui la migrazione a Google Cloud: pianifica e crea le basi.

Pianifica il multitenancy

Per progettare una gerarchia delle risorse efficiente, valuta come le strutture aziendali e organizzative vengono mappate in Google Cloud. Ad esempio, se 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 lo stesso isolamento. 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, consulta 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:

Esegui il provisioning e la configurazione dell'ambiente GKE.
Configura i tuoi cluster GKE.
Esegui il refactoring dei carichi di lavoro.
Esegui il refactoring dei processi di deployment e operativi.
Esegui la migrazione dei dati dal tuo ambiente di origine a Google Cloud.
Esegui il deployment dei carichi di lavoro nel tuo ambiente GKE.
Convalida i carichi di lavoro e l'ambiente GKE.
Esponi i carichi di lavoro in esecuzione su GKE.
Shift il traffico dall'ambiente di origine all'ambiente GKE.
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, devi eseguire 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. In caso contrario, potrebbe essere necessario eliminare e ricreare i cluster nel caso in cui le funzionalità di cluster di cui hai bisogno non possano essere attivate dopo la creazione di un cluster.

Dopo la fase di valutazione, 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 ciascun nodo e i piani di scalabilità di ciascun cluster.
La modalità di funzionamento di ogni cluster. GKE offre due modalità di funzionamento per i cluster: GKE Autopilot e 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 nei cluster GKE e se devi creare automaticamente pool di nodi con il provisioning automatico dei nodi.
Le procedure di inizializzazione che puoi trasferire dal tuo ambiente all'ambiente GKE e le nuove procedure che puoi implementare. Ad esempio, puoi avviare automaticamente i nodi GKE implementando una o più procedure di inizializzazione, eventualmente privilegiate, per ogni nodo o pool di nodi nei tuoi cluster.
I piani di scalabilità per ogni cluster.
Le funzionalità GKE aggiuntive di cui hai bisogno, ad esempio Cloud Service Mesh, e i componenti aggiuntivi GKE, ad esempio Backup for GKE.

Per ulteriori informazioni sul provisioning dei cluster GKE, consulta:

Gestione del parco risorse

Quando esegui il provisioning dei 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:

Multi-Cluster Service Discovery, un meccanismo di rilevamento e chiamata dei servizi tra cluster. I servizi sono rilevabili e accessibili nei 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 saperne di più, consulta Eseguire il deployment di gateway multi-cluster.
Mesh multi-cluster su Cloud Service Mesh gestito. Per ulteriori informazioni, consulta Configurare un mesh multicluster.

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:

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.
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.
Ristruttura qualsiasi oggetto incompatibile per renderlo compatibile con GKE o ritiralo.
Crea questi oggetti nei tuoi cluster GKE.
Configura gli oggetti aggiuntivi di cui hai bisogno nei tuoi cluster GKE.

Config Sync

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

Per ulteriori informazioni, consulta la sezione 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, consulta Controller dei criteri.

Esegui il refactoring dei carichi di lavoro

Una best practice per progettare carichi di lavoro containerizzati è evitare dipendenze dalla piattaforma di orchestrazione dei container. 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 tu possa eseguire la migrazione della maggior parte dei carichi di lavoro così come sono su GKE, potresti dover fare uno sforzo aggiuntivo per eseguire il refactoring dei carichi di lavoro che dipendono da funzionalità specifiche dell'ambiente, al fine di ridurre al minimo queste dipendenze, passando eventualmente ad alternative disponibili su GKE.

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

Esamina le funzionalità specifiche dell'ambiente di origine, come componenti aggiuntivi, estensioni e integrazioni.
Adotta soluzioni GKE alternative appropriate.
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 tuoi carichi di lavoro dipendono da queste funzionalità, devi:

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

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

Valuta la possibilità di ritirare una di queste funzionalità specifiche dell'ambiente di origine.
Valuta quanto sia fondamentale una funzionalità specifica dell'ambiente di origine per la riuscita della migrazione.

Adotta soluzioni GKE alternative idonee

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

Evita di adottare soluzioni GKE alternative per le funzionalità specifiche dell'ambiente di origine che intendi ritirare.
Concentrati sull'adozione di soluzioni GKE alternative per 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ì com'è in GKE, potresti dover eseguire il refactoring di alcuni, soprattutto se dipendevano da funzionalità specifiche dell'ambiente di origine per le quali hai adottato soluzioni GKE alternative.

Questo refactoring potrebbe comportare:

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

Per semplificare 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.

Ristrutturare i processi di deployment e 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 i carichi di lavoro ed esegui il loro deployment in Google Cloud instead of in the source environment.

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

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

Potresti aver implementato queste procedure nel tuo ambiente di origine e intendi progettare e implementare procedure simili in Google Cloud. 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, devi eseguire il refactoring di queste procedure in modo che abbiano come target l'ambiente Google Cloud anziché l'ambiente di origine.
Una combinazione degli approcci precedenti.

Il refactoring dei processi di deployment e operativi può essere complesso e richiedere un impegno significativo. Se provi a eseguire queste attività nell'ambito 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 di implementazione e operativi, probabilmente hai compreso il loro design e la loro 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:

Questo documento è incentrato sui processi di deployment che producono gli artefatti eseguire il deployment e implementarle nell'ambiente di runtime di destinazione. Il refactoring strategia dipende molto dalla complessità di questi processi. Il seguente elenco delinea una possibile strategia di refactoring generale:

Esegui il provisioning dei repository di elementi su Google Cloud. Ad esempio, puoi usa Artifact Registry per archiviare artefatti e creare dipendenze.
Esegui il refactoring delle procedure di compilazione per archiviare gli artefatti sia nell'ambiente di origine sia in Artifact Registry.
Esegui il refactoring delle procedure di deployment per distribuire i carichi di lavoro nell'ambiente Google Cloud di destinazione. Ad esempio, puoi iniziare a eseguire il deployment di un piccolo sottoinsieme dei tuoi carichi di lavoro in Google Cloud utilizzando gli elementi archiviati in Artifact Registry. Poi, aumenta gradualmente il numero di carichi di lavoro di cui è stato eseguito il deployment in Google Cloud, fino a quando tutti i carichi di lavoro di cui vuoi eseguire la migrazione non vengono eseguiti su Google Cloud.
Esegui il refactoring delle procedure di compilazione per archiviare gli artefatti solo in Artifact Registry.
Se necessario, esegui la migrazione delle versioni precedenti degli elementi da eseguire il deployment dai repository nell'ambiente di origine ad Artifact Registry. Ad esempio, puoi e copiare immagini container in Artifact Registry.
Puoi dismettere i repository nel tuo ambiente di origine quando se ne richiedono uno.

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

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

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

Esegui il deployment dei carichi di lavoro

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

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

Convalidare i carichi di lavoro

Dopo aver eseguito il deployment dei carichi di lavoro nel tuo ambiente GKE, ma prima di esporli agli utenti, ti consigliamo di eseguire verifiche e test approfonditi. Questi test possono aiutarti a verificare che i carichi di lavoro siano si comporta come previsto. Ad esempio, potresti:

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

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

Esponi i tuoi carichi di lavoro

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

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

Per ulteriori informazioni sull'esposizione dei carichi di lavoro in esecuzione in 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, hai diverse opzioni per implementare un meccanismo di bilanciamento del carico che trasferisca gradualmente il traffico dall'ambiente di origine a quello di destinazione. Ad esempio, puoi implementare un criterio di risoluzione DNS che risolva i record DNS in base a un criterio per risolvere una determinata percentuale di richieste agli indirizzi IP appartenenti al tuo ambiente GKE. In alternativa, puoi implementare un meccanismo di bilanciamento del carico 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 un cutover, ovvero 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 hanno iniziato a gestire correttamente le richieste, puoi ritirare l'ambiente di origine.

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

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

Per ritirare l'ambiente di origine:

Esegui la disattivazione dei carichi di lavoro in esecuzione nei cluster dell'ambiente di origine.
Elimina i cluster nell'ambiente di origine.
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 delle attività di ottimizzazione finché l'ambiente di destinazione non soddisfa i requisiti di ottimizzazione. I passaggi di ogni iterazione sono i seguenti:

Valuta l'ambiente attuale, i team e il ciclo di ottimizzazione.
Stabilisci i requisiti e gli obiettivi di ottimizzazione.
Ottimizza il tuo ambiente e i tuoi team.
Ottimizza il ciclo di ottimizzazione.

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

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

Le 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 stabilire i requisiti di ottimizzazione per il tuo ambiente GKE, inizia tenendo conto dei seguenti aspetti:

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

Sicurezza, privacy e conformità

Monitora la 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. Scopri il modello di sicurezza GKE e come proteggere i tuoi 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 tuoi 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 del costo dell'ambiente GKE, consulta:

Efficienza operativa

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

Progetta i tuoi cluster GKE in modo che siano fungibili. Considerando di replicare i cluster come fungibili e automatizzando il provisioning e la configurazione, puoi semplificare e generalizzare i processi operativi per mantenerli oltre a 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 relative ai tuoi carichi di lavoro e cluster vengano raccolte correttamente. Inoltre, verifica che tutti gli avvisi pertinenti che utilizzano queste metriche come input siano impostati e funzionino.

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

Ottimizzazione delle prestazioni

Configura la scalabilità automatica del cluster e il provisioning automatico dei nodi. Ridimensiona automaticamente il tuo cluster GKE in base alla domanda utilizzando la scalabilità automatica del cluster e il provisioning automatico dei nodi.
Scalabilità automatica dei carichi di lavoro. GKE supporta diversi come:
- Scala automaticamente i carichi di lavoro in base alle metriche.
- Scala automaticamente i carichi di lavoro modificando la forma del numero di pod i tuoi carichi di lavoro Kubernetes Scalabilità automatica orizzontale dei pod.
- Scala automaticamente i carichi di lavoro regolando le richieste e i limiti delle risorse configurando la scalabilità automatica pod verticale.

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

Passaggi successivi

Scopri quando consulta l'assistenza per le migrazioni.
Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.

Collaboratori

Autore: Marco Ferrari | Cloud Solutions Architect