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, lo spostamento dei 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 in Google Cloud. Se ti interessa avere una panoramica della serie, guarda Migrazione a Google Cloud: scegliere il percorso di migrazione.

Questo documento fa parte di una serie che illustra la migrazione 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, privato o in un altro cloud che fornisce il provisioning GKE Enterprise Questo documento è utile anche se stai valutando l'opportunità di eseguire voglio vedere come potrebbe essere. L'ambiente di destinazione può essere uno le 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 eseguire la migrazione del resto in Google Cloud.

Per decidere quale ambiente è adatto alle tue esigenze, considera i tuoi requisiti. Per Ad esempio, puoi concentrarti sull'aumento del valore della tua attività anziché preoccuparsi dell'infrastruttura, eseguire la migrazione a un ambiente cloud pubblico e l'outsourcing di 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 è necessario mantenere alcuni carichi di lavoro al di fuori di Google Cloud, prendere in considerazione un ambiente ibrido, ad esempio se devi mantenere dei carichi di lavoro nell'ambiente attuale per rispettare la posizione dei dati norme e regolamenti. In alternativa, puoi implementare migliora e muoviti di migrazione, in cui devi prima modernizzare i carichi di lavoro in loco e poi eseguire la migrazione a Google Cloud.

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

• Gestione multi-cluster per aiutare te e la tua organizzazione a gestire cluster, infrastruttura carichi di lavoro diversi in ambienti cloud e on-premise.
• Configurazione Sync e Policy Controller per creare una configurazione e criteri comuni in tutti dell'infrastruttura e di applicarli sia on-premise che nel cloud.
• Cloud Service Mesh adottare un mesh di servizi completamente gestiti che semplifica i servizi operativi, gestione del traffico, telemetria e protezione delle comunicazioni tra i servizi.
• Autorizzazione binaria per fare in modo 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 della migrazione mentre stai ancora progettando la migrazione. È più facile adottare questi anziché modificare i processi e l'infrastruttura in un secondo momento. Tu puoi iniziare a utilizzare questi servizi immediatamente o quando è tutto pronto per modernizzarti per 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 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, in modo da avere dei link a quel documento, ove opportuno.

Valutazione e rilevamento dei carichi di lavoro

Nella fase di valutazione, stabilisci i requisiti e le dipendenze eseguire 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 i tuoi processi e le tue app in base alle loro proprietà e delle 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 individuazione dei carichi di lavoro, ma forniscono informazioni specifiche per la valutazione dei carichi di lavoro da OpenShift a GKE Enterprise.

Creare gli inventari

Per creare l'inventario dei componenti del tuo ambiente, seguenti:

• 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 OpenShift completamente gestito di Google Cloud. Questo modello probabilmente riflette la tua attuale struttura organizzativa ed esigenze. Se ti rendi conto che il modello attuale non soddisfa alle esigenze della tua organizzazione, puoi utilizzare questa migrazione come un'opportunità per migliorare model.

Innanzitutto, raccogli informazioni sui team responsabili di aspetti:

• lo sviluppo e il deployment di applicazioni, inclusi tutti gli utenti OpenShift, di sviluppo o di rilascio dei carichi di lavoro.
• la gestione della piattaforma OpenShift, inclusa la creazione Progetti OpenShift, assegnare ruoli agli utenti, configurare contesti di sicurezza e configurare CI/CD pipeline di dati.
• Installazione di OpenShift e gestione dei cluster, incluso OpenShift installazione, upgrade, scalabilità dei cluster e gestione della capacità.
• Gestione dell'infrastruttura. Questi team gestiscono server fisici, spazio di archiviazione networking, piattaforma di virtualizzazione e sistemi operativi.

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

