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 questa operazione non è corretta, spostare i carichi di lavoro da un ambiente all'altro può risultare impegnativo, 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, vedi Migrazione a Google Cloud: scegliere il 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 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 o in un altro cloud provider, a GKE Enterprise. Questo documento è utile anche se stai valutando l'opportunità di eseguire la migrazione e vuoi scoprire come potrebbe essere. 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 ed esegui la migrazione del resto su Google Cloud.

Per decidere quale ambiente è adatto alle tue esigenze, considera i tuoi requisiti. Ad esempio, puoi concentrarti sull'aumento del valore della tua attività, anziché 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. In caso di requisiti, come la conservazione di alcuni carichi di lavoro al di fuori di Google Cloud, ti consigliamo di utilizzare un ambiente ibrido, ad esempio se devi mantenere parte dei 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 migliorare e spostare, in cui devi prima modernizzare i carichi di lavoro in loco, quindi eseguire la migrazione a Google Cloud.

Indipendentemente 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 cluster, infrastruttura e carichi di lavoro in ambienti cloud e on-premise da un'unica posizione.
• 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.
• Cloud 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.
• Knative serving per supportare i carichi di lavoro serverless nel tuo ambiente GKE Enterprise.

Ti consigliamo di valutare questi servizi nelle prime fasi del processo di migrazione, mentre è ancora in fase di progettazione. Ora è più facile adottare questi servizi, anziché modificare i processi e l'infrastruttura in un secondo momento. Puoi iniziare a utilizzare questi servizi immediatamente o quando è tutto pronto per modernizzare i tuoi carichi di lavoro.

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

1. Valutazione e rilevamento dei carichi di lavoro.
2. Pianificare e costruire le basi.
3. Deployment dei carichi di lavoro.
4. Ottimizzazione dell'ambiente.

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

Questo documento si basa sui concetti trattati in Migrazione dei container in Google Cloud: migrazione di Kubernetes a GKE, pertanto sono presenti link a questo documento, ove appropriato.

Valutazione e rilevamento dei carichi di lavoro

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

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

Le sezioni seguenti si basano su Migrazione a Google Cloud: valutazione e rilevamento 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.

Creare gli inventari

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

• Modello di distribuzione 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 distribuzione dei servizi e gestione della piattaforma

Per eseguire la migrazione dei carichi di lavoro da OpenShift a GKE Enterprise, devi valutare l'attuale modello di distribuzione dei servizi e di gestione della piattaforma del tuo ambiente OpenShift. È probabile che questo modello rifletta la tua struttura organizzativa e le tue esigenze attuali. Se ti rendi conto che il modello attuale non soddisfa le esigenze dell'organizzazione, puoi utilizzare questa migrazione come opportunità per migliorare il modello.

Innanzitutto, raccogli informazioni sui team responsabili dei seguenti aspetti:

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

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

• Il team di sviluppo. Questo team sviluppa i carichi di lavoro e ne esegue il deployment su OpenShift. In ambienti di produzione complessi, il team che esegue il deployment dei carichi di lavoro potrebbe essere diverso dal team di sviluppo. Per semplicità in questo documento, consideriamo che faccia parte del team di sviluppo. Negli 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 indicati come amministratori di cluster OpenShift. Questo team configura i modelli di progetto OpenShift per diversi team di sviluppo e, in ambienti più gestiti, crea progetti OpenShift. Inoltre, assegna 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 le strategie di build e deployment. A volte sono definiti team DevOps o team middleware se gestiscono le configurazioni middleware e server delle applicazioni per gli sviluppatori. Il team della piattaforma e il team dell'infrastruttura potrebbero essere coinvolti anche in attività di gestione dei cluster OpenShift di basso livello, come l'installazione e l'upgrade del software, la scalabilità del cluster e la gestione della capacità.
• Il team dell'infrastruttura. Questo team gestisce l'infrastruttura sottostante che supporta l'ambiente OpenShift. Ad esempio, sono responsabili di server, archiviazione, networking, piattaforma di virtualizzazione e sistema operativo di base. Questo team a volte è definito team del data center o team operativo. Se OpenShift viene implementato in un ambiente cloud pubblico, questo 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 oppure per isolare diverse zone di rete e sicurezza, come zone interne e zone demilitarizzate.

