Migrazione dei container in Google Cloud: migrazione da OpenShift a GKE Enterprise

Questo documento ti aiuta a pianificare, progettare e implementare la migrazione da OpenShift a GKE Enterprise. Se eseguito in modo errato, spostare i carichi di lavoro da un ambiente all'altro può essere un'attività impegnativa, quindi pianifica ed esegui la migrazione con attenzione.

Questo documento fa parte di una serie in più parti sulla migrazione a Google Cloud. Se ti interessa una panoramica della serie, consulta Migrazione a Google Cloud: scelta del percorso di migrazione.

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

• Migrazione dei container in Google Cloud: migrazione di Kubernetes a Google Kubernetes Engine (GKE)
• Migrazione dei container in Google Cloud: migrazione a un nuovo ambiente GKE
• Migrazione dei container in Google Cloud: migrazione da OpenShift a GKE Enterprise (questo documento)
• Migrazione dei container in Google Cloud: migrazione dei progetti OpenShift a GKE Enterprise
• Migrazione da OpenShift a GKE Enterprise: migrazione delle SCC di OpenShift ai vincoli di Policy Controller

Questo documento è utile se prevedi di eseguire la migrazione da OpenShift in esecuzione in un ambiente di hosting on-premise o privato, oppure in un altro cloud provider, a GKE Enterprise. Questo documento è utile anche se stai valutando l'opportunità di eseguire la migrazione e vuoi esplorare il possibile aspetto. L'ambiente di destinazione può essere uno dei seguenti:

• Un ambiente ospitato interamente su Google Cloud.
• Un ambiente ibrido in cui gestisci parte del carico di lavoro on-premise o in un ambiente di hosting privato e migra il resto su Google Cloud.

Per decidere quale ambiente è adatto alle tue esigenze, considera le tue esigenze. Ad esempio, puoi concentrarti sull'aumento del valore della tua azienda invece di preoccuparti dell'infrastruttura, eseguendo la migrazione a un ambiente cloud pubblico ed esternalizzando alcune responsabilità a Google. Puoi trarre vantaggio da un modello di consumo elastico per ottimizzare la spesa e l'utilizzo delle risorse. Se hai dei requisiti, ad esempio per conservare alcuni carichi di lavoro al di fuori di Google Cloud, ti consigliamo di prendere in considerazione un ambiente ibrido, ad esempio se devi mantenere parte dei tuoi carichi di lavoro nell'ambiente attuale per rispettare i criteri e le normative sulla posizione dei dati. In alternativa, puoi implementare una strategia di migrazione di tipo migliora e sposta, in cui prima devi modernizzare i carichi di lavoro in loco e poi eseguire la migrazione a Google Cloud.

A prescindere dal tipo di ambiente di destinazione, l'obiettivo di questa migrazione è gestire i carichi di lavoro in esecuzione nell'ambiente utilizzando GKE Enterprise. Adottando GKE Enterprise, hai accesso a una serie di servizi, tra cui:

• Gestione multi-cluster per aiutare te e la tua organizzazione a gestire da un'unica posizione i cluster, l'infrastruttura e i carichi di lavoro in ambienti cloud e on-premise.
• Config Sync e Policy Controller per creare una configurazione e criteri comuni in tutta la tua infrastruttura e per applicarli sia on-premise che nel cloud.
• Anthos Service Mesh per adottare un mesh di servizi completamente gestiti che semplifica i servizi operativi, la gestione del traffico, la telemetria e la protezione delle comunicazioni tra i servizi.
• Autorizzazione binaria per garantire che i container di cui esegui il deployment nei tuoi ambienti siano attendibili.
• Cloud Run for Anthos per supportare i carichi di lavoro serverless nel tuo ambiente GKE Enterprise.

Ti consigliamo di valutare questi servizi all'inizio del processo di migrazione, mentre è ancora in fase di progettazione della migrazione. È più facile adottare questi servizi ora, anziché modificare i processi e l'infrastruttura in un secondo momento. Puoi iniziare a utilizzare questi servizi immediatamente o quando vuoi modernizzare i carichi di lavoro.

In questa migrazione, seguirai il framework di migrazione definito in Migrazione a Google Cloud: Introduzione. Il framework prevede quattro fasi:

1. Valutazione e scoperta dei carichi di lavoro.
2. Pianificazione e costruzione di fondamenta.
3. Deployment dei carichi di lavoro.
4. Ottimizzare l'ambiente.

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

Questo documento si basa sui concetti trattati nell'articolo Migrazione dei container in Google Cloud: migrazione di Kubernetes a GKE. Sono quindi disponibili i link al documento, ove appropriato.

Valutazione e scoperta dei carichi di lavoro

Nella fase di valutazione, determini i requisiti e le dipendenze per la migrazione ai carichi di lavoro da OpenShift a GKE Enterprise:

1. Crea un inventario completo dei tuoi processi e delle tue app.
2. Cataloga i tuoi processi e le tue app in base alle loro proprietà e dipendenze.
3. Addestra e istruisci i tuoi team su Google Cloud.
4. Crea esperimenti e proof of concept su Google Cloud.
5. Calcolare il costo totale di proprietà (TCO) dell'ambiente di destinazione.
6. Scegli i carichi di lavoro di cui vuoi eseguire prima la migrazione.

Le seguenti sezioni si basano su Migrazione a Google Cloud: valutazione e individuazione dei carichi di lavoro, ma forniscono informazioni specifiche per la valutazione dei carichi di lavoro di cui vuoi eseguire la migrazione da OpenShift a GKE Enterprise.

Crea i tuoi inventari

Per creare l'inventario dei componenti del tuo ambiente, considera quanto segue:

• Modello di fornitura dei servizi e gestione della piattaforma
• Progetti OpenShift
• Processo di creazione e deployment
• Carichi di lavoro, requisiti e dipendenze
• Configurazione dei cluster OpenShift

