Migrazione dei container a Google Cloud: migrazione da OpenShift ad Anthos

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo documento ti aiuta a pianificare, progettare e implementare la migrazione da OpenShift ad Anthos. Se eseguito in modo errato, il trasferimento dei carichi di lavoro da un ambiente a un altro può essere un'attività complessa, pianifica ed esegui attentamente la migrazione.

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 in cui viene illustrata la migrazione dei container a Google Cloud:

Questo documento è utile se stai pianificando di eseguire la migrazione da OpenShift in esecuzione in un ambiente di hosting on-premise o privato oppure in un altro cloud provider ad Anthos. Questo documento è utile anche per valutare l'opportunità di eseguire la migrazione e voler 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 mantieni parte del carico di lavoro on-premise o in un ambiente di hosting privato ed esegui la migrazione del resto a Google Cloud.

Per decidere quale ambiente soddisfa le tue esigenze, tieni in considerazione i tuoi requisiti. Ad esempio, puoi concentrarti sull'aumento del valore della tua attività anziché preoccuparti dell'infrastruttura, eseguire la migrazione a un ambiente cloud pubblico e 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 requisiti che devi mantenere alcuni dei tuoi carichi di lavoro al di fuori di Google Cloud, potresti considerare un ambiente ibrido, ad esempio se devi mantenere parte dei tuoi carichi di lavoro nel tuo ambiente attuale per rispettare i criteri e i regolamenti sulla posizione dei dati. In alternativa, puoi implementare una strategia di migrazione migliora e sposta, in cui modernizza innanzitutto i carichi di lavoro, quindi esegui la migrazione a Google Cloud.

Indipendentemente dal tipo di ambiente di destinazione, l'obiettivo di questa migrazione è gestire i carichi di lavoro in esecuzione in tale ambiente utilizzando Anthos. Adottando Anthos, hai accesso a una gamma di servizi, tra cui i seguenti:

  • Gestione multi-cluster per aiutare te e la tua organizzazione a gestire cluster, infrastruttura e carichi di lavoro negli ambienti cloud e on-premise da un'unica posizione.
  • Anthos Config Management per creare una configurazione e dei 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 gestito che semplifica i servizi operativi, la gestione del traffico e la telemetria e la sicurezza 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 Anthos.

Ti consigliamo di valutare questi servizi all'inizio del processo di migrazione, mentre la stai ancora progettando. È più facile adottare questi servizi adesso, anziché modificare i processi e l'infrastruttura in un secondo momento. Puoi iniziare a utilizzare immediatamente questi servizi o quando tutto è pronto per modernizzare i tuoi carichi di lavoro.

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

  1. Valutare e scoprire i tuoi carichi di lavoro.
  2. Pianificazione e costruzione di una base.
  3. Deployment dei carichi di lavoro.
  4. Ottimizzare l'ambiente.

Il seguente diagramma illustra il percorso del percorso di migrazione.

Percorso di migrazione in quattro fasi.

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

Valutare e scoprire i tuoi carichi di lavoro

Nella fase di valutazione, stabilisci i requisiti e le dipendenze per eseguire la migrazione ai carichi di lavoro da OpenShift ad Anthos:

  1. Crea un inventario completo dei tuoi processi e delle tue app.
  2. Classifica i processi e le app in base alle loro proprietà e dipendenze.
  3. Forma 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 prima i carichi di lavoro di cui vuoi eseguire la migrazione.

Le seguenti sezioni si basano sulla migrazione a Google Cloud: valutazione e scoperta dei carichi di lavoro, ma forniscono informazioni specifiche per valutare i carichi di lavoro di cui vuoi eseguire la migrazione da OpenShift ad Anthos.

Crea i tuoi inventari

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

  • Modello di distribuzione dei servizi e gestione delle piattaforme
  • Progetti OpenShift
  • Processo di creazione e deployment
  • Carichi di lavoro, requisiti e dipendenze
  • Configurazione dei cluster OpenShift

Modello di distribuzione dei servizi e gestione delle piattaforme