• Il team di sviluppo. Questo team sviluppa i carichi di lavoro ed esegue il deployment su OpenShift. Quando ci si occupa di ambienti di produzione complessi, che esegue il deployment dei carichi di lavoro potrebbe essere diverso dal team di sviluppo. Per semplicità in questo documento, consideriamo che questo team faccia parte team di sviluppo. Negli ambienti self-service, il team di sviluppo ha la responsabilità di creare progetti OpenShift.
• Il team della piattaforma. Questo team è responsabile di OpenShift di gestione della piattaforma, generalmente noto come cluster OpenShift Google Workspace for Education. Questo team configura Modelli di progetto OpenShift per diversi team di sviluppo e, in ambienti più gestiti, crea Progetti OpenShift. Questo team assegna anche ruoli e autorizzazioni, e configurare i contesti di sicurezza controllo controllo dell'accesso basato sui ruoli (RBAC), le quote per risorse e oggetti di computing e le quote di build strategie di deployment. A volte è definito team DevOps o come team del middleware, se gestisce il middleware e le configurazioni del server web per gli sviluppatori. Il team della piattaforma e del team dell'infrastruttura potrebbe essere coinvolto anche in un cluster OpenShift di basso livello attività di gestione come l'installazione e l'upgrade del software, la creazione scalabilità e gestione della capacità.
• Il team dell'infrastruttura. Questo team gestisce le risorse che supporta l'ambiente OpenShift. Ad esempio: sono responsabili di server, archiviazione, networking, e il sistema operativo di base. Questo team a volte viene indicato come come team del data center o team operativo. Se il deployment di OpenShift viene eseguito in un ambiente cloud pubblico, questo team è responsabile as a Service (IaaS) offerti da un provider cloud pubblico.

È inoltre importante valutare se disponi di cluster OpenShift dedicati ambienti diversi. Ad esempio, potresti avere ambienti diversi sviluppo, garanzia di qualità e produzione oppure di separare alla rete e alle zone di sicurezza, come le zone interne zone demilitarizzate.

Progetti OpenShift

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

• Ruoli dei cluster e ruoli locali. OpenShift supporta entrambi i ruoli locali di un progetto OpenShift oppure ruoli a livello di cluster. Valuti se hai creato cluster e ruoli locali per progettare un efficace meccanismo di controllo dell'accesso nell'ambiente di destinazione.
• Associazioni di ruoli, entrambe per ruoli cluster e ruoli locali. Agli utenti e ai gruppi sono concesse le autorizzazioni per eseguire operazioni su OpenShift ai progetti assegnando loro associazioni di ruoli. I ruoli possono essere a livello di cluster o locale. Spesso le associazioni di ruoli locali sono associate nei vari ruoli nei cluster. Ad esempio, l'associazione predefinita del ruolo di amministratore del progetto OpenShift potrebbe essere associate al ruolo predefinito di amministratore del cluster.
• ResourceQuotas. Per limitare il consumo aggregato di risorse, OpenShift consente di definire Quote a livello di progetto OpenShift e in più progetti OpenShift. Tu valuti il modo in cui vengono mappati Kubernetes ResourceQuotes, e compilare un elenco di tutte le ResourceQuote di cui hai eseguito il provisioning configurate nell'ambiente OpenShift.

Valutare l'ambiente descrive come valutare le risorse Kubernetes, ad esempio ServiceAccount, e PersistentVolumes.

Processi di creazione e deployment

Dopo aver raccolto informazioni sulla distribuzione dei servizi e sulla gestione della piattaforma, e sui progetti OpenShift, valuti come stai creando il tuo carichi di lavoro con deployment e deployment nel tuo ambiente.

Nel tuo ambiente OpenShift esistente, potresti avere lo stesso edificio per tutti i carichi di lavoro oppure potrebbero esserci processi diversi da valutare. Gli artefatti del processo di creazione per un carico di lavoro containerizzato immagini container. In un ambiente OpenShift, potresti creare un container archiviarle e eseguirne il deployment 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 contiene 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 fornendo una Dockerfile e tutti gli artefatti necessari per creare un'immagine container, configurazione di una build da origine a immagine, la configurazione di una build della pipeline, o la configurazione di una build personalizzata. Queste strategie di creazione creano BuildConfig risorsa che definisce la scelta dell'edificio, la località degli artefatti di origine le immagini container di destinazione e gli eventi che possono attivare il container un processo di creazione di immagini.