Progetti OpenShift

Un progetto OpenShift è uno spazio dei nomi Kubernetes con annotazioni aggiuntive che consentono agli sviluppatori di gestire le risorse in modo isolato rispetto ad altri team per separarle logicamente. Per creare l'inventario dei tuoi progetti OpenShift, considera quanto segue per ogni progetto:

• Ruoli dei cluster e ruoli locali. OpenShift supporta sia i ruoli locali di un progetto OpenShift sia i ruoli a livello di cluster. Devi valutare se hai creato cluster e ruoli 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 a livello locale. Spesso le associazioni di ruoli locali sono associate a ruoli del cluster predefiniti. Ad esempio, l'associazione predefinita del ruolo di amministratore del progetto OpenShift potrebbe essere associata al ruolo predefinito di amministratore del cluster.
• ResourceQuotas. Per limitare il consumo aggregato di risorse, OpenShift consente di definire sia le quote a livello di progetto OpenShift sia le quote in più progetti OpenShift. Devi valutare il modo in cui vengono mappate a Kubernetes ResourceQuotas e compilare un elenco di tutte le ResourceQuote di cui hai eseguito il provisioning e configurato nel tuo ambiente OpenShift.

Nella sezione Valutazione dell'ambiente viene descritto come valutare le risorse Kubernetes, come ServiceAccounts e PersistentVolume.

Processi di creazione e deployment

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

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

• 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 automatizzata di integrazione e deployment continuo (CI/CD) che ha l'immagine container e i manifest di Kubernetes come prodotto finale.
• Il processo di creazione dell'immagine container viene eseguito all'interno di OpenShift. OpenShift supporta diverse opzioni, ad esempio fornire un Dockerfile e tutti gli artefatti necessari per creare un'immagine container, configurare una build da origine a immagine, configurare la build di una pipeline o una build personalizzata. Queste strategie di build creano una risorsa BuildConfig che definisce la scelta di edificio, la posizione 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, archiviala in un Container Registry di cui puoi eseguire il deployment in un secondo momento. Il Container Registry può essere ospitato su OpenShift o all'esterno dell'ambiente OpenShift. Valuta questo aspetto perché potresti aver bisogno di un sistema simile nel tuo 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 DeploymentConfigs.
• Un servizio Kubernetes per rendere la tua applicazione raggiungibile dai client e una route OpenShift per connetterti al servizio Kubernetes dall'esterno del cluster.
• Un OpenShift ImageStream per fornire un'astrazione per fare riferimento alle immagini container. Un elemento ImageStream OpenShift include una o più immagini container, ciascuna identificata da tag, e presenta una singola visualizzazione astratta delle immagini correlate, simile a un repository di immagini container.
• Un OpenShift BuildConfig per creare le immagini container di quell'applicazione OpenShift in OpenShift.

A seconda dello scopo dell'applicazione, per definire l'app puoi utilizzare oggetti diversi, anziché 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 correlati alle operazioni che devono essere eseguiti su ogni nodo o devono essere associati a nodi specifici, puoi definirli utilizzando DaemonSets.

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

Manifest della risorsa 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, PersistentVolumeClaim, richieste e limiti delle risorse, strategia di aggiornamento, nome servizio StatefulSet, pianificazione cron job
ImageStream	Immagine container, criterio pull delle immagini, 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 risorse esterne
Route	Nome host e percorso della risorsa utilizzati per connettersi all'applicazione dall'esterno del cluster, regole di routing, crittografia, informazioni sulla catena di certificati

Nella sezione Valutazione dell'ambiente viene spiegato come valutare le risorse Kubernetes come le seguenti:

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

OpenShift 4 ha introdotto l'Operator Framework. Se utilizzi questa versione OpenShift, potresti aver eseguito il deployment di alcune applicazioni utilizzando gli operatori installati. In questo caso, ottieni l'elenco degli operatori installati e raccogli informazioni per ciascuno di essi sulle istanze dell'operatore 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? Devono raggiungere specifici sistemi di backend?
• Vincoli per eseguire i carichi di lavoro in una località specifica. Ad esempio, i carichi di lavoro o i set di dati devono rimanere on-premise per soddisfare requisiti quali 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 tuoi 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. Le diverse versioni di OpenShift potrebbero avere funzionalità diverse. Devi valutare quale versione di OpenShift stai utilizzando per sapere se stai utilizzando funzionalità di OpenShift specifiche della 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 del contesto di sicurezza OpenShift definiti nei cluster, nella 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 quale modalità OpenShift SDN hai configurato nei tuoi cluster.

