Best practice per la pianificazione

Questo argomento offre consigli per le migrazioni delle applicazioni a Google Kubernetes Engine (GKE) o GKE Enterprise, in base alle migrazioni di applicazioni reali eseguite con Migrate to Containers.

L'interfaccia a riga di comando del client predittivo di Migration Center o l'interfaccia a riga di comando mcdc è uno strumento che utilizzi per determinare l'idoneità del carico di lavoro della VM per la migrazione a un contenitore.

Carichi di lavoro consigliati

Migrate to Containers è consigliato per determinati tipi di carichi di lavoro Linux e Windows, elencati di seguito.

Idoneo

Linux

Le applicazioni Linux adatte alla migrazione utilizzando Migrate to Containers includono le seguenti architetture di applicazioni:

• Server web/delle applicazioni
• Middleware di logica di business (ad esempio Tomcat)
• Stack multi-VM e multilivello (ad esempio LAMP)
• Database di piccole/medie dimensioni (ad esempio MySQL e PostgreSQL)

Inoltre, le applicazioni più adatte alla migrazione con Migrate to Containers hanno le seguenti caratteristiche operative:

• Carichi di lavoro con duty cycle basso e intermittenti
• Ambienti di laboratorio per sviluppo, test e formazione
• Servizi sempre attivi e a basso carico

In generale, la maggior parte dei carichi di lavoro Linux è compatibile con la migrazione, ad eccezione di quelli elencati esplicitamente di seguito nella sezione Non è una buona scelta.

Windows

Le applicazioni Windows adatte alla migrazione con Migrate to Containers includono i carichi di lavoro che soddisfano tutte le seguenti caratteristiche:

• IIS 7 o versioni successive, ASP.NET con .NET Framework 3.5 o versioni successive
• Livelli web e di logica
• WS2008 R2 o versioni successive

Supporto del sistema operativo

Migrate to Containers è compatibile con i seguenti sistemi operativi VM.

Non è la scelta migliore

Linux

Per Linux, le applicazioni e i server non adatti alla migrazione con Migrate to Containers includono:

• Database in memoria di grandi dimensioni e ad alte prestazioni
• VM con driver del kernel speciali (ad esempio NFS in modalità kernel)
• Dipendenze da hardware specifico
• Software con licenze legate alla registrazione di determinati ID hardware

Windows

Per Windows, i carichi di lavoro senza IIS 7 o versioni successive installate non sono adatti alla migrazione. Altri tipi di applicazioni non idonee alla migrazione includono:

• Applicazioni con dipendenze da GPU o TPU
• Applicazioni di networking a basso livello
• Applicazioni desktop, RDP e VDI
• Applicazioni con BYOL

Regole di accesso DNS e di rete

Prima di eseguire la migrazione a GKE, assicurati di conoscere le risorse di rete e i servizi utilizzati dai carichi di lavoro di cui è stata eseguita la migrazione e assicurati che siano accessibili e indirizzabili dal tuo Virtual Private Cloud.

Pianifica i nomi dei servizi Kubernetes

Se i tuoi carichi di lavoro dipendono dal DNS per accedere ai servizi, devi pianificare lo schema dello spazio dei nomi, i criteri di rete e i nomi dei servizi di Kubernetes.

La specifica di deployment generata dal processo di migrazione contiene un oggetto Service headless suggerito di tipo "ClusterIP". "ClusterIP" indica che non è presente alcun bilanciamento del carico e che un singolo IP interno del cluster è raggiungibile solo dall'interno del cluster. Il controller degli endpoint Kubernetes modifica la configurazione DNS per restituire record (indirizzi) che rimandano ai pod, etichettati con "app": "app-name" in deployment_spec.yaml.

Nota: i nomi dei servizi Kubernetes sono più limitati di quanto consentito dal DNS.

Creare e applicare servizi per le connessioni a pod e container

Dopo la migrazione di un carico di lavoro, i nomi host non sono più applicabili. Per consentire le connessioni ai tuoi carichi di lavoro, crea e applica servizi.

Identifica e configura i nomi e gli IP di cui è stata eseguita la migrazione

GKE gestisce il file /etc/hosts. In Migrate to Containers, l'adattamento del file hosts dalla VM di origine a GKE non è ancora automatizzato. I nomi e gli IP nel file hosts sulla VM di cui è stata eseguita la migrazione devono essere identificati e configurati come hostAliases.

Posiziona i servizi dipendenti nello stesso spazio dei nomi

I servizi dipendenti l'uno dall'altro devono essere colocalizzati nello stesso spazio dei nomi Kubernetes e utilizzare nomi DNS brevi (ad esempio app e db) per comunicare. Questa configurazione consente inoltre di replicare più ambienti di applicazione, come produzione, gestione temporanea e test.

Controlla l'area di accesso con la rete GKE

GKE dispone di controlli sofisticati per il networking. È possibile accedere ai pod da diverse reti, come la rete internet pubblica, la rete VPC o la rete del cluster interno. In questo modo, offre l'opportunità di controllare e limitare ulteriormente la superficie di accesso a un carico di lavoro senza la complessità aggiuntiva della gestione di VLAN, filtri o regole di routing.

Ad esempio, una tipica applicazione a tre livelli ha livelli frontend, di applicazione e database. Quando esegui la migrazione a Google Cloud, il servizio frontend viene configurato con un LoadBalancer sulla rete VPC. Gli altri livelli non sono direttamente accessibili dall'esterno del cluster GKE. Un policy di accesso di rete garantisce che il servizio dell'applicazione sia accessibile solo dai pod frontend dall'interno della rete del cluster interno. Un altro criterio garantisce che i pod di database siano accessibili solo dai pod di applicazione.