Dopo aver creato ogni immagine container, la archivi in un Container Registry che di cui potrai 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 target completamente gestito di Google Cloud.

Carichi di lavoro, requisiti e dipendenze

Ciascuna Applicazione OpenShift contiene i seguenti componenti:

• Un OpenShift DeploymentConfig o un Deployment di Kubernetes . Per ulteriori informazioni sulle differenze tra questi oggetti, vedi Confronto tra Deployment e DeploymentConfig.
• R Servizio Kubernetes per rendere la tua applicazione raggiungibile dai client OpenShift Route per connetterti a quel servizio Kubernetes dall'esterno del cluster.
• Un Stream di immagine OpenShift per fornire un'astrazione che faccia riferimento alle immagini container. Un OpenShift ImageStream include una o più immagini container, ognuna identificata da tag, e presenta una singola vista astratta delle immagini correlate, simile a una di immagini container.
• Un OpenShift BuildConfig per creare le immagini container dell'applicazione OpenShift in OpenShift.

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

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

La tabella seguente elenca le più importanti specifiche e i parametri raccolti dalle risorse OpenShift per eseguire la migrazione 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 container, porta container, numero di repliche di pod, oggetti ConfigMap, Secret, PersistentVolumeClaim, richieste e limiti di 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, IP l'indirizzo e la porta su cui è esposto il servizio, gli endpoint risorse esterne
Route	Nome host e percorso della risorsa utilizzati per la connessione all'applicazione da esterno al cluster, regole di routing, crittografia, catena di certificati informazioni

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 di secret
• Ingress
• Logging e monitoraggio

OpenShift 4 ha introdotto Operator Framework. Se utilizzi questa versione OpenShift, potresti aver eseguito il deployment utilizzando le applicazioni Operatori. In questo caso, ottieni l'elenco degli operatori installati e raccogli informazioni sulle istanze dell'operatore di cui è stato eseguito il deployment. Questi Istanze definite dall'operatore Risorse personalizzate che eseguono il deployment di alcuni Risorse.

Oltre a valutare queste risorse, valuti quanto segue:

• Requisiti di connettività di rete dell'applicazione. Ad esempio: che i tuoi servizi o pod siano esposti a una rete specifica. Possono devono raggiungere sistemi di backend specifici?
• Vincoli per eseguire i carichi di lavoro in una località specifica. Ad esempio: carichi di lavoro o set di dati devono rimanere on-premise per come la latenza nella comunicazione con altri carichi di lavoro, norme relative alla posizione dei dati e alla vicinanza agli utenti?

Configurazione dei cluster OpenShift

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

• Versione OpenShift. Versioni principali di OpenShift nell'ambito di questa procedura sono OpenShift 3 e OpenShift 4. Versioni OpenShift diverse potrebbero avere funzionalità diverse. Valuti quale versione di OpenShift sapere se stai utilizzando un sistema operativo OpenShift specifico le funzionalità di machine learning.
• Provider di identità utilizzato per l'autenticazione. Per l'autenticazione, potrebbe utilizzare server OAuth integrato, e uno o più provider di identità.
• Vincoli del contesto di sicurezza. Valutare OpenShift Vincoli del contesto di sicurezza che hai definito nei tuoi cluster, nella loro configurazione e a quali utenti, gruppi e account di servizio assegnati.
• Criterio di rete e isolamento. Valuta NetworkPolicy, come configurato l'isolamento della rete di pod Modalità SDN OpenShift configurato nei tuoi cluster.