Per eseguire la migrazione dei carichi di lavoro da OpenShift ad Anthos, valuta l'attuale modello di distribuzione dei servizi e gestione della piattaforma dell'ambiente OpenShift. Questo modello probabilmente riflette la struttura e le esigenze attuali della tua organizzazione. Se ritieni che il modello attuale non soddisfi le esigenze dell'organizzazione, puoi utilizzarla per migliorare il modello.

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

  • Sviluppo di applicazioni e deployment, inclusi tutti gli utenti di OpenShift, in genere i team di sviluppo o di rilascio dei carichi di lavoro.
  • Gestione delle piattaforme OpenShift, tra cui 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 e gestione dei cluster di OpenShift, incluse l'installazione, l'upgrade e la scalabilità dei cluster.
  • 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 gestione della piattaforma può essere costituito dai seguenti team:

  • Il team di sviluppo Questo team sviluppa carichi di lavoro e li esegue il deployment su OpenShift. Quando si tratta di 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 questo team 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, in genere denominata amministratore di cluster OpenShift. Questo team configura i modelli di progetto OpenShift per i diversi team di sviluppo e, in ambienti più gestiti, crea progetti OpenShift. Questo team assegna anche ruoli e autorizzazioni, configura i contesti di sicurezza e il controllo dell'accesso basato sui ruoli (RBAC), definisce le quote per le risorse e gli oggetti di calcolo e definisce le strategie di build e deployment. Denominati anche team DevOps o team middleware, se gestiscono configurazioni middleware e server di 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, spazio di archiviazione, networking, piattaforma di virtualizzazione e sistema operativo di base. Questo team è a volte chiamato team del data center o team operativo. Se viene eseguito il deployment di OpenShift in un ambiente cloud pubblico, questo team è responsabile dei servizi IaaS (Infrastructure as a Service) offerti da un provider di servizi cloud pubblici.

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

Progetti OpenShift

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

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

La valutazione dell'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 delle piattaforme e sui progetti OpenShift, puoi valutare 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 carichi di lavoro oppure potrebbero esserci processi diversi 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 e eseguirne il deployment in diversi modi:

Dopo aver creato ogni immagine container, la archivi in un Container Registry che potrai distribuire in un secondo momento. 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:

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 tramite Job o cron job.
  • Definisci le applicazioni stateful utilizzando StatefulSet.
  • Se hai carichi di lavoro relativi alle operazioni che devono essere eseguiti su ogni nodo o essere vincolati a nodi specifici, puoi definirli utilizzando DaemonSet.

La seguente tabella elenca le specifiche e i parametri più importanti che raccogli dalle risorse OpenShift per eseguire la migrazione delle applicazioni all'ambiente Anthos target.

File manifest open source per la risorsa Specifiche e parametri più importanti
Deployment, DeploymentConfig, StatefulSet, Job, cron job Immagine e repository dei container, porta del container, numero di repliche dei pod, ConfigMap, Secret, PersistentVolumeClaim, richieste e limiti di risorse, strategia di aggiornamento, StatefulSet Service Name, pianificazione del cron job
Stream di immagini Immagine container, criterio pull pull, repository di immagini container
Horizontal Pod Autoscaler Criteri di scalabilità automatica
Servizio Nome host utilizzato per la connessione all'applicazione dall'interno del cluster, indirizzo IP e porta sulla quale è esposto il servizio, endpoint creati per risorse esterne
Percorso Nome host e percorso della risorsa utilizzati per connettersi all'applicazione dall'esterno del cluster, regole di routing, crittografia, informazioni sulla catena di certificati

La valutazione dell'ambiente descrive come valutare le risorse Kubernetes, tra cui:

OpenMaiusc 4 ha introdotto il framework degli operatori. Se utilizzi questa versione OpenShift, potresti aver eseguito il deployment di alcune applicazioni tramite gli operatori installati. In questo caso, ottieni l'elenco degli operatori installati e raccogli informazioni per ciascuno di essi sulle istanze operatore di cui è stato eseguito il deployment. Queste istanze sono 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 tuoi servizi o pod devono essere esposti a una rete specifica? Devono raggiungere sistemi di backend specifici?
  • 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 rispettare requisiti quali la latenza nelle comunicazioni con altri carichi di lavoro, i criteri relativi alla posizione dei dati e la vicinanza agli utenti?