• Monitoraggio. Valuta gli attuali requisiti di monitoraggio e le modalità di provisioning e configurazione del sistema di monitoraggio attuale 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 tua soluzione target, considera quanto segue:

  • La soluzione di monitoraggio che stai attualmente utilizzando nel tuo ambiente OpenShift, ad esempio un Prometheus ospitato su OpenShift, uno stack Prometheus- Grafana indipendente, Zabbix, InfluxData o Nagios.
  • Il modo in cui le metriche vengono prodotte e raccolte, ad esempio un meccanismo 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 oppure on-premise.
  • Le metriche che stai raccogliendo attualmente per i tuoi carichi di lavoro.
  • Eventuali avvisi sulle metriche configurate nel sistema di monitoraggio attuale.

• Registrazione. Valuta gli attuali requisiti di logging e le modalità di provisioning e configurazione dell'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 OpenShift vengono fornite con una soluzione di logging basata su uno stack Elasticsearch, Fluentd ed 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 tua soluzione target, considera quanto segue:

  • Il sistema di logging attualmente in uso nell'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 sistema di logging, ad esempio di cui è stato eseguito il deployment in un ambiente cloud oppure on-premise.
  • I criteri di conservazione dei log e la configurazione.

Nella sezione Valutazione dell'ambiente viene spiegato 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 processi e ai carichi di lavoro OpenShift, potrai completare le altre attività della fase di valutazione in Migrazione a Google Cloud: valutazione e scoperta dei carichi di lavoro.

Pianificare e costruire le basi

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

1. Creare una gerarchia di risorse.
2. Configura 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 la tua base su GKE Enterprise, basandoti sulle informazioni contenute in Migrazione a Google Cloud: creare gli elementi di base.

Prima di creare una base in Google Cloud, leggi la panoramica tecnica di GKE Enterprise per capire come funziona GKE Enterprise e quali componenti GKE Enterprise potrebbero essere necessari. A seconda dei requisiti relativi al carico di lavoro e alla località dei dati raccolti in fase di valutazione, puoi eseguire il deployment dei carichi di lavoro su Google Distributed Cloud, cluster GKE su Google Cloud o GKE on AWS. I cluster potrebbero essere distribuiti tra diversi ambienti. Per ulteriori informazioni sulla creazione di una base per GKE su Google Cloud, consulta Pianificazione e creazione degli elementi di base.

Per creare una base per Google Distributed Cloud, leggi i suoi concetti principali, quindi considera quanto segue quando installi Google Distributed Cloud:

• 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 del cluster di amministrazione e dei cluster utente. Questi requisiti dipendono dalla quantità di richieste di risorse per i carichi di lavoro e dal numero di cluster di cui hai bisogno. Durante la fase di valutazione, hai valutato entrambi gli aspetti.

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

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

Per creare una base per GKE su AWS, scopri i suoi concetti principali, ad esempio l'architettura di GKE on AWS e l'archiviazione di GKE on AWS. Tieni presente quanto segue durante l'installazione di GKE su AWS:

• 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. Sono necessari Terraform e kubectl.
• Configura l'ambiente AWS. Devi configurare l'ambiente AWS, installare strumenti come l'interfaccia a riga di comando (CLI) di AWS, configurare le credenziali AWS IAM ed eseguire il provisioning di risorse nell'ambiente AWS, ad esempio una chiave KMS AWS.
• Configura 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 carichi di lavoro.

Le sezioni seguenti forniscono informazioni specifiche per il deployment dei carichi di lavoro in GKE Enterprise, basandosi sulle informazioni contenute 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 automatizzati e containerizzati.

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

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