• Monitoraggio. Valuta i tuoi attuali requisiti di monitoraggio e come eseguire il provisioning e la configurazione dell'attuale sistema di monitoraggio per decidere come progettare e implementare una soluzione di monitoraggio nell'ambiente di destinazione. Questo può aiutarti a determinare se utilizzare una nuova soluzione di monitoraggio o se puoi continuare a usare la soluzione esistente. Molti OpenShift includono uno stack di monitoraggio basato Prometeo per monitorare i componenti del sistema, che possono essere utilizzati anche il monitoraggio. Quando progetti la tua soluzione target, considera quanto segue:

  • La soluzione di monitoraggio che stai utilizzando attualmente un ambiente OpenShift, ad esempio un Prometheus ospitato da OpenShift, indipendente Prometheus: Grafana stack, Zabbix InfluxData, o Nagio
  • Il modo in cui le metriche vengono prodotte e raccolte, ad esempio un pull o un meccanismo di spinta.
  • Dipendenze da qualsiasi componente di cui è stato eseguito il deployment nei cluster OpenShift.
  • La posizione del sistema di monitoraggio, ad esempio di cui è stato eseguito il deployment in un ambiente cloud o on-premise.
  • Le metriche che stai raccogliendo attualmente per i tuoi carichi di lavoro.
  • Eventuali avvisi sulle metriche configurate di monitoraggio delle conversioni.

• Registrazione. Valuta i tuoi attuali requisiti di logging e come il provisioning e la configurazione dell'attuale sistema di logging per decidere come progettare e implementare una soluzione di logging nell'ambiente di destinazione. Questo può aiutarti a determinare se utilizzare una nuova soluzione di logging o se puoi continuare a usare la soluzione esistente. Molte versioni OpenShift viene fornita con una soluzione di logging basata su Elasticsearch Fluents e Kibana Stack (EFK) utilizzato per raccogliere i log dai componenti di sistema. Questo soluzione può essere utilizzata anche per il logging delle applicazioni. Quando progetti soluzione target, considera quanto segue:

  • Il sistema di logging attualmente in uso un ambiente OpenShift, ad esempio uno stack EFK ospitato da OpenShift, 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 posizione del sistema di logging, ad esempio di cui è stato eseguito il deployment in una nell'ambiente cloud o on-premise.
  • I criteri di conservazione dei log e la configurazione.

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 OpenShift e carichi di lavoro, completi le altre attività della fase Migrazione a Google Cloud: valutazione e individuazione dei carichi di lavoro.

Pianificare e costruire le basi

Nella fase di pianificazione e creazione, esegui il provisioning e la configurazione e i 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 costruire le fondamenta su GKE Enterprise, basandosi sulle informazioni Migrazione a Google Cloud: creare le basi.

Prima di creare una base in Google Cloud, leggi il Panoramica tecnica di GKE Enterprise per capire come funziona GKE Enterprise e quale GKE Enterprise i componenti necessari. A seconda del carico di lavoro e della località dei dati che hai raccolto nella fase di valutazione, esegui il deployment carichi di lavoro Google Distributed Cloud, attivo Cluster GKE su Google Cloud, o su GKE su AWS. I cluster potrebbero essere distribuiti tra diversi ambienti. Per ulteriori informazioni informazioni sulla creazione di elementi di base per GKE per Google Cloud, consulta Pianifica e costruisci le basi.

Per gettare le basi per Google Distributed Cloud, scopri di più sulle sue concetti principali, e considera quanto segue quando installazione di Google Distributed Cloud:

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

• Configura la tua rete. Devi configurare la rete on-premise soddisfano le esigenze dell'applicazione dei requisiti di connettività di rete raccolti e il test di installazione di Google Distributed Cloud i tuoi requisiti. Considera le seguenti esigenze di networking:

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

Creare le basi per GKE su AWS, scopri di più concetti principali, come Architettura di GKE su AWS e GKE su spazio di archiviazione AWS. Tieni presente quanto segue durante l'installazione di GKE su AWS:

• Assicurati che i servizi Amazon Web Services (AWS) e Google Cloud soddisfano i requisiti requisiti per GKE su AWS. GKE su AWS richiede un account (AWS) con accesso da riga di comando e un AWS Key Management Service (KMS) chiave per criptare i secret a livello di applicazione nei cluster. Ti servono Terraform e kubectl.
• Configura l'ambiente AWS. Devi configurare l'ambiente AWS, di installazione, come Interfaccia a riga di comando (CLI) AWS, configurare le credenziali AWS IAM, ed eseguire il provisioning di risorse nel tuo ambiente AWS, Chiave KMS AWS.
• Configura l'ambiente Google Cloud. Devi configurare tuo ambiente Google Cloud, creano i necessari Configurare i progetti e gli account di servizio Google Cloud.

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 carichi di lavoro in GKE Enterprise, basandoti sulle informazioni 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 dai deployment manuali a deployment automatizzati e containerizzati.

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

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

Puoi eseguire il provisioning di cluster GKE su Google Cloud, Google Distributed Cloud o GKE su cluster AWS. Ad esempio, se devi distribuire un carico di lavoro on-premise, quindi esegui il provisioning più cluster Google Distributed Cloud. Se i carichi di lavoro non hanno alcuna località esegui il provisioning di cluster GKE su Google Cloud. Nel In entrambi i casi, puoi gestire e monitorare i cluster con GKE Enterprise. Se se hai requisiti multi-cloud, devi eseguire il provisioning di GKE su AWS insieme ad altri cluster GKE Enterprise.

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

• Utilizza spazi dei nomi Kubernetes diversi. Il team della piattaforma crea Kubernetes per ogni progetto OpenShift e implementa uno modello multi-tenancy del cluster. Questo modello assomiglia molto a quello che probabilmente hai adottato in OpenShift potrebbe richiedere una serie di cluster GKE Enterprise è simile al numero di cluster OpenShift. Se necessario, puoi di avere comunque cluster dedicati per ambienti diversi.
• Utilizza diversi cluster GKE Enterprise. L'infrastruttura fornisce un cluster GKE Enterprise a ogni team di sviluppo, e il team della piattaforma gestisce ciascuno di questi cluster. Questo modello un numero di cluster GKE Enterprise maggiore rispetto al numero ai cluster OpenShift perché offre maggiore flessibilità e l'isolamento per il tuo sviluppo.
• Utilizza diversi progetti Google Cloud. Il team dell'infrastruttura crea progetto Google Cloud per ogni team di sviluppo e provisioning di cluster GKE Enterprise all'interno del progetto Google Cloud. La piattaforma che gestisce questi cluster. Questo modello potrebbe richiedere il numero di cluster GKE Enterprise superiore a quello perché offre la massima flessibilità e il massimo isolamento per il tuo team di sviluppo.

Dopo aver deciso il numero di cluster necessari e l'ambiente in cui eseguirne il provisioning, devi definire le dimensioni, la configurazione e i tipi di nodi del cluster. Poi eseguire il provisioning di cluster e pool di nodi, in base ai requisiti dei carichi di lavoro raccolti durante la fase di valutazione. Ad esempio, i carichi di lavoro richiedono determinate garanzie di prestazioni e scalabilità, insieme a qualsiasi come la necessità GPU e TPU.

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

• 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 nel Progetti OpenShift e cluster fase di valutazione:

• Gestione di identità e accessi. Puoi configurare l'identità degli accessi, come descritto in Configura la gestione di identità e accessi. Puoi eseguire la migrazione Cloud Identity come provider di identità principale oppure usa Google Cloud Directory Sync per sincronizzare Cloud Identity con un modello LDAP o un server Active Directory. Google Distributed Cloud supporta OpenID Connect (OIDC) per l'autenticazione nei cluster utente mediante la riga di comando. Segui Autenticazione con OIDC e Google per integrare l'autenticazione da riga di comando con Cloud Identity.
• Monitoraggio. Puoi adattare la soluzione di monitoraggio attuale scegli come target l'ambiente GKE Enterprise in base ai tuoi vincoli i tuoi requisiti. Se la tua soluzione attuale è ospitata su OpenShift, puoi implementare Cloud Monitoring come descritto in Costruire le basi oppure puoi implementare Prometheus e Grafana con Google Distributed Cloud.
• Logging. Puoi adattare la soluzione di logging attuale al target l'ambiente GKE Enterprise in base ai tuoi vincoli i tuoi requisiti. Se la tua soluzione attuale è ospitata su OpenShift, puoi implementare Cloud Logging come descritto in Creazione delle basi - Monitoraggio e avvisi.