Modello di fornitura dei servizi e gestione della piattaforma

Per eseguire la migrazione dei carichi di lavoro da OpenShift a GKE Enterprise, devi valutare il modello attuale di distribuzione dei servizi e di gestione della piattaforma del tuo ambiente OpenShift. Questo modello riflette probabilmente la struttura e le esigenze dell'organizzazione. Se ti rendi conto che il modello attuale non soddisfa le esigenze dell'organizzazione, puoi utilizzare questa migrazione come opportunità per migliorarlo.

In primo luogo, raccogli informazioni sui team responsabili dei seguenti aspetti:

• Sviluppo e deployment di applicazioni, inclusi tutti gli utenti OpenShift, in genere team di sviluppo o rilascio dei carichi di lavoro.
• Gestione della piattaforma OpenShift, incluse la creazione di progetti OpenShift, l'assegnazione di ruoli agli utenti, la configurazione dei contesti di sicurezza e la configurazione delle pipeline CI/CD.
• Installazione di OpenShift e gestione dei cluster, compresi installazione, upgrade, scalabilità dei cluster e gestione della capacità di OpenShift.
• Gestione dell'infrastruttura. che gestiscono i server fisici, lo spazio di archiviazione, il networking, la piattaforma di virtualizzazione e i sistemi operativi.

Un modello di distribuzione dei servizi e di gestione della piattaforma può essere composto dai seguenti team:

• Il team di sviluppo. Questo team sviluppa carichi di lavoro e ne esegue il deployment su OpenShift. In ambienti di produzione complessi, il team che distribuisce i carichi di lavoro potrebbe essere diverso dal team di sviluppo. Per semplicità in questo documento, consideriamo questo team come parte del team di sviluppo. In ambienti self-service, il team di sviluppo ha anche la responsabilità di creare progetti OpenShift.
• Il team della piattaforma. Questo team è responsabile della gestione della piattaforma OpenShift, generalmente indicata come amministratori dei cluster OpenShift. Questo team configura modelli di progetto OpenShift per diversi team di sviluppo e, in ambienti più gestiti, crea progetti OpenShift. Questo team assegna inoltre ruoli e autorizzazioni, configura i contesti di sicurezza e il controllo degli accessi basato sui ruoli (RBAC), definisce le quote per le risorse e gli oggetti di calcolo e definisce le strategie di build e deployment. A volte sono indicati come team DevOps o team middleware se gestiscono le configurazioni middleware e server applicazioni per gli sviluppatori. Il team della piattaforma e il team dell'infrastruttura potrebbero anche essere coinvolti in attività di gestione dei cluster OpenShift di basso livello, come l'installazione e l'upgrade del software, la scalabilità dei cluster e la gestione della capacità.
• Il team dell'infrastruttura. Questo team gestisce l'infrastruttura di base che supporta l'ambiente OpenShift. Ad esempio, sono responsabili dei server, dello spazio di archiviazione, del networking, della piattaforma di virtualizzazione e del sistema operativo di base. Talvolta, questo team viene definito team del data center o team operativo. Se il deployment di OpenShift viene eseguito in un ambiente cloud pubblico, il team è responsabile dei servizi Infrastructure as a Service (IaaS) offerti da un provider cloud pubblico.

È inoltre importante valutare se disponi di cluster OpenShift dedicati per ambienti diversi. Ad esempio, potresti avere ambienti diversi per lo sviluppo, il controllo qualità e la produzione o per separare zone di rete e sicurezza diverse, come zone interne e zone demilitarizzate.

Progetti OpenShift

Un progetto OpenShift è uno spazio dei nomi Kubernetes con annotazioni aggiuntive che consente agli sviluppatori di gestire le risorse in isolamento da altri team per separare logicamente le risorse. Per creare l'inventario dei tuoi progetti OpenShift, considera quanto segue per ogni progetto:

• Ruoli del cluster e ruoli locali. OpenShift supporta sia i ruoli locali per un progetto OpenShift sia i ruoli a livello di cluster. Valuta se hai creato ruoli cluster e locali per progettare un meccanismo di controllo dell'accesso efficace nell'ambiente di destinazione.
• Associazioni di ruoli, sia per i ruoli del cluster che per i ruoli locali. Agli utenti e ai gruppi vengono concesse le autorizzazioni per eseguire operazioni sui progetti OpenShift assegnando loro associazioni di ruoli. I ruoli possono essere a livello di cluster o locale. Spesso, le associazioni di ruoli locali sono associate a ruoli cluster predefiniti. Ad esempio, l'associazione predefinita del ruolo di amministratore del progetto OpenShift potrebbe essere associata al ruolo di amministratore predefinito del cluster.
• ResourceQuotas. Per limitare il consumo aggregato di risorse, OpenShift consente di definire sia quote a livello di progetto OpenShift sia quote su più progetti OpenShift. Devi valutare il modo in cui vengono mappate a Kubernetes ResourceQuotas e compilare un elenco di tutte le ResourceQuotas di cui hai eseguito il provisioning e configurato nel tuo ambiente OpenShift.

Valutare l'ambiente descrive come valutare le risorse Kubernetes, come ServiceAccounts e PersistentVolume.

Processi di creazione e deployment

Dopo aver raccolto le informazioni sul modello di distribuzione dei servizi e di gestione della piattaforma e sui progetti OpenShift, valuti come stai creando i carichi di lavoro e come ne stai eseguendo il deployment nel tuo ambiente.

Nel tuo ambiente OpenShift esistente, potresti avere lo stesso processo di creazione e deployment per tutti i carichi di lavoro oppure potrebbero essere diversi processi da valutare. Gli artefatti del processo di creazione di un carico di lavoro containerizzato sono immagini container. In un ambiente OpenShift, potresti creare immagini container, archiviarle ed eseguirne il deployment in modi diversi:

• Il processo di creazione delle immagini container viene eseguito completamente al di fuori di OpenShift. Il processo di compilazione può essere basato su passaggi manuali o su una pipeline di integrazione continua automatizzata e deployment continuo (CI/CD) con l'immagine container e i manifest di Kubernetes come prodotto finale.
• Il processo di creazione delle immagini container viene eseguito all'interno di OpenShift. OpenShift supporta diverse opzioni, ad esempio la fornitura di un Dockerfile e di tutti gli artefatti necessari per creare un'immagine container, configurazione di una build da sorgente a immagine, configurazione di build di una pipeline o configurazione di una build personalizzata. Queste strategie di build creano una risorsa BuildConfig che definisce la scelta di creazione, la località degli artefatti di origine, le immagini container di destinazione e gli eventi che possono attivare il processo di creazione delle immagini container.

Dopo aver creato ogni immagine container, la archivia in un Container Registry di cui puoi eseguire il deployment in un secondo momento. Il tuo Container Registry può essere ospitato in OpenShift o all'esterno del tuo ambiente OpenShift. Valuta questo aspetto perché potresti aver bisogno di un sistema simile nell'ambiente di destinazione.

Carichi di lavoro, requisiti e dipendenze

Ogni applicazione OpenShift contiene i seguenti componenti:

• Un oggetto OpenShift DeploymentConfig o un oggetto Kubernetes Deployment. Per ulteriori informazioni sulle differenze tra questi oggetti, consulta Confronto tra Deployment e DeploymentConfig.
• Un servizio Kubernetes per rendere la tua applicazione raggiungibile dai client e una route OpenShift per connettersi a questo servizio Kubernetes dall'esterno del cluster.
• Un elemento OpenShift ImageStream per fornire un'astrazione per fare riferimento alle immagini container. Un oggetto OpenShift ImageStream include una o più immagini container, ciascuna identificata da tag e presenta un'unica vista astratta delle immagini correlate, simile a un repository di immagini container.
• Un elemento OpenShift BuildConfig per creare le immagini container dell'applicazione OpenShift in OpenShift.

A seconda dello scopo dell'applicazione, puoi utilizzare oggetti diversi per definire l'app anziché utilizzare gli oggetti Deployment o DeploymentConfig:

• Definisci le applicazioni batch utilizzando Job o cron job.
• Definire le applicazioni stateful utilizzando gli StatefulSets.
• Se hai carichi di lavoro relativi alle operazioni che devono essere eseguiti su ogni nodo, o essere associati a nodi specifici, puoi definirli utilizzando DaemonSets.

La seguente tabella elenca le specifiche e i parametri più importanti che hai raccolto dalle risorse OpenShift per eseguire la migrazione delle applicazioni nell'ambiente GKE Enterprise di destinazione.

Manifest delle risorse OpenShift di origine	Specifiche e parametri più importanti
Deployment, DeploymentConfig, StatefulSet, Job, cron job	Immagine e repository del container, porta del container, numero di repliche dei pod, ConfigMap, secret, richieste di volumi permanenti, richieste e limiti di risorse, strategia di aggiornamento, nome del servizio StatefulSet, pianificazione dei cron job
ImageStream	Immagine container, criterio pull immagine, repository di immagini container
Horizontal Pod Autoscaler	Criteri di scalabilità automatica
Servizio	Nome host utilizzato per connettersi all'applicazione dall'interno del cluster, indirizzo IP e porta su cui è esposto il servizio, endpoint creati per le risorse esterne
Route	Nome host e percorso della risorsa utilizzati per connettersi all'applicazione dall'esterno del cluster, delle regole di routing, della crittografia e delle informazioni sulla catena di certificati

Valutare l'ambiente descrive come valutare le risorse Kubernetes, ad esempio:

• Altri controller Kubernetes
• Horizontal Pod Autoscaler
• Contesto di sicurezza dei pod
• Carichi di lavoro stateless e stateful
• Archiviazione
• Configurazione e inserimento dei secret
• Ingress
• Logging e monitoraggio

OpenShift 4 ha introdotto il framework degli operatori. Se utilizzi questa versione di OpenShift, potresti aver eseguito il deployment di alcune applicazioni utilizzando gli operatori installati. In questo caso, otterrai l'elenco degli operatori installati e raccogli informazioni per ciascuno di loro sulle istanze Operator di cui è stato eseguito il deployment. Si tratta di risorse personalizzate definite dall'operatore che eseguono il deployment di alcune delle risorse Kubernetes elencate in precedenza.

Oltre a valutare queste risorse, valuti quanto segue:

• Requisiti di connettività di rete dell'applicazione. Ad esempio, i servizi o i pod devono essere esposti a una rete specifica? Deve raggiungere sistemi di backend specifici?
• Vincoli per l'esecuzione dei carichi di lavoro in una località specifica. Ad esempio, eventuali carichi di lavoro o set di dati devono rimanere on-premise per soddisfare requisiti come la latenza nella comunicazione con altri carichi di lavoro, i criteri relativi alla posizione dei dati e la vicinanza agli utenti?

Configurazione dei cluster OpenShift

Successivamente, valuterai i cluster OpenShift. Per completare questa attività, raccogli le seguenti informazioni:

• Versione OpenShift. Le versioni principali di OpenShift nell'ambito di questo documento sono OpenShift 3 e OpenShift 4. Versioni OpenShift diverse potrebbero avere funzionalità diverse. Valuta la versione di OpenShift in esecuzione per sapere se stai utilizzando funzionalità specifiche di OpenShift specifiche per la versione.
• Provider di identità utilizzato per l'autenticazione. Per l'autenticazione, potresti utilizzare il server OAuth integrato e uno o più provider di identità.
• Vincoli del contesto di sicurezza. Valuta i vincoli di contesto di sicurezza di OpenShift che hai definito nei cluster, la loro configurazione e a quali utenti, gruppi e account di servizio sono assegnati.
• Criterio di rete e isolamento. Valuta NetworkPolicy, come hai configurato l'isolamento della rete di pod e la modalità OpenShift SDN che hai configurato nei tuoi cluster.