Configurazione dei cluster OpenShift

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

  • Versione di OpenShift. Le versioni principali di OpenShift, che rientrano nell'ambito di questo documento, sono OpenShift 3 e OpenShift 4. Versioni OpenShift diverse potrebbero avere funzionalità diverse. Puoi valutare quale versione di OpenShift stai utilizzando per sapere se stai utilizzando funzionalità specifiche della versione di OpenShift.
  • Provider di identità utilizzato per l'autenticazione. Per l'autenticazione, potresti utilizzare il server OAuth integrato e uno o più provider di identità.
  • Vincoli di contesto di sicurezza. Valuta i vincoli di contesto relativi alla sicurezza che hai definito nei tuoi cluster, la loro configurazione e a quali utenti, gruppi e account di servizio sono assegnati.
  • Criterio di isolamento e rete di rete. Valuta NetworkPolicies, come hai configurato l'isolamento di rete dei pod e quale modalità SDN di OpenShift hai configurato nei cluster.
  • Monitoraggio. Valuta i tuoi attuali requisiti di monitoraggio e come hai eseguito il provisioning e la 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 OpenShift includono uno stack di monitoraggio basato su Prometheus per monitorare i componenti del sistema, che possono essere utilizzati anche per il monitoraggio delle applicazioni. Quando progetti la tua soluzione target, considera quanto segue:

    • La soluzione di monitoraggio che stai utilizzando nel tuo ambiente OpenShift, ad esempio uno Prometheus ospitato da OpenShift, uno stack indipendente di Prometheus-Grafana, Zabbix, InfluxData o Nagios.
    • Come vengono prodotte e raccolte le metriche, ad esempio un meccanismo di pull o push.
    • Dipendenze da tutti i componenti di cui è stato eseguito il deployment nel cluster OpenShift.
    • La posizione del tuo sistema di monitoraggio, ad esempio il deployment in un ambiente cloud o on-premise.
    • Le metriche che stai raccogliendo attualmente per i tuoi carichi di lavoro.
    • Qualsiasi avviso sulle metriche configurate nel sistema di monitoraggio attuale.
  • Logging. Valuta i tuoi attuali requisiti di logging e come hai eseguito il provisioning e la configurazione del sistema di logging attuale 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), che viene 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 di destinazione, tieni presente quanto segue:

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

La valutazione dell'ambiente descrive come valutare quanto segue:

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

Completa il test

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

Pianificazione e costruzione degli elementi di base

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. Configura la gestione di identità e accessi.
  3. Configura la fatturazione.
  4. Configurare la connettività di rete.
  5. Rafforza la tua sicurezza.
  6. Configura monitoraggio e avvisi.

Questa sezione fornisce informazioni specifiche per creare le basi di Anthos, basandosi sulle informazioni contenute in Migrazione a Google Cloud: creazione delle basi.

Prima di gettare le basi di Google Cloud, leggi la panoramica tecnica di Anthos per comprendere come funziona Anthos e quali componenti di Anthos potrebbero essere necessari. A seconda dei requisiti per il carico di lavoro e la località dei dati che hai raccolto nella fase di valutazione, esegui il deployment dei tuoi carichi di lavoro su Cluster Anthos su VMware, su Cluster Anthos su Google Cloud o su Cluster Anthos su AWS. I tuoi cluster potrebbero essere distribuiti tra ambienti diversi. Per saperne di più sulla creazione di una base per GKE su Google Cloud, consulta Pianificare e creare le basi.

Per creare una base per i cluster Anthos su VMware, leggi i concetti fondamentali e considera quanto segue durante l'installazione di cluster Anthos su VMware:

Per creare una base per i cluster Anthos su AWS, leggi i suoi concetti fondamentali, come Cluster Anthos sull'architettura AWS e Cluster Anthos sullo spazio di archiviazione AWS. Quando installi i cluster Anthos su AWS, tieni presente quanto segue:

deployment dei carichi di lavoro

Nella fase di deployment, esegui il deployment dei tuoi carichi di lavoro su Anthos:

  1. Provisioning e configurazione della piattaforma e degli ambienti di runtime.
  2. Esegui la migrazione dei dati da un ambiente precedente a uno nuovo.
  3. Esegui il deployment dei tuoi carichi di lavoro.