Utilizzo Config Sync puoi definire centralmente la configurazione delle seguenti risorse in un comune conforme a Git e applicare tale configurazione a tutti i cluster, sia on-premise che nel cloud:

• Controllo controllo dell'accesso basato sui ruoli (RBAC) Dopo la configurazione dell'autenticazione, puoi implementare i criteri di autorizzazione utilizzando una combinazione di Identity and Access Management e RBAC per Kubernetes. Queste norme soddisfano i requisiti che hai raccolto nei Valutazione del progetto OpenShift e ai il modello multi-tenancy scelto da te.
• 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 carichi di lavoro. Puoi utilizzare Policy Controller per creare vincoli a applicare la sicurezza dei pod in base ai tuoi requisiti e ai vincoli del contesto di sicurezza OpenShift configurazione raccolta nella fase di valutazione.
• Criterio di rete e isolamento. Puoi implementare la rete richiesta isolamento tra spazi dei nomi o carichi di lavoro utilizzando Kubernetes Criteri di rete.

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

Esegui la migrazione dei dati dal tuo ambiente precedente

Ora puoi eseguire la migrazione dei dati dall'ambiente di origine all'ambiente di destinazione completamente gestito di Google Cloud.

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

• Affidati alla clonazione, all'esportazione e all'importazione dei volumi del tuo fornitore di spazio di archiviazione le funzionalità di machine learning. Se utilizzi Volumi vSphere VMware nel tuo ambiente on-premise e stai eseguendo la migrazione Google Distributed Cloud, cloni gli oggetti PersistentVolume sottostante VMDK dischi virtuali e montarli come volumi nell'ambiente di destinazione. Se stai eseguendo la migrazione a GKE, import i tuoi dischi virtuali Dischi permanenti di Compute Engine e utilizzale come volumi permanenti.
• Esegui il backup dei dati dall'ambiente di origine utilizzando il sistema operativo strumenti o strumenti di database. Ospita i dati in una posizione temporanea che accessibili da entrambi gli ambienti e poi ripristinando i dati completamente gestito di Google Cloud.
• Utilizzare uno strumento di copia da remoto, come rsync, per copiare i dati dall'ambiente di origine a quello di destinazione.
• Utilizza una soluzione di backup indipendente dallo spazio di archiviazione, come Velero con integrazione restic.

Per ulteriori informazioni, vedi Migrazione a Google Cloud: trasferimento di set di dati di grandi dimensioni.

Per saperne di più sulla migrazione dei dati e sulle strategie per gestire lo spazio di archiviazione in per GKE, consulta Eseguire la migrazione dei dati dal vecchio ambiente a quello nuovo e i documenti di GKE 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 VMware vSphere Storage, plug-in di volume in-tree per Kubernetes, e Interfaccia di Container Storage (CSI). La scelta dipende dal sistema di archiviazione esterno a cui l'integrazione con le modalità di accesso supportate e, se hai bisogno per eseguire il provisioning del volume.

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

Esegui il deployment dei carichi di lavoro

Dopo aver eseguito il provisioning del cluster GKE Enterprise e la migrazione dei dati, per la creazione e il deployment dei carichi di lavoro. Puoi scegliere tra diverse opzioni, dalle impostazioni manuali i deployment quelli completamente automatizzati.

