Best practice per la pianificazione

Questo argomento offre consigli per la migrazione di applicazioni a Google Kubernetes Engine (GKE) o GKE Enterprise, basate sulle 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 alcuni tipi di carichi di lavoro Linux e Windows, che vengono descritti in dettaglio 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 della logica di business (ad esempio Tomcat)
• Stack multi-VM e multi-livello (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:

• Ciclo di servizio ridotto e carichi di lavoro intensivi
• 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 carichi di lavoro esplicitamente elencati di seguito in Non adatta.

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 versione successiva, ASP.NET con .NET Framework 3.5 o versione successiva
• Livelli logici e web
• WS2008 R2 o successivo

Supporto dei sistemi operativi

Migrate to Containers è compatibile con questi Sistemi operativi per VM.

Non adatto

Linux

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

• 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 un determinato ID hardware

Windows

Per Windows, i carichi di lavoro che non hanno installato IIS 7 o versioni successive non sono adatti 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 alla rete e DNS

Prima di eseguire la migrazione a GKE, assicurati di aver compreso il le risorse di rete e i servizi utilizzati dai carichi di lavoro migrati e assicurati che perché 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 la configurazione schema dello spazio dei nomi, criteri di rete e nomi dei servizi.

La specifica del deployment generata dal processo di migrazione contiene un oggetto Service headless suggerito di tipo "ClusterIP". "ClusterIP" significa nessun bilanciamento del carico e un singolo IP interno del cluster raggiungibile solo dall'interno nel cluster. Il controller degli endpoint Kubernetes modifica la configurazione DNS per restituire record (indirizzi) che puntano ai pod, etichettati con "app": "app-name" nel file 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 nomi e 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. Questo aiuta anche a replicare più ambienti applicativi, come come produzione, gestione temporanea e test.

Controlla la piattaforma di accesso con il networking GKE

GKE offre sofisticate networking i controlli di sicurezza. È possibile accedere ai pod da diversi reti, ad esempio la rete internet pubblica, la rete VPC o la rete cluster interna. 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 include frontend, applicazione ai livelli del 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 accesso alla rete norme garantisce che il servizio dell'applicazione sia accessibile solo dai pod frontend all'interno della rete del cluster interna. Un altro criterio assicura che i pod del database sono accessibili solo dai pod dell'applicazione.

NFS

Definisci i montaggi NFS come volumi permanenti

Quando crei il piano di migrazione, il client NFS monta 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 generare artefatti di 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.

Consulta Personalizzazione dei montaggi NFS. per ulteriori informazioni.

Nota: Migrate to Containers richiede che i montaggi NFS siano accessibili 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 cloud-native.

Migrazione dei dati dalle condivisioni NFS di origine

Se la VM di origine utilizza un montaggio condiviso NFS, non è possibile eseguire la migrazione di questi dati automaticamente. Monta la condivisione sul container dei carichi di lavoro di cui è stata eseguita la migrazione utilizzando un volume permanente NFS oppure, se la condivisione NFS di origine è remota, copia i dati a un'altra condivisione file che fornisce l'accesso a latenza più bassa al cluster.

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 to 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, ti consigliamo di utilizzare Database Migration Service

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

Assicurati che siano disponibili i metadati inseriti

Se le tue applicazioni si basano su metadati inseriti (ad esempio, l'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 runtime 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 in modo da iniziare dal runlevel 3.

Disattiva i servizi non necessari

Migrate to Containers disabilita automaticamente le specifiche 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 blocklist.yaml .

Personalizzazione dei servizi disattivati

Per impostazione predefinita, Migrate to Containers disabilita i servizi non necessari elencati sopra. Puoi anche definire un 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 software del sistema operativo in modalità utente, patch di sicurezza, modifica delle configurazioni incorporate aggiunta o sostituzione di file e per l'aggiornamento di Migrate to Containers il software di runtime.

Per saperne di più, vedi Aggiornamenti delle immagini dopo la migrazione.

Passaggi successivi

• Scopri di più sulla valutazione offline.