Le seguenti sezioni forniscono informazioni specifiche per il deployment dei carichi di lavoro in Anthos, sulla base delle 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 dai deployment manuali ai deployment automatizzati e containerizzati.

Provisioning e configurazione della piattaforma di runtime e degli ambienti

Prima di poter eseguire il deployment di qualsiasi carico di lavoro, esegui il provisioning e configura i cluster Anthos necessari.

Puoi eseguire il provisioning di cluster GKE su Google Cloud, Cluster Anthos su cluster VMware o cluster Anthos 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 Anthos sui cluster VMware. Se i tuoi carichi di lavoro non hanno requisiti di località, esegui il provisioning dei cluster GKE su Google Cloud. In entrambi i casi, gestisci e monitori i cluster con Anthos. Se disponi di requisiti multi-cloud, esegui il provisioning di cluster Anthos sui cluster AWS, insieme ad altri cluster Anthos.

Prima di tutto, definisci il numero e il tipo di cluster Anthos 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 diversi ambienti. Se più team di sviluppo stanno attualmente condividendo i tuoi cluster OpenShift, devi implementare un modello multitenancy su Anthos:

  • Utilizza diversi spazi dei nomi di Kubernetes. Il team della piattaforma crea uno spazio dei nomi Kubernetes per ogni progetto OpenShift e implementa un modello multi-tenancy del cluster. Questo modello è molto simile a quello che probabilmente hai adottato nel tuo ambiente OpenShift, pertanto potrebbe richiedere un numero di cluster Anthos simile al numero di cluster OpenShift. Se necessario, puoi comunque avere cluster dedicati per diversi ambienti.
  • Utilizza diversi cluster Anthos. Il team dedicato all'infrastruttura fornisce un cluster Anthos per ogni team di sviluppo e il team della piattaforma gestisce ciascuno di questi cluster. Questo modello potrebbe richiedere un numero di cluster Anthos 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 Anthos all'interno di tale progetto Google Cloud. Il team della piattaforma gestisce quindi questi cluster. Questo modello potrebbe richiedere alcuni cluster Anthos in più rispetto al numero di cluster OpenShift, in quanto offre la massima flessibilità e 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 cluster del cluster. Quindi esegui il provisioning dei cluster e dei pool di nodi, in base ai requisiti del carico di lavoro raccolti durante la fase di valutazione. Ad esempio, i 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, vedi quanto segue:

Dopo aver creato i cluster e prima di eseguire il deployment di un carico di lavoro, configura i seguenti componenti in modo che soddisfino i requisiti raccolti nella fase di valutazione dei progetti OpenShift e dei cluster:

Utilizzando Anthos Config Management, 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 dell'accesso basato sui ruoli (RBAC). Dopo aver configurato l'autenticazione, puoi implementare i tuoi criteri di autorizzazione utilizzando una combinazione di Identity and Access Management e Kubernetes RBAC. Questi criteri soddisfano i requisiti raccolti nella valutazione del progetto OpenShift e nel modello multitenancy scelto.
  • Quote delle risorse. Puoi applicare quote di risorsa a spazi dei nomi per assegnare quote ai team di sviluppatori in base alle tue esigenze.
  • Contesto di sicurezza per i carichi di lavoro. Puoi utilizzare Policy Controller di Anthos Config Management per creare vincoli per applicare la sicurezza dei pod in base ai tuoi requisiti e alla configurazione dei vincoli di contesto della sicurezza di OpenShift raccolti nella fase di valutazione.
  • Criterio di isolamento e rete di rete. Puoi implementare l'isolamento di rete richiesto tra spazi dei nomi o carichi di lavoro utilizzando i criteri di rete di Kubernetes.

Per utilizzare Anthos Config Management, devi installarlo, insieme a Policy Controller.

Esegui la migrazione dei dati dall'ambiente precedente

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