• Monitoraggio. Valuta i tuoi attuali requisiti di monitoraggio e il modo in cui hai eseguito il provisioning e la configurazione del tuo attuale sistema di monitoraggio per decidere come progettare e implementare una soluzione di monitoraggio nell'ambiente di destinazione. Questa valutazione può aiutarti a determinare se utilizzare una nuova soluzione di monitoraggio o se puoi continuare a utilizzare la soluzione esistente. Molte versioni di OpenShift includono uno stack di monitoraggio basato su Prometheus per monitorare i componenti di sistema, che può essere utilizzato anche per il monitoraggio delle applicazioni. Quando progetti la soluzione di destinazione, considera quanto segue:

  • La soluzione di monitoraggio attualmente in uso nel tuo ambiente OpenShift, ad esempio un Prometheus ospitato da OpenShift, uno stack indipendente di Prometheus-Grafana, Zabbix, InfluxData o Nagios.
  • Modalità di produzione e raccolta delle metriche, ad esempio un meccanismo di tipo pull o push.
  • Dipendenze da qualsiasi componente di cui è stato eseguito il deployment nei cluster OpenShift.
  • La località del sistema di monitoraggio, ad esempio di cui è stato eseguito il deployment in un ambiente cloud o on-premise.
  • Le metriche che stai raccogliendo per i tuoi carichi di lavoro.
  • Eventuali avvisi sulle metriche configurate nel sistema di monitoraggio attuale.

• Logging. Valuta i tuoi attuali requisiti di logging e il modo in cui hai eseguito il provisioning e la configurazione del tuo attuale sistema di logging per decidere come progettare e implementare una soluzione di logging nell'ambiente di destinazione. Questa valutazione può aiutarti a determinare se utilizzare una nuova soluzione di logging o se puoi continuare a utilizzare la soluzione esistente. Molte versioni di OpenShift vengono fornite con una soluzione di logging basata su uno stack Elasticsearch, Fluentd e Kibana (EFK) utilizzato per raccogliere i log dai componenti di sistema. Questa soluzione può essere utilizzata anche per il logging delle applicazioni. Quando progetti la soluzione target, considera quanto segue:

  • Il sistema di logging che stai utilizzando nel tuo ambiente OpenShift, ad esempio uno stack EFK ospitato da OpenShift, uno stack EFK indipendente o Splunk.
  • Dipendenze da qualsiasi componente di cui è stato eseguito il deployment nei cluster OpenShift.
  • L'architettura e la capacità dei componenti di archiviazione dei log.
  • La località del tuo sistema di logging, ad esempio di cui è stato eseguito il deployment in un ambiente cloud o on-premise.
  • I criteri di conservazione e la configurazione dei log.

Valutare l'ambiente descrive come valutare quanto segue:

• Numero di cluster
• Numero e tipo di nodi per cluster
• Considerazioni aggiuntive su logging, monitoraggio e tracciamento
• Risorse Kubernetes personalizzate

Completa la valutazione

Dopo aver creato gli inventari relativi ai tuoi processi e carichi di lavoro OpenShift, completi le altre attività della fase di valutazione in Migrazione a Google Cloud: valutazione e scoperta dei carichi di lavoro.

Pianificazione e costruzione delle basi

Nella fase di pianificazione e creazione, esegui il provisioning e la configurazione dell'infrastruttura e dei servizi che supportano i carichi di lavoro:

1. Creare una gerarchia di risorse.
2. Configurare la gestione di identità e accessi.
3. Configura la fatturazione.
4. Configura la connettività di rete.
5. Rafforza la tua sicurezza.
6. Configura il monitoraggio e gli avvisi.

Questa sezione fornisce informazioni specifiche per creare le basi su GKE Enterprise, basandosi sulle informazioni contenute in Migrazione a Google Cloud: creare le basi.

Prima di creare una base in Google Cloud, leggi la panoramica tecnica di GKE Enterprise per capire come funziona GKE Enterprise e di quali componenti GKE Enterprise potresti aver bisogno. A seconda dei requisiti di carico di lavoro e di località dei dati che hai raccolto nella fase di valutazione, esegui il deployment dei carichi di lavoro su GKE su VMware, cluster GKE su Google Cloud o GKE su AWS. I cluster potrebbero essere distribuiti tra ambienti diversi. Per ulteriori informazioni sulla creazione delle basi per GKE su Google Cloud, consulta Pianificazione e creazione delle basi.

Per creare una base per GKE su VMware, leggi i concetti principali e tieni presente quanto segue durante l'installazione di GKE su VMware:

• Assicurati che il tuo ambiente on-premise soddisfi i requisiti per Anthos GKE On-Prem. Devi fornire una capacità sufficiente nel tuo ambiente VMware vSphere per soddisfare i requisiti dei cluster di amministrazione e dei cluster utente. Questi requisiti dipendono dalla quantità di richieste di risorse dei carichi di lavoro e dal numero di cluster necessari. Hai valutato entrambi gli aspetti nella fase di valutazione.

• Configura la tua rete. Devi configurare la tua rete on-premise per soddisfare i requisiti di connettività di rete delle applicazioni raccolti nella valutazione, oltre ai requisiti di installazione di GKE su VMware. Considera le seguenti esigenze di networking:

  • Networking
  • Bilanciamento del carico
  • Regole firewall
  • Progetti Google Cloud
  • Account di servizio

Per creare le basi per GKE su AWS, scopri di più sui suoi concetti principali, ad esempio architettura GKE su AWS e GKE sullo spazio di archiviazione AWS. Durante l'installazione di GKE su AWS, considera quanto segue:

• Assicurati che i tuoi ambienti Amazon Web Services (AWS) e Google Cloud soddisfino i requisiti per GKE su AWS. GKE su AWS richiede un account (AWS) con accesso da riga di comando e una chiave AWS Key Management Service (KMS) per criptare i secret a livello di applicazione nei cluster. Hai bisogno di Terraform e kubectl.
• Configura l'ambiente AWS. Devi configurare l'ambiente AWS, installare strumenti come AWS Command Line Interface (CLI), configurare le credenziali AWS IAM ed eseguire il provisioning delle risorse nel tuo ambiente AWS, ad esempio una chiave KMS AWS.
• Configurare l'ambiente Google Cloud. Devi configurare il tuo ambiente Google Cloud, creare i progetti e gli account di servizio Google Cloud necessari e configurare IAM.

deployment dei carichi di lavoro

Nella fase di deployment, esegui il deployment dei carichi di lavoro su GKE Enterprise:

1. Esegui il provisioning e la configurazione della piattaforma e degli ambienti di runtime.
2. Esegui la migrazione dei dati dal vecchio ambiente a quello nuovo.
3. Esegui il deployment dei tuoi carichi di lavoro.

Le seguenti sezioni forniscono informazioni specifiche per il deployment dei carichi di lavoro in GKE Enterprise, a partire dalle informazioni riportate in Migrazione a Google Cloud: trasferimento di set di dati di grandi dimensioni, Migrazione a Google Cloud: deployment dei carichi di lavoro e Migrazione a Google Cloud: migrazione da deployment manuali a deployment containerizzati automatizzati.

Esegui il provisioning e la configurazione della piattaforma e degli ambienti di runtime

Prima di eseguire il deployment di qualsiasi carico di lavoro, devi eseguire il provisioning e la configurazione dei cluster GKE Enterprise necessari.

Puoi eseguire il provisioning di cluster GKE su Google Cloud, GKE su cluster VMware o GKE su cluster AWS. Ad esempio, se hai un carico di lavoro di cui devi eseguire il deployment on-premise, devi eseguire il provisioning di uno o più cluster GKE su VMware. Se i tuoi carichi di lavoro non prevedono requisiti di località, esegui il provisioning dei cluster GKE su Google Cloud. In entrambi i casi, gestisci e monitori i cluster con GKE Enterprise. Se hai requisiti multi-cloud, esegui il provisioning di GKE su cluster AWS, insieme ad altri cluster GKE Enterprise.

Innanzitutto, definisci il numero e il tipo di cluster GKE Enterprise di cui hai bisogno. Questi requisiti dipendono in gran parte dalle informazioni raccolte nella fase di valutazione, ad esempio il modello di servizio da implementare e il modo in cui vuoi isolare i diversi ambienti. Se più team di sviluppo condividono attualmente i tuoi cluster OpenShift, devi implementare un modello multi-tenancy su GKE Enterprise:

• Utilizza spazi dei nomi Kubernetes diversi. Il team della piattaforma crea uno spazio dei nomi Kubernetes per ogni progetto OpenShift e implementa un modello di cluster multi-tenancy. Questo modello è molto simile a quello che probabilmente hai adottato nel tuo ambiente OpenShift, quindi potrebbe richiedere una serie di cluster GKE Enterprise simili al numero dei tuoi cluster OpenShift. Se necessario, puoi comunque avere cluster dedicati per ambienti diversi.
• Utilizza cluster GKE Enterprise diversi. Il team dell'infrastruttura fornisce un cluster GKE Enterprise per ogni team di sviluppo, mentre il team della piattaforma gestisce ciascuno di questi cluster. Questo modello potrebbe richiedere più cluster GKE Enterprise rispetto al numero dei tuoi cluster OpenShift, perché offre maggiore flessibilità e isolamento per il tuo sviluppo.
• Utilizzare progetti Google Cloud diversi. Il team dell'infrastruttura crea un progetto Google Cloud per ogni team di sviluppo ed esegue il provisioning dei cluster GKE Enterprise all'interno di quel progetto Google Cloud. Quindi, il team della piattaforma gestisce questi cluster. Questo modello potrebbe richiedere alcuni cluster GKE Enterprise in più rispetto al numero di cluster OpenShift perché offre la massima flessibilità e isolamento ai tuoi team di sviluppo.

Dopo aver deciso il numero di cluster di cui hai bisogno e in quale ambiente eseguirne il provisioning, definisci la dimensione, la configurazione e i tipi di nodi del cluster. Quindi, esegui il provisioning dei cluster e dei pool di nodi, in base ai requisiti dei carichi di lavoro raccolti durante la fase di valutazione. Ad esempio, i carichi di lavoro potrebbero richiedere determinate garanzie di prestazioni e scalabilità, insieme ad altri requisiti, come la necessità di GPU e TPU.

Per ulteriori informazioni sul provisioning e sulla configurazione dei cluster, consulta quanto segue:

• Esegui il provisioning e la configurazione della piattaforma di runtime e degli ambienti per i cluster GKE su Google Cloud.
• Creazione di cluster di amministrazione e utente per GKE su cluster VMware.
• Installazione del cluster di gestione e creazione di un cluster utente per GKE su cluster AWS.

Dopo aver creato i cluster e prima di eseguire il deployment di qualsiasi carico di lavoro, configura i seguenti componenti per soddisfare i requisiti raccolti nella fase di valutazione dei progetti OpenShift e dei cluster:

• Gestione di identità e accessi. Puoi configurare la gestione di identità e accessi come descritto in Configurare la gestione di identità e accessi. Puoi eseguire la migrazione a Cloud Identity come provider di identità principale oppure utilizzare Google Cloud Directory Sync per sincronizzare Cloud Identity con un server LDAP o Active Directory esistente. GKE su VMware supporta OpenID Connect (OIDC) per l'autenticazione in base ai cluster utente utilizzando la riga di comando. Consulta la pagina relativa all'autenticazione con OIDC e Google per integrare l'autenticazione a riga di comando con Cloud Identity.
• Monitoraggio. Puoi adattare la tua attuale soluzione di monitoraggio all'ambiente GKE Enterprise di destinazione in base ai tuoi vincoli e requisiti. Se la tua soluzione attuale è ospitata su OpenShift, puoi implementare Cloud Monitoring come descritto nella sezione Creare le basi oppure implementare Prometheus e Grafana con GKE su VMware.
• Logging. Puoi adattare la tua attuale soluzione di logging all'ambiente GKE Enterprise di destinazione in base ai tuoi vincoli e ai tuoi requisiti. Se la tua soluzione attuale è ospitata su OpenShift, puoi implementare Cloud Logging come descritto in Creazione della base - Monitoraggio e avvisi.

Con Config Sync, puoi definire a livello centrale la configurazione delle seguenti risorse in un repository comune conforme a Git e applicare questa configurazione a tutti i cluster, sia on-premise che nel cloud:

• Controllo dell'controllo dell'accesso basato sui ruoli (RBAC). Dopo aver configurato l'autenticazione, puoi implementare i criteri di autorizzazione utilizzando una combinazione di Identity and Access Management e Kubernetes RBAC. Questi criteri soddisfano i requisiti che hai raccolto nella valutazione del progetto OpenShift e nel modello multi-tenancy che hai scelto.
• Quote delle risorse. Puoi applicare quote delle risorse agli spazi dei nomi per assegnare quote ai team di sviluppatori in base alle esigenze.
• Contesto di sicurezza per i tuoi carichi di lavoro. Puoi utilizzare Policy Controller per creare vincoli per applicare la sicurezza dei pod in base ai tuoi requisiti e alla configurazione dei vincoli di contesto di sicurezza di OpenShift raccolti nella fase di valutazione.
• Criterio di rete e isolamento: Puoi implementare l'isolamento di rete richiesto tra spazi dei nomi o carichi di lavoro utilizzando i criteri di rete di Kubernetes.

Per installare Config Sync, consulta Installare Config Sync. Per installare Policy Controller, consulta Installare Policy Controller.

Migrazione dei dati dal vecchio ambiente

Ora puoi eseguire la migrazione dei dati dall'ambiente di origine all'ambiente di destinazione.

Se le tue applicazioni stateful OpenShift ospitano dati su volumi permanenti Kubernetes, esistono diverse strategie per la migrazione dei dati nell'ambiente di destinazione. La scelta della strategia giusta dipende da vari fattori, come i provider di spazio di archiviazione del backend di origine e di destinazione e le località di deployment:

• Affidati alle funzionalità di clonazione, esportazione e importazione dei volumi del tuo fornitore di spazio di archiviazione. Se utilizzi volumi VMware vSphere nel tuo ambiente on-premise ed esegui la migrazione a GKE su VMware, devi clonare i PersistentVolume sottostanti ai dischi virtuali VMDK e montarli come volumi nell'ambiente di destinazione. Se stai eseguendo la migrazione a GKE, import i tuoi dischi virtuali come dischi permanenti di Compute Engine e li utilizzi come volumi permanenti.
• Esegui il backup dei dati dall'ambiente di origine utilizzando strumenti del sistema operativo o di database. Ospita i dati in una posizione temporanea accessibile da entrambi gli ambienti e poi ripristina i dati nell'ambiente di destinazione.
• Utilizza uno strumento di copia remota, come rsync, per copiare i dati dall'ambiente di origine all'ambiente di destinazione.
• Utilizza una soluzione di backup indipendente dallo spazio di archiviazione, come Velero con integrazione restic.

Per maggiori informazioni, consulta Migrazione a Google Cloud: trasferimento di set di dati di grandi dimensioni.

Per ulteriori informazioni sulla migrazione di dati e strategie per gestire l'archiviazione in GKE, consulta Eseguire la migrazione dei dati dal vecchio ambiente al nuovo ambiente e i documenti di GKE sulla configurazione dell'archiviazione.

Con GKE su VMware, puoi scegliere tra diverse opzioni per l'integrazione con sistemi di archiviazione esterni, ad esempio tramite l'archiviazione VMware vSphere, plug-in di volume in-tree di Kubernetes e driver CSI (Container Storage Interface). La scelta dipende dal sistema di archiviazione esterno con cui devi eseguire l'integrazione, dalle modalità di accesso supportate e se hai bisogno del provisioning del volume dinamico.

GKE su AWS esegue automaticamente il deployment del driver CSI per Amazon Elastic Block Store (EBS) e di un spazio di archiviazione predefinito di StorageClass che supporta PersistentVolumeClaim con volumi EBS e StorageClass per altri tipi di volumi EBS. Puoi anche installare driver CSI aggiuntivi e StorageClass personalizzati. Se hai un volume EBS che vuoi importare in GKE su AWS, puoi creare un PersistentVolume da questo.

Esegui il deployment dei carichi di lavoro

Dopo aver eseguito il provisioning del cluster GKE Enterprise e la migrazione dei dati, puoi creare ed eseguire il deployment dei carichi di lavoro. Hai diverse opzioni, dai deployment manuali a quelli completamente automatizzati.

Se devi utilizzare gli operatori per eseguire il deployment di carichi di lavoro che impiegano questo metodo di deployment nel tuo ambiente OpenShift, devi installare l'operatore prima di eseguire il deployment del carico di lavoro. Puoi verificare la disponibilità degli operatori di cui hai bisogno nelle seguenti origini:

• Google Cloud Marketplace
• operatorhub.io
• Sito web di un fornitore di software specifico o repository GitHub

Esegui il deployment manualmente

Se esegui manualmente il deployment dei carichi di lavoro nel tuo ambiente OpenShift, puoi adattare questo processo manuale al nuovo ambiente GKE Enterprise. Ad esempio, puoi tradurre manualmente i manifest delle risorse OpenShift che hai valutato in carichi di lavoro, requisiti e dipendenze nei manifest delle risorse GKE Enterprise corrispondenti.