Se devi utilizzare gli operatori per eseguire il deployment di carichi di lavoro che utilizzano questo deployment nell'ambiente OpenShift, è necessario installare l'Operator prima eseguendo il deployment del carico di lavoro. Puoi verificare la disponibilità degli operatori che necessarie nelle seguenti fonti:

• 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 tuo nuovo GKE Enterprise completamente gestito di Google Cloud. Ad esempio, puoi tradurre manualmente la risorsa OpenShift che hai valutato carichi di lavoro, requisiti e dipendenze ai manifest delle risorse GKE Enterprise corrispondenti.

La seguente tabella si estende la tabella nel carichi di lavoro, requisiti e dipendenze di questo documento e aggiunge informazioni sul target le risorse di GKE Enterprise 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 container, porta container, numero di repliche di pod, oggetti ConfigMap, Secret, PersistentVolumeClaim, richieste e limiti di 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, IP l'indirizzo e la porta su cui è esposto il servizio, gli endpoint risorse esterne	Servizio
Route	Nome host e percorso della risorsa utilizzati per connettersi all'applicazione dall'esterno nel cluster, le regole di routing	In entrata

Progettare e implementare un processo di deployment automatizzato

Per creare ed eseguire il deployment dei carichi di lavoro in modo automatico, devi progettare e implementare i processi di creazione e deployment o adatta quelli esistenti per supportare completamente gestito di Google Cloud. Se devi eseguire il deployment dei carichi di lavoro in un ambiente ibrido, di deployment devono supportare sia GKE Google Cloud e 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 Trigger di build o Trigger dell'app GitHub, o configurare i deployment automatici dalla console Google Cloud. Se utilizzi vincoli di Policy Controller, puoi verifica i descrittori Kubernetes e GKE Enterprise in base ai criteri nei job Cloud Build per fornire feedback agli sviluppatori.

Se devi eseguire job di build o archiviare il codice sorgente on-premise, puoi utilizzare GitLab. GitLab offre repository di codice sorgente e una piattaforma di collaborazione, CI/CD e un registro di immagini container. Potresti eseguire il deployment di GitLab di cluster GKE Enterprise direttamente Cloud Marketplace o usare una delle altre opzioni disponibili opzioni di installazione.

Se attualmente utilizzi una delle strutture OpenShift per creare o il deployment automatico dei carichi di lavoro, puoi adottare uno dei seguenti strategie, in base alla procedura corrente:

• Pipeline Jenkins. Se utilizzi le pipeline di Jenkins per automatizzare il processo di build e deployment, puoi trasferire la pipeline Cloud Build, usa il tuo ambiente Jenkins esistente o esegui il deployment Jenkins in Google Cloud
• Build e deployment da un Dockerfile e gli artefatti richiesti. Puoi utilizzare Cloud Build immagini container per la creazione con un Dockerfile o un file di configurazione della build. Se vuoi eseguire le tue build su un cluster on-premise, puoi utilizzare GitLab.
• Build da origine a immagine. In Cloud Build, devi di implementare un passaggio preliminare per creare gli artefatti un'immagine container. 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 crea l'immagine container. Questo approccio richiede anche che tu fornisca un Dockerfile forniscine una, puoi utilizzare Buildpack di Google Cloud o Jib per applicazioni Java.
• Build personalizzate. Puoi Creare builder Cloud Build personalizzati come in OpenShift. Se i tuoi generatori personalizzati non utilizzano specifiche di OpenShift, potresti essere in grado di utilizzarle così come sono in Cloud Build.

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