Se le applicazioni stateful OpenShift ospitano dati sui volumi permanenti di 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 archiviazione di backend di origine e di destinazione e le località di deployment:

  • Affidati alle capacità di clonazione, esportazione e importazione del volume del tuo provider di archiviazione. Se utilizzi volumi vSphere di VMware nel tuo ambiente on-premise e stai eseguendo la migrazione ad cluster Anthos su VMware, clona i dischi permanenti VMDK sottostanti e montali come volumi nel tuo ambiente di destinazione. Se stai eseguendo la migrazione a GKE, importi i tuoi dischi virtuali come dischi permanenti di Compute Engine e utilizzali come volumi permanenti.
  • Esegui il backup dei dati dall'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, ad esempio Velero con integrazione permanente.

Per ulteriori informazioni, consulta la pagina Migrazione a Google Cloud: Trasferimento di set di dati di grandi dimensioni.

Per ulteriori informazioni sulla migrazione dei dati e sulle strategie di gestione dell'archiviazione in GKE, consulta Eseguire la migrazione dei dati dall'ambiente precedente al nuovo ambiente e la documentazione di GKE sulla configurazione dello spazio di archiviazione. Se hai intenzione di modernizzare i carichi di lavoro per applicare un'architettura di microservizi o se l'hai già adottata, vedi Migrazione di un'applicazione monolitica ai microservizi su GKE.

Con i cluster Anthos su VMware, puoi scegliere tra diverse opzioni per l'integrazione con sistemi di archiviazione esterni, ad esempio tramite l'archiviazione VMware vSphere, i plug-in di volumi integrati in Kubernetes e i driver Container Storage Interface (CSI). La scelta dipende dal sistema di archiviazione esterno che devi integrare, dalle modalità di accesso supportate e dal provisioning dinamico del volume.

I cluster Anthos su AWS eseguono automaticamente il deployment del driver CSI per Amazon Elastic Block Store (EBS) e di un StorageClass predefinito che supporta PersistentVolumeClaim con volumi EBS e StorageClass per altri tipi di volume EBS. Puoi anche installare driver CSI aggiuntivi e Classi Storage personalizzate. Se hai un volume EBS da importare nei cluster Anthos su AWS, puoi creare un PersistentVolume da questo.

Esegui il deployment dei tuoi carichi di lavoro

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

Se devi utilizzare gli operatori per eseguire il deployment dei carichi di lavoro che utilizzano questo metodo di deployment nell'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 fonti:

Deployment manuale

Se esegui manualmente il deployment dei carichi di lavoro nel tuo ambiente OpenShift, puoi adattare questo processo di deployment manuale al nuovo ambiente Anthos. Ad esempio, puoi tradurre manualmente i manifest delle risorse OpenShift valutati in carichi di lavoro, requisiti e dipendenze ai manifest delle risorse Anthos corrispondenti.

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

File manifest open source per la risorsa Specifiche e parametri più importanti Manifest di risorse Anthos 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 e limiti di risorse, aggiornamento della strategia, StatefulSet Service Name, pianificazione del cron job Deployment, StatefulSet, Job, cron job
Stream di immagini Immagine container, criterio pull pull, repository di immagini container Deployment
Horizontal Pod Autoscaler Criteri di scalabilità automatica Horizontal Pod Autoscaler
Servizio Nome host utilizzato per la connessione all'applicazione dall'interno del cluster, indirizzo IP e porta sulla quale è esposto il servizio, endpoint creati per risorse esterne Servizio
Percorso Nome host e percorso della risorsa utilizzati per la connessione all'applicazione dall'esterno del cluster, regole di routing In entrata

Progettare e implementare un processo di deployment automatico

Per creare ed eseguire automaticamente il deployment dei tuoi carichi di lavoro, devi progettare e implementare i processi di build e deployment o adattare quelli esistenti per supportare il nuovo ambiente. Se devi eseguire il deployment dei carichi di lavoro in un ambiente ibrido, i processi di deployment devono supportare sia i cluster GKE su Google Cloud che Anthos su VMware.

Per implementare i processi di compilazione e deployment, puoi utilizzare Cloud Build. Se vuoi automatizzare i processi di compilazione e deployment, puoi configurare trigger di build o trigger di app GitHub o configurare deployment automatizzati da Google Cloud Console. Se utilizzi vincoli di controller dei criteri, puoi controllare i descrittori Kubernetes e Anthos in base ai criteri nei job di 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, funzionalità CI/CD e un registro di immagini container. Puoi eseguire il deployment di GitLab sui tuoi cluster Anthos direttamente da Cloud Marketplace oppure utilizzare una delle altre opzioni di installazione disponibili.