Puoi eseguire il provisioning di cluster GKE su Google Cloud, Google Distributed Cloud o GKE su cluster AWS. Ad esempio, se hai un carico di lavoro di cui devi eseguire il deployment on-premise, esegui il provisioning di uno o più cluster Google Distributed Cloud. Se per i carichi di lavoro non è richiesta la località, esegui il provisioning dei cluster GKE su Google Cloud. In entrambi i casi, puoi gestire e monitorare i cluster con GKE Enterprise. Se hai requisiti multi-cloud, esegui il provisioning di GKE su cluster AWS, insieme ad altri cluster GKE Enterprise.

Per prima cosa, devi definire il numero e il tipo di cluster GKE Enterprise di cui hai bisogno. Questi requisiti dipendono in gran parte dalle informazioni raccolte durante la fase di valutazione, ad esempio il modello di servizio che vuoi implementare e il modo in cui vuoi isolare i diversi ambienti. Se più team di sviluppo condividono 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 assomiglia molto a quello che probabilmente hai adottato nel tuo ambiente OpenShift, quindi potrebbe richiedere un numero di cluster GKE Enterprise simile al numero di cluster OpenShift. Se necessario, puoi comunque avere cluster dedicati per diversi ambienti.
• Utilizza diversi cluster GKE Enterprise. 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 un numero di cluster GKE Enterprise superiore al numero di cluster OpenShift, perché offre maggiore flessibilità e isolamento per lo sviluppo.
• Utilizza diversi progetti Google Cloud. Il team dell'infrastruttura crea un progetto Google Cloud per ogni team di sviluppo ed esegue il provisioning dei cluster GKE Enterprise all'interno del progetto Google Cloud. Il team della piattaforma gestisce quindi questi cluster. Questo modello potrebbe richiedere per alcuni cluster GKE Enterprise più del numero di cluster OpenShift perché offre la massima flessibilità e il massimo isolamento per i tuoi team di sviluppo.

Dopo aver deciso il numero di cluster necessari e l'ambiente in cui eseguirne il provisioning, definisci le dimensioni, la configurazione e i tipi di nodi del cluster. Successivamente, 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 tuoi carichi di lavoro potrebbero richiedere determinate garanzie di prestazioni e scalabilità, insieme a qualsiasi altro requisito, 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 i cluster Google Distributed Cloud.
• 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 un 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. Google Distributed Cloud supporta OpenID Connect (OIDC) per l'autenticazione rispetto ai cluster utente utilizzando la riga di comando. Segui Autenticazione con OIDC e Google per integrare l'autenticazione a riga di comando con Cloud Identity.
• Monitoraggio. Puoi adattare la soluzione di monitoraggio attuale 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 Monitoring come descritto in Creazione degli elementi di base oppure Prometheus e Grafana con Google Distributed Cloud.
• Logging. Puoi adattare la tua soluzione di logging attuale 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 degli elementi di base - Monitoraggio e avvisi.

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

• Controllo 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 RBAC di Kubernetes. Questi criteri soddisfano i requisiti raccolti nella valutazione del progetto OpenShift e il modello multi-tenancy che hai scelto.
• Quote delle risorse. Puoi applicare quote delle risorse agli spazi dei nomi per assegnare le quote ai team di sviluppatori in base alle esigenze.
• Contesto di sicurezza per i carichi di lavoro. Puoi utilizzare Policy Controller per creare vincoli al fine di applicare la sicurezza dei pod in base ai tuoi requisiti e alla configurazione dei vincoli del contesto di sicurezza OpenShift raccolti nella fase di valutazione.
• Criterio di rete e isolamento. Puoi implementare l'isolamento della 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.

Esegui la migrazione dei dati dal tuo ambiente precedente

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

Se le applicazioni stateful OpenShift ospitano dati su volumi permanenti di Kubernetes, esistono diverse strategie per eseguire la migrazione dei dati nell'ambiente di destinazione. La scelta della strategia giusta dipende da vari fattori, come i provider di archiviazione 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 e stai eseguendo la migrazione a Google Distributed Cloud, puoi clonare gli oggetti PersistentVolume sottostanti i dischi virtuali VMDK e montarli come volumi nell'ambiente di destinazione. Se esegui 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 dal tuo ambiente di origine utilizzando strumenti del sistema operativo o strumenti di database. Ospita i dati in una posizione temporanea accessibile da entrambi gli ambienti, quindi 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 ulteriori informazioni, consulta Migrazione a Google Cloud: trasferimento di set di dati di grandi dimensioni.