NFS

Definire i mount NFS come volumi permanenti

Quando crei il piano di migrazione, i mount client NFS sulla VM di origine vengono rilevati e aggiunti automaticamente al piano generato.

Sebbene i montaggi vengano aggiunti al piano, sono disattivati per impostazione predefinita. Ciò significa che le definizioni di PersistentVolume e PersistentVolumeClaim non sono incluse nel file deployment_spec.yaml quando generi gli elementi della migrazione. Se vuoi che Migrate to Containers generi definizioni di PersistentVolume e PersistentVolumeClaim, devi prima modificare il piano di migrazione per abilitare il montaggio del client NFS.

Per ulteriori informazioni, consulta Personalizzazione dei mount NFS.

Nota: Migrate to Containers richiede che i mount NFS siano accessibili dal cluster di deployment che ospita il workload del container di cui è stata eseguita la migrazione. Tuttavia, Migrate to Containers non convalida questa connettività. Un contenitore sottoposto a migrazione con un problema di connettività non può essere avviato e potrebbe essere necessario modificare il file deployment_spec.yaml per risolvere il problema. Per ulteriori informazioni, consulta Accedere alle istanze Filestore con il driver CSI Filestore.

Nota: l'utilizzo di NFS tramite un link VPN potrebbe comportare una riduzione delle prestazioni a causa dell'aumento della latenza e della larghezza di banda ridotta.

Server NFS in modalità kernel

Non è possibile eseguire la migrazione delle VM con server NFS in esecuzione in modalità kernel in GKE con Migrate to Containers. Queste VM devono essere migrate in VM su Compute Engine. In alternativa, puoi utilizzare Filestore per una soluzione NFS nativa del cloud.

Migrazione dei dati dalle condivisioni NFS di origine

Se la VM di origine utilizza un montaggio della condivisione NFS, non è possibile eseguire la migrazione di questi dati automaticamente. Monta la condivisione sul contenitore del carico di lavoro sottoposto a migrazione utilizzando un volume NFS permanente oppure, se la condivisione NFS di origine è remota, copia i dati in un'altra condivisione file che offra un accesso al cluster con latenza inferiore.

Per le opzioni di copia dei dati, consulta quanto segue:

1. Storage Transfer Service o Transfer Appliance.

2. Copia dei dati con gcloud storage rsync (dalla condivisione file di origine al bucket e poi dal bucket alla condivisione file nel cloud).

3. Soluzioni di terze parti, come NetApp SnapMirror a NetApp Cloud Volumes.

4. Utilità OSS come Rsync.

Assicurati che i database siano accessibili

Se la tua applicazione si basa su un database, che sia eseguito localmente sulla VM o su una macchina esterna, devi assicurarti che il database sia ancora accessibile dal nuovo pod sottoposto a migrazione. Devi verificare che il criterio del firewall di rete consenta l'accesso dal cluster al database.

Per eseguire la migrazione del database a Google Cloud, consigliamo di utilizzare Database Migration Service

In alternativa, puoi eseguire il database all'interno del cluster. Per ulteriori informazioni, consulta Pianifica i deployment di database su GKE.

Assicurati che i metadati iniettati siano disponibili

Se le tue applicazioni si basano su metadati iniettati (ad esempio variabili di ambiente), devi assicurarti che questi metadati siano disponibili su GKE. Se non è disponibile lo stesso metodo di inserimento dei metadati, GKE offre ConfigMaps e Secrets.

Configura i servizi necessari per l'avvio al livello di servizio 3

I carichi di lavoro di Migrate to Containers raggiungono solo il livello di servizio 3. Le VM migrate in GKE con Migrate to Containers verranno avviate nel contenitore al livello di servizio 3 di Linux. Alcuni servizi (ad esempio X11 o XDM per l'accesso remoto alla GUI tramite VNC) sono configurati per impostazione predefinita per l'avvio solo al livello di servizio 5. Tutti i servizi necessari devono essere configurati per l'avvio al livello di servizio 3.

Disattivare i servizi non necessari

Migrate to Containers disattiva automaticamente i servizi specifici per l'hardware o l'ambiente e un insieme predefinito di servizi aggiuntivi in esecuzione sulle VM. Questi servizi non sono necessari dopo la migrazione dei carichi di lavoro nei container.

Ad esempio, Migrate to Containers disattiva automaticamente iptables, ip6tables e firewalld. Per un elenco completo dei servizi disattivati da Migrate to Containers, scarica il file blocklist.yaml.

Personalizzazione dei servizi disattivati

Per impostazione predefinita, Migrate to Containers disattiva i servizi non necessari elencati sopra. Puoi anche definire un elenco personalizzato di servizi da disattivare in un contenitore sottoposto a migrazione personalizzando il piano di migrazione per definire una lista bloccata. Con una lista bloccata, puoi specificare uno o più servizi da disattivare in un contenitore sottoposto a migrazione.

Gestire e aggiornare le VM migrate

Utilizzando gli elementi generati durante la migrazione, puoi applicare aggiornamenti software di applicazioni e sistema operativo in modalità utente, patch di sicurezza, modificare configurazioni incorporate, aggiungere o sostituire file e aggiornare il software di runtime di Migrate to Containers.

Per ulteriori informazioni, consulta la sezione Aggiornamenti immagine post-migrazione.

Passaggi successivi

• Scopri di più sulla valutazione offline.