Se al momento utilizzi una delle strutture OpenShift per creare i tuoi carichi di lavoro o eseguirne il deployment automatico, puoi adottare una delle seguenti strategie, in base al processo attuale:

  • Jenkins Pipelines. Se utilizzi le pipeline Jenkins per automatizzare il processo di compilazione e deployment, puoi trasferire la tua pipeline a 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 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 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 container. Questo approccio richiede anche che tu fornisca un Dockerfile o, se non vuoi fornirne uno, puoi utilizzare i build cloud cloud-native o Jib per le applicazioni Java.
  • Build personalizzate. Puoi creare builder Cloud Build personalizzati come fai ora in OpenShift. Se i tuoi builder personalizzati non utilizzano funzionalità specifiche di OpenShift, potresti essere in grado di usarle come in Cloud Build.

Qualsiasi sia l'approccio scelto per la creazione delle immagini container, devi archiviarle in un repository immagine container. Hai le seguenti opzioni:

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 tue build e delle tue immagini 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à di OpenShift to Anthos

La seguente tabella è un riepilogo di come mappare le funzionalità di Anthos a quelle che hai utilizzato su OpenShift.

OpenShift Anthos
Progetti OpenShift
  • Spazi dei nomi Kubernetes gestiti centralmente da Anthos Config Management
  • Autorizzazione Kubernetes RBAC gestita centralmente da Anthos Config Management
  • Quote delle risorse Kubernetes che sono gestite centralmente da Anthos Config Management
OpenShift SDN e isolamento di rete
  • Criteri di sicurezza della rete Calico gestiti centralmente da Anthos Config Management
vincoli del contesto di sicurezza OpenShift
  • Vincoli del controller dei criteri di gestione della configurazione di Anthos
Pipeline OpenShift
  • Cloud Build
  • Integrazione con Jenkins mediante il plug-in Jenkins di Google Cloud
  • GitLab
OpenShift da immagine a immagine
  • Buildpack cloud-native
  • Fiocco
Integrazione di identità
  • Cloud Identity
  • Google Cloud Directory Sync
  • Integrazione di cluster Anthos su VMware OIDC

Ottimizzazione dell'ambiente

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

  1. Valutare il tuo ambiente attuale, i tuoi team e il tuo ciclo di ottimizzazione.
  2. Definizione dei requisiti e degli obiettivi di ottimizzazione.
  3. Ottimizzazione dell'ambiente e dei tuoi team.
  4. Regolazione del loop di ottimizzazione.

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

Valuta il tuo ambiente attuale, i tuoi team e il tuo ciclo di ottimizzazione

Mentre la prima valutazione si concentra sulla migrazione dal tuo ambiente attuale ad Anthos, questa valutazione è personalizzata per la fase di ottimizzazione.

Definire i requisiti di ottimizzazione

Per i requisiti di ottimizzazione di GKE su Google Cloud, consulta i requisiti di ottimizzazione stabiliti in Ottimizzazione dell'ambiente.

Consulta i seguenti requisiti di ottimizzazione per il tuo ambiente Anthos:

Completa l'ottimizzazione

Dopo aver compilato l'elenco dei requisiti di ottimizzazione, devi completare il resto delle attività della fase di ottimizzazione in Migrazione a Google Cloud: ottimizzazione dell'ambiente.

Trovare assistenza

Google Cloud offre varie opzioni e risorse per trovare l'assistenza e l'assistenza necessarie per utilizzare al meglio i servizi Google Cloud:

  • Risorse self-service. Se non hai bisogno di assistenza dedicata, hai a disposizione diverse opzioni che puoi utilizzare secondo i tuoi tempi.
  • Partner tecnologici. Google Cloud ha collaborato con diverse società 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.

Sono disponibili altre risorse per aiutare a eseguire la migrazione dei carichi di lavoro in Google Cloud nel Google Cloud Migration Center.

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

Passaggi successivi