Per ulteriori informazioni sulla migrazione dei dati e sulle strategie per gestire lo spazio di archiviazione in GKE, vedi Eseguire la migrazione dei dati dal vecchio ambiente al nuovo ambiente e i documenti di GKE sulla configurazione dello spazio di archiviazione.

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

GKE su AWS esegue automaticamente il deployment del driver CSI per Amazon Elastic Block Store (EBS) e di un oggetto StorageClass predefinito che esegue PersistentVolumeClaim con volumi EBS e StorageClass per altri tipi di volumi EBS. Puoi anche installare driver CSI aggiuntivi e classi di archiviazione personalizzate. Se vuoi importare un volume EBS 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 a disposizione diverse opzioni, dai deployment manuali a quelli completamente automatizzati.

Se devi utilizzare gli operatori per eseguire il deployment di carichi di lavoro che utilizzano 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 o repository GitHub specifico di un fornitore di software

Esegui il deployment manualmente

Se esegui manualmente il deployment dei carichi di lavoro nell'ambiente OpenShift, puoi adattare questo processo di deployment 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 relativa a carichi di lavoro, requisiti e dipendenze di questo documento e aggiunge informazioni sulle risorse di GKE Enterprise di destinazione in cui puoi utilizzarle.

Manifest della risorsa 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 di pod, ConfigMap, Secret, PersistentVolumeClaim, richieste e limiti delle risorse, strategia di aggiornamento, nome servizio StatefulSet, pianificazione cron job	Deployment, StatefulSet, Job, cron job
ImageStream	Immagine container, criterio pull delle immagini, 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 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 automaticamente il deployment dei carichi di lavoro, devi progettare e implementare processi di creazione e deployment oppure adatti quelli esistenti a supporto del 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 sia Google Distributed Cloud.

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

Se devi eseguire job di build o archiviare il codice sorgente on-premise, potresti usare 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 strutture OpenShift per creare o eseguire il deployment automatico dei tuoi carichi di lavoro, puoi adottare una delle seguenti strategie, in base al processo attuale:

• Pipeline Jenkins. Se utilizzi le pipeline di Jenkins per automatizzare il processo di creazione e deployment, puoi trasferire la tua pipeline su Cloud Build, utilizzare l'ambiente Jenkins esistente o eseguire il deployment di Jenkins in Google Cloud.
• Build e deployment da un Dockerfile e gli artefatti richiesti. Puoi utilizzare Cloud Build per creare immagini container con un Dockerfile o un file di configurazione della build. Se vuoi eseguire le tue build su un cluster on-premise, puoi usare 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 tuo 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 del container. Questo approccio richiede anche che tu fornisca un Dockerfile o, se non vuoi fornirne uno, puoi utilizzare i buildpack di Google Cloud o Jib per le applicazioni Java.
• Build personalizzate. Puoi creare builder Cloud Build personalizzati come stai facendo adesso in OpenShift. Se i tuoi builder personalizzati non utilizzano funzionalità specifiche di OpenShift, potresti riuscire a utilizzarle così come sono in Cloud Build.

Qualunque sia l'approccio scelto per creare le immagini container, devi archiviarle in un repository di immagini container. Hai a disposizione le seguenti opzioni:

• Mantieni il repository di immagini container esistente. Se utilizzi un repository esterno di immagini container non in esecuzione su OpenShift e non vuoi ancora eseguire la migrazione, puoi continuare a utilizzare questo repository per archiviare le tue immagini container.
• Container Registry. Se preferisci un servizio completamente gestito, puoi utilizzare Container Registry per archiviare le immagini container. Se hai bisogno di livelli di sicurezza aggiuntivi, puoi gestire in autonomia le chiavi di crittografia di Container Registry, configurare un perimetro sicuro per accedere a Container Registry, migliorare la sicurezza della catena di fornitura del software e scansionare le immagini container alla ricerca di vulnerabilità note con Artifact Analysis. Container Registry supporta anche le immagini di base gestite gestite da Google come base per le immagini container.
• Repository on-premise. Se devi eseguire la migrazione del repository attuale perché è ospitato su OpenShift e archiviare le immagini container on-premise, puoi scegliere il registro fornito con GitLab.
• Approccio ibrido. Puoi 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 nel repository on-premise. In questo caso, utilizzerai le funzionalità di Container Registry e potrai comunque trarre 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 consentire ai tuoi cluster di accedere al repository delle immagini container.

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

