Best practice per la pianificazione

Questo argomento offre consigli per la migrazione 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 del Centro di migrazione o mcdc è uno strumento che puoi utilizzare per determinare l'idoneità del carico di lavoro delle VM per la migrazione a un container.

Carichi di lavoro consigliati

Migrate to Containers è consigliato per alcuni tipi di carichi di lavoro Linux e Windows, descritti in dettaglio di seguito.

Idoneo

Linux

Le applicazioni Linux ideali per la migrazione mediante Migrate to Containers includono le seguenti architetture delle applicazioni:

• Server web/di applicazioni
• Middleware per la logica di business (ad es. Tomcat)
• Stack multi-VM e multilivello (ad es. 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 a basso ciclo di lavoro e bursty
• Ambienti di sviluppo, test e formazione dei lab
• 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 in Non è adatto.

Windows

Le applicazioni Windows ideali per la migrazione utilizzando Migrate to Containers includono 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 superiore

Supporto del sistema operativo

Migrate to Containers è compatibile con questi sistemi operativi VM.

Non è adatto

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 associate a un determinato ID hardware registrato

Windows

Per Windows, i carichi di lavoro senza IIS 7 o versioni successive non sono idonei per la migrazione. Altri tipi di applicazioni non adatte alla migrazione includono:

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

DNS e regole di accesso alla rete

Prima di eseguire la migrazione a GKE, assicurati di comprendere le risorse di rete e i servizi utilizzati dai carichi di lavoro migrati e assicurati che siano accessibili e raggiungibili dal tuo Virtual Private Cloud.

Pianifica i nomi dei servizi Kubernetes

Se i 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 Kubernetes.

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

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

Creazione e applicazione di 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 i 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 migrata devono essere identificati e configurati come hostAliases.

Colloca 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 applicativi, come produzione, gestione temporanea e test.

Controlla la piattaforma di accesso con il networking GKE

GKE dispone di sofisticati controlli di networking. È possibile accedere ai pod da diverse reti, come la rete internet pubblica, la rete VPC o la rete cluster interna. Ciò offre l'opportunità di controllare ulteriormente e limitare la piattaforma di accesso a un carico di lavoro senza la complessità aggiuntiva della gestione delle VLAN, dei filtri o delle regole di routing.

Ad esempio, una tipica applicazione a tre livelli ha livelli di frontend, applicazione e database. Quando viene eseguita la migrazione a Google Cloud, il servizio di frontend viene configurato con un LoadBalancer sulla rete VPC. Gli altri livelli non sono accessibili direttamente dall'esterno del cluster GKE. Un criterio di accesso alla rete assicura 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 dell'applicazione.

NFS

Definisci i montaggi NFS come volumi permanenti

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

Sebbene i montaggi vengano aggiunti al piano, sono disabilitati per impostazione predefinita. Ciò significa che le definizioni di PersistentVolume e PersistentVolumeClaim non sono incluse nel file deployment_spec.yaml quando generi gli artefatti di migrazione. Se vuoi che Migrate to Containers generi le 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 montaggi NFS.

Nota: Migrate to Containers richiede che i montaggi 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à. Impossibile avviare un container di cui è stata eseguita la migrazione con un problema di connettività e potresti dover 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 su un link VPN potrebbe aver ridotto le prestazioni a causa dell'aumento della latenza e della larghezza di banda ridotta.

Server NFS in modalità kernel

Non è possibile eseguire la migrazione in GKE delle VM con server NFS in esecuzione in modalità kernel con Migrate to Containers. È necessario eseguire la migrazione di queste VM in VM su Compute Engine. In alternativa, puoi utilizzare Filestore per una soluzione NFS cloud-native.

Migrazione dei dati dalle condivisioni NFS di origine

Se la VM di origine utilizza un montaggio di condivisione NFS, non è possibile eseguire la migrazione automatica di questi dati. Monta la condivisione sul container del carico di lavoro di cui è stata eseguita la migrazione utilizzando un volume permanente NFS oppure, se la condivisione NFS di origine è remota, copia i dati in un'altra condivisione file che fornisce accesso a latenza minore al cluster.

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

1. Storage Transfer Service o Transfer Appliance.

2. Copia di dati con gsutil rsync (dalla condivisione del 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 viene eseguito localmente sulla VM o su una macchina esterna, 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 consenta l'accesso dal cluster al database.

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

In alternativa, puoi eseguire il database all'interno del cluster. Per maggiori informazioni, consulta Pianificare il deployment dei database su GKE.

Assicurati che i metadati inseriti siano disponibili

Se le tue applicazioni si basano su metadati inseriti (ad esempio variabili di ambiente), devi assicurarti che questi metadati siano disponibili in GKE. Se lo stesso metodo di inserimento dei metadati non è disponibile, GKE offre 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 esecuzione 3. Le VM migrate in GKE con Migrate to Containers verranno avviate nel container a runlevel 3 Linux. Alcuni servizi (ad esempio X11 o XDM, per l'accesso GUI remoto utilizzando VNC) sono configurati per impostazione predefinita per essere avviati solo al runtime 5. Tutti i servizi necessari devono essere configurati in modo da iniziare a livello di esecuzione 3.

Disattiva i servizi non necessari

Migrate to Containers disabilita automaticamente i servizi specifici dell'hardware o dell'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 disabilitati da Migrate to Containers, scarica il file blocklist.yaml.

Personalizzazione dei servizi disattivati

Per impostazione predefinita, Migrate to Containers disabilita i servizi non necessari elencati sopra. Puoi anche definire il tuo elenco personalizzato di servizi da disabilitare in un container di cui è stata eseguita la migrazione personalizzando il piano di migrazione per definire una lista bloccata. Con una lista bloccata, puoi specificare uno o più servizi da disabilitare in un container di cui è stata eseguita la migrazione.

Gestisci e aggiorna le VM migrate

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

Per ulteriori informazioni, consulta Aggiornamenti delle immagini post-migrazione.

Passaggi successivi

• Scopri di più sulla valutazione offline.