La tabella seguente estende la tabella nella sezione Carichi di lavoro, requisiti e dipendenze di questo documento e aggiunge informazioni sulle risorse GKE Enterprise di destinazione in cui puoi utilizzarle.

Manifest delle risorse OpenShift di origine	Specifiche e parametri più importanti	Manifest della risorsa GKE Enterprise di destinazione
Deployment, DeploymentConfig, StatefulSet, Job, cron job	Immagine e repository del container, porta del container, numero di repliche dei pod, ConfigMap, secret, PersistentVolumeClaim, richieste di risorse e limiti, strategia di aggiornamento, nome servizio StatefulSet, pianificazione cron job	deployment, StatefulSet, Job, cron job
ImageStream	Immagine container, criterio pull immagine, repository di immagini container	Deployment
Horizontal Pod Autoscaler	Criteri di scalabilità automatica	Horizontal Pod Autoscaler
Servizio	Nome host utilizzato per connettersi all'applicazione dall'interno del cluster, indirizzo IP e porta su cui è esposto il servizio, endpoint creati per le risorse esterne	Servizio
Route	Nome host e percorso della risorsa utilizzati per connettersi all'applicazione dall'esterno del cluster, regole di routing	In entrata

Progettare e implementare un processo di deployment automatizzato

Per creare ed eseguire il deployment dei tuoi carichi di lavoro in modo automatico, progetti e implementi processi di creazione e deployment oppure adatti quelli esistenti a supporto del tuo nuovo ambiente. Se devi eseguire il deployment dei carichi di lavoro in un ambiente ibrido, i processi di deployment devono supportare sia GKE su Google Cloud che GKE su VMware.

Per implementare i processi di creazione e deployment, puoi utilizzare Cloud Build. Se vuoi automatizzare i processi di creazione e deployment, puoi configurare trigger di build o trigger di app GitHub oppure impostare deployment automatizzati dalla console Google Cloud. Se utilizzi vincoli di Policy Controller, puoi verificare i descrittori di Kubernetes e GKE Enterprise in base ai criteri nei job Cloud Build per fornire feedback agli sviluppatori.

Se devi eseguire job di compilazione o archiviare il codice sorgente on-premise, puoi utilizzare GitLab. GitLab offre repository di codice sorgente e una piattaforma di collaborazione, funzionalità CI/CD e un registro di immagini container. Puoi eseguire il deployment di GitLab sui tuoi cluster GKE Enterprise direttamente da Cloud Marketplace oppure utilizzare una delle altre opzioni di installazione disponibili.

Se attualmente utilizzi una delle funzionalità di OpenShift per creare o eseguire il deployment automatico dei tuoi carichi di lavoro, puoi adottare una delle seguenti strategie, in base al tuo processo attuale:

• Pipeline Jenkins. Se utilizzi le pipeline di Jenkins per automatizzare il processo di creazione e deployment, puoi portarla su Cloud Build, utilizzare il tuo ambiente Jenkins esistente o eseguire il deployment di Jenkins in Google Cloud.
• Crea e implementa un Dockerfile e gli artefatti richiesti. Puoi utilizzare Cloud Build per creare immagini container con un Dockerfile o un file di configurazione di compilazione. Se vuoi eseguire le tue build su un cluster on-premise, puoi utilizzare GitLab.
• Build da origine a immagine. In Cloud Build, devi implementare un passaggio preliminare per creare gli artefatti richiesti dall'immagine container risultante. Se il job da origine a immagine crea un'app Python e produce un'immagine container, devi configurare un passaggio di build personalizzato per creare l'app Python, quindi creare l'immagine container. Questo approccio richiede anche di fornire un Dockerfile oppure, se non vuoi fornirlo, puoi utilizzare i buildpack di Google Cloud o Jib per le applicazioni Java.
• Build personalizzate. Puoi creare builder Cloud Build personalizzati come stai facendo ora in OpenShift. Se i tuoi builder personalizzati non utilizzano funzionalità specifiche di OpenShift, potresti essere in grado di usarle così come sono in Cloud Build.

Qualunque sia l'approccio che scegli per la creazione delle immagini container, devi archiviarle in un repository di immagini container. Hai a disposizione le seguenti opzioni:

• Mantieni il tuo repository di immagini container esistente. Se utilizzi un repository di immagini container esterno non in esecuzione su OpenShift e non vuoi ancora eseguire la migrazione, puoi continuare a utilizzare questo repository per archiviare le immagini container.
• Container Registry. Se preferisci un servizio completamente gestito, puoi utilizzare Container Registry per archiviare le tue immagini container. Se hai bisogno di livelli di sicurezza aggiuntivi, puoi gestire autonomamente le chiavi di crittografia di Container Registry, configurare un perimetro sicuro per l'accesso a Container Registry, migliorare la sicurezza della catena di fornitura del software ed eseguire la scansione delle immagini container per individuare vulnerabilità note con Artifact Analysis. Container Registry supporta anche immagini di base gestite gestite da Google come base per le immagini container.
• Repository on-premise. Se devi eseguire la migrazione dal repository attuale perché è ospitato su OpenShift e devi archiviare le immagini container on-premise, puoi scegliere il registro fornito con GitLab.
• Approccio ibrido. Potete combinare le opzioni precedenti per trarre vantaggio dai punti di forza di ognuna. Ad esempio, puoi utilizzare Container Registry come repository principale ed eseguirne il mirroring al tuo repository on-premise. In questo caso, utilizzi le funzionalità di Container Registry e trai vantaggio dall'avere un repository on-premise.

Indipendentemente dalla tua scelta di archiviare le immagini container, devi eseguire il provisioning e configurare le credenziali per i tuoi cluster per accedere al repository di immagini container.

Se devi inviare notifiche sullo stato delle build e delle immagini dei container a utenti o servizi di terze parti, puoi utilizzare Cloud Functions per rispondere agli eventi prodotti da Cloud Build e Container Registry.

Riepilogo della mappatura delle funzionalità da OpenShift a GKE Enterprise

La seguente tabella è un riepilogo di come mappare le funzionalità di GKE Enterprise con quelle che hai utilizzato su OpenShift.

OpenShift	GKE Enterprise
Progetti OpenShift	Spazi dei nomi Kubernetes gestiti centralmente da Config Sync, Autorizzazione Kubernetes RBAC gestita a livello centrale da Config Sync Le quote delle risorse Kubernetes gestite centralmente da Config Sync
OpenShift SDN e isolamento della rete	Criteri di sicurezza della rete Calico, gestiti centralmente da Config Sync
Limitazioni del contesto di sicurezza di OpenShift	Vincoli di Policy Controller
Pipeline OpenShift	Cloud Build Integrazione con Jenkins mediante il plug-in Google Cloud Jenkins GitLab
OpenShift da origine a immagine	Buildpack cloud-native Fiocco
Integrazione dell'identità	Cloud Identity Google Cloud Directory Sync Integrazione OIDC di GKE su VMware

Ottimizzare l'ambiente

L'ottimizzazione è l'ultima fase della migrazione. In questa fase, rendi il tuo ambiente più efficiente di prima. In questa fase, eseguirai più iterazioni di un ciclo ripetibile finché il tuo ambiente non soddisfa i requisiti di ottimizzazione. I passaggi di questo loop ripetibile sono i seguenti:

1. Valutazione dell'ambiente attuale, dei team e del loop di ottimizzazione.
2. Stabilire i requisiti e gli obiettivi di ottimizzazione.
3. Ottimizzazione del tuo ambiente e dei tuoi team.
4. Ottimizzazione del loop di ottimizzazione.

Le seguenti sezioni si basano su Migrazione a Google Cloud: ottimizzazione dell'ambiente.

Valutare l'ambiente attuale, i team e il loop di ottimizzazione

Sebbene la prima valutazione si concentri sulla migrazione dal tuo ambiente attuale a GKE Enterprise, questa valutazione è personalizzata per la fase di ottimizzazione.

Definisci i tuoi requisiti di ottimizzazione

Per i requisiti di ottimizzazione di GKE su Google Cloud, rivedi i requisiti di ottimizzazione definiti nella sezione Ottimizzare l'ambiente.

Esamina i seguenti requisiti di ottimizzazione per il tuo ambiente GKE Enterprise:

• Inizia a eseguire il deployment dei carichi di lavoro in un ambiente serverless. Se hai bisogno di ridurre il carico sui tuoi team operativi, puoi iniziare a utilizzare piattaforme serverless completamente gestite come Cloud Run e Cloud Run for Anthos.
• Modernizza i processi di deployment. Migrazione a Google Cloud: deployment dei carichi di lavoro descrive i tipici processi di deployment end-to-end e come modernizzare i processi esistenti. Se vuoi modernizzare i processi di deployment esistenti o se vuoi progettarne di nuovi, consulta Migrazione a Google Cloud: migrazione dai deployment manuali ai deployment automatizzati e containerizzati per indicazioni.
• Esegui il deployment con Spinnaker. Se devi implementare la logica di deployment, ad esempio deployment canary e deployment blu/verde, per aumentare l'affidabilità dell'ambiente e ridurre l'impatto per gli utenti, puoi utilizzare Spinnaker. Per utilizzare Spinnaker su Google Cloud, devi installarlo. Successivamente, implementerai i processi di deployment con Spinnaker. Ad esempio, puoi registrare i cluster GKE esistenti in Spinnaker, abilitare il supporto di Kustomize per Spinnaker o implementare pipeline di distribuzione continua con Spinnaker e GKE.
• Implementa una catena di fornitura del software sicura. Per i carichi di lavoro critici per la sicurezza, puoi implementare una catena di fornitura del software sicura nei tuoi cluster GKE Enterprise utilizzando Autorizzazione binaria.
• Passa ad Anthos Service Mesh. Se utilizzi già OpenShift Service Mesh o sei alla ricerca delle funzionalità di gestione del traffico, osservabilità e sicurezza fornite da un mesh di servizi, puoi adottare Anthos Service Mesh. Anthos Service Mesh fornisce una distribuzione di Istio testata e supportata da GKE Enterprise, insieme alle funzionalità di backend gestite da Google per l'osservabilità, la gestione dei certificati mTLS e l'integrazione con Identity Aware Proxy (IAP).

Completa l'ottimizzazione

Dopo aver compilato l'elenco dei requisiti di ottimizzazione, completi le altre attività della fase di ottimizzazione in Migrazione a Google Cloud: ottimizzazione dell'ambiente.

Ricerca di aiuto

Google Cloud offre varie opzioni e risorse per trovare l'aiuto e il supporto necessari per utilizzare al meglio i servizi Google Cloud:

• Risorse self-service. Se non hai bisogno di un'assistenza dedicata, hai a disposizione varie opzioni che puoi utilizzare secondo i tuoi tempi.
• Partner tecnologici. Google Cloud ha collaborato con diverse aziende per aiutarti a utilizzare i nostri prodotti e servizi.
• Servizi professionali di Google Cloud. I nostri servizi professionali possono aiutarti a ottenere il massimo dal tuo investimento in Google Cloud.

Nel Centro di migrazione di Google Cloud sono disponibili altre risorse per facilitare la migrazione dei carichi di lavoro a Google Cloud.

Per ulteriori informazioni su queste risorse, consulta la sezione Guida di ricerca dell'articolo Migrazione a Google Cloud: guida introduttiva.

Passaggi successivi

• Migrazione a Google Cloud: guida introduttiva.
• Scopri di più su GKE Enterprise e Migrazione ai container.
• Scopri come supportare la migrazione con l'espansione del mesh Istio.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.