Riepilogo della mappatura delle funzionalità da OpenShift a GKE Enterprise

La tabella seguente è un riepilogo di come mappare le funzionalità di GKE Enterprise a quelle utilizzate su OpenShift.

OpenShift	GKE Enterprise
Progetti OpenShift	gli spazi dei nomi Kubernetes gestiti centralmente da Config Sync delle autorizzazioni RBAC di Kubernetes, gestite centralmente da Config Sync le quote delle risorse Kubernetes gestite centralmente da Config Sync
OpenShift SDN e isolamento della rete	i criteri di sicurezza della rete di Calico gestiti centralmente da Config Sync
Vincoli del contesto di sicurezza OpenShift	Vincoli di Policy Controller
Pipeline OpenShift	Cloud Build Integrazione con Jenkins mediante il plug-in Jenkins di Google Cloud GitLab
OpenShift dall'origine all'immagine	Buildpack cloud-native Fiocco
Integrazione delle identità	Cloud Identity Google Cloud Directory Sync Integrazione OIDC Google Distributed Cloud

Ottimizzazione dell'ambiente

L'ottimizzazione è l'ultima fase della migrazione. In questa fase, rendi il tuo ambiente più efficiente rispetto a prima. In questa fase, esegui più iterazioni di un loop ripetibile fino a quando l'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 ciclo di ottimizzazione.
2. Stabilire i requisiti e gli obiettivi di ottimizzazione.
3. Ottimizzazione dell'ambiente e dei team.
4. Ottimizzazione del loop di ottimizzazione.

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

Valuta l'ambiente attuale, i team e il ciclo di ottimizzazione

Mentre la prima valutazione si concentra 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 stabiliti in Ottimizzazione dell'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 dei team operativi, puoi iniziare a utilizzare piattaforme serverless completamente gestite come Cloud Run e Knative serving.
• Modernizza i processi di deployment. Migrazione a Google Cloud: il deployment dei carichi di lavoro descrive i processi di deployment end-to-end tipici e come modernizzare i processi esistenti. Se vuoi modernizzare i processi di deployment esistenti o progettarne di nuovi, consulta Migrazione a Google Cloud: migrazione da deployment manuali a deployment automatizzati e containerizzati per indicazioni.
• Esegui il deployment con Spinnaker. Se hai bisogno di implementare una logica di deployment, ad esempio deployment canary e deployment blu/verde per aumentare l'affidabilità del tuo ambiente e ridurre l'impatto per i tuoi utenti, puoi utilizzare Spinnaker. Per utilizzare Spinnaker su Google Cloud, è necessario installarlo. Successivamente, implementerai i processi di deployment con Spinnaker. Ad esempio, puoi registrare i tuoi cluster GKE esistenti in Spinnaker, abilitare il supporto Kustomize per Spinnaker o implementare pipeline di distribuzione continua con Spinnaker e GKE.
• Implementa una catena di fornitura del software sicura. Per 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 a Cloud Service Mesh. Se utilizzi già OpenShift Service Mesh o cerchi le funzionalità di gestione del traffico, osservabilità e sicurezza fornite da un mesh di servizi, puoi adottare Cloud Service Mesh. Cloud Service Mesh fornisce una distribuzione GKE Enterprise testata e supportata di Istio, insieme a funzionalità di backend gestite da Google per osservabilità, gestione dei certificati mTLS e integrazione con Identity Aware Proxy (IAP).

Completa l'ottimizzazione

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

Trovare assistenza

Google Cloud offre varie opzioni e risorse per consentirti di 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 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 Google Cloud. I nostri servizi professionali possono aiutarti a ottenere il massimo dal tuo investimento in Google Cloud.

In Google Cloud Migration Center sono disponibili altre risorse per la migrazione dei carichi di lavoro in Google Cloud.

Per ulteriori informazioni su queste risorse, consulta la sezione Trovare assistenza di Migrazione a Google Cloud: guida introduttiva.

Passaggi successivi

• Migrazione a Google Cloud: introduzione.
• Scopri di più su GKE Enterprise e Migrazione ai container.
• Leggi 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.