Best practice per la pianificazione

Questo argomento fornisce 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.

Interfaccia a riga di comando del client predittivo del Centro di migrazione o l'interfaccia a riga di comando mcdc è uno strumento che utilizzi per determinare la VM adatto alla migrazione a un container.

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 mediante Migrate to Containers includono le seguenti architetture dell'applicazione:

• 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 presentano le seguenti caratteristiche operative:

• Carichi di lavoro con duty cycle basso e intermittenti
• Ambienti di lab di sviluppo, test e formazione
• Servizi sempre attivi, 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 perfette per la migrazione con Migrate to Containers include carichi di lavoro che soddisfano tutti i seguenti caratteristiche:

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

Supporto dei sistemi operativi

Migrate to Containers è compatibile con questi Sistemi operativi per 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 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 idonei per la migrazione. Altri tipi di applicazioni non idonee alla migrazione includono:

• Applicazioni con dipendenze da GPU o TPU
• Applicazioni di networking di 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 del 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ù limitato 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 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, adattando il file hosts dalla VM di origine a GKE non è ancora automatizzato. I nomi e gli IP nel file hosts sulla La VM deve essere identificata e configurata come hostAliases.

Collocare i servizi dipendenti nello stesso spazio dei nomi

I servizi che dipendono l'uno dall'altro devono essere collocati 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 la networking. È possibile accedere ai pod da diverse reti, come la rete internet pubblica, la rete VPC o la rete del cluster interno. Questo offre l'opportunità di controllare ulteriormente e limitare la superficie di accesso a un carico di lavoro senza la complessità aggiuntiva di gestione di VLAN, filtri o routing le regole del caso.

Ad esempio, una tipica applicazione a tre livelli ha livelli frontend, di applicazione e database. Quando viene eseguita la migrazione a Google Cloud, il servizio di frontend 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

Definisci i montaggi 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.

Mentre i supporti vengono 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 carico di lavoro del container di cui è stata eseguita la migrazione. Tuttavia, Migrate to Containers non convalida questa connettività. Un container di cui è stata eseguita la migrazione con un problema di connettività non può essere avviato e potrebbe essere necessario modificare il file deployment_spec.yaml per risolvere il problema. Vedi Accedere alle istanze Filestore con il driver CSI Filestore per ulteriori informazioni.

Nota: l'utilizzo di NFS tramite link VPN potrebbe ridurre le prestazioni grazie all'aumento della latenza e alla larghezza di banda ridotta.

Server NFS in modalità kernel

Le VM con server NFS in esecuzione in modalità kernel non possono essere di cui è stata eseguita la migrazione in GKE con Migrate to Containers. Queste VM devono essere di cui è stata eseguita la migrazione 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 una 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 in corso... (dalla condivisione file di origine al bucket e quindi dal bucket alla condivisione file cloud).

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

4. le utilità OSS come Rsync.

Assicurati che i database siano accessibili

Se la tua applicazione si basa su un database, eseguito localmente sulla VM, o su un computer esterno, devi assicurarti che il database sia ancora accessibile dal nuovo pod di cui è stata eseguita la migrazione. Devi verificare che il criterio firewall di rete permette di accedere 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 Pianificare i deployment dei 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 lo stesso metodo di inserimento dei metadati non è disponibile, Offerte GKE ConfigMaps e Secret.

Configura i servizi necessari per iniziare dal runlevel 3

I carichi di lavoro di Migrate to Containers raggiungono solo il livello di servizio 3. VM migrate in Verrà avviato GKE con Migrate to Containers il container su Linux runlevel 3. Alcuni servizi (ad esempio X11 o XDM, per l'accesso remoto alla GUI tramite VNC) sono configurati in modo da iniziare per impostazione predefinita runlevel 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 ai container.

Ad esempio, Migrate to Containers disabilita 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.