• Mantieni il repository di immagini container esistente. Se utilizzi un un repository esterno di immagini container non in esecuzione su OpenShift e non è ancora tutto pronto per la migrazione,puoi continuare a utilizzare il repository e archiviare le immagini container.
• Container Registry. Se preferisci un servizio completamente gestito, utilizzare Container Registry per archiviare le immagini container. Se hai bisogno di livelli di sicurezza aggiuntivi, lattina gestire autonomamente 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 eseguire la scansione delle immagini container per verificare la presenza di vulnerabilità note con Analisi degli artefatti. Container Registry supporta anche immagini di base gestite gestiti da Google come base per le immagini container.
• Repository on-premise. Se hai bisogno di abbandonare repository attuale perché è ospitato su OpenShift e devi archiviare per le immagini container on-premise, puoi scegliere registry fornito con GitLab.
• Approccio ibrido. Puoi combinare le opzioni precedenti per trarne vantaggio dai punti di forza di ciascuno. Ad esempio, puoi utilizzare Container Registry come repository principale ed eseguine il mirroring un repository on-premise. In questo caso, utilizzerai Container Registry e traggono vantaggio dall'avere un repository on-premise.

Indipendentemente dalla tua scelta di archiviare le immagini container, devi eseguire il provisioning configura le credenziali per consentire ai tuoi cluster di accedere all'immagine container repository Git.

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

Riepilogo della mappatura delle funzionalità da OpenShift a GKE Enterprise

La tabella seguente è un riepilogo di come mappare GKE Enterprise quelle usate in OpenShift.

OpenShift	GKE Enterprise
Progetti OpenShift	gli spazi dei nomi Kubernetes gestiti centralmente Config Sync le autorizzazioni RBAC di Kubernetes, gestite centralmente Config Sync le quote delle risorse Kubernetes gestite centralmente Config Sync
OpenShift SDN e isolamento della rete	i criteri di sicurezza della rete di Calico, gestiti centralmente 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, per rendere il tuo ambiente più efficiente di prima. In questa fase, eseguire più iterazioni di un loop ripetibile fino a quando soddisfa i requisiti di ottimizzazione. I passaggi di questo loop ripetibile sono come segue:

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 prima valutazione è incentrato sulla migrazione dall'ambiente attuale a GKE Enterprise. questa valutazione è su misura 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 Ottimizzazione dell'ambiente

Esamina quanto segue requisiti per l'ottimizzazione per il tuo ambiente GKE Enterprise.

• Inizia a eseguire il deployment dei carichi di lavoro in un ambiente serverless. Se hai bisogno per ridurre il carico sui team operativi, puoi iniziare a utilizzare tramite piattaforme serverless gestite Cloud Run e Knative serving.
• 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 il deployment esistente o vuoi progettarne di nuovi, fai riferimento Migrazione a Google Cloud: migrazione dai deployment manuali a deployment automatizzati e containerizzati per assistenza.
• Esegui il deployment con Spinnaker. Se devi implementare la logica di deployment, come 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. Per 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 criticità per la sicurezza carichi di lavoro, puoi Implementa una catena di fornitura del software sicura nei tuoi cluster GKE Enterprise Autorizzazione binaria.
• Passa a Cloud Service Mesh. Se stai già utilizzando OpenShift Service Mesh Oppure stai cercando la gestione, l'osservabilità e la sicurezza del traffico, offerte da un mesh di servizi, puoi adottare Cloud Service Mesh. Cloud Service Mesh fornisce un servizio GKE Enterprise testato e supportato distribuzione di Istio, insieme alle funzionalità di backend gestite da Google della osservabilità, gestione dei certificati mTLS, e l'integrazione Identity Aware Proxy (IAP).

Completa l'ottimizzazione

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

Trovare assistenza

Google Cloud offre varie opzioni e risorse per aiutarti a 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 a cui usare 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.

Sono disponibili altre risorse per aiutarti a eseguire la migrazione dei carichi di lavoro in Google Cloud Centro di migrazione di Google Cloud.

Per ulteriori informazioni su queste risorse, consulta trovare assistenza sezione di Migrazione a Google Cloud: introduzione.

Passaggi successivi

• Migrazione a Google Cloud: introduzione.
• Scopri di più su GKE Enterprise e Eseguire la migrazione ai container.
• Scopri come fare supportano la migrazione con l'espansione del mesh Istio.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.