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.
L'interfaccia a riga di comando del client di rilevamento 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 alcuni tipi di carichi di lavoro Linux e Windows, che vengono descritti in dettaglio 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 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:
- 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 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 versioni successive
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 che non sono adatti alla migrazione con Migrate to Containers include:
- 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 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 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 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 rimandano ai pod, etichettati con "app": "app-name" in deployment_spec.yaml.
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 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 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 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 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
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.
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 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 condiviso 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:
Copia dei dati con
gcloud storage rsync(dalla condivisione file di origine al bucket e poi dal bucket alla condivisione file nel cloud).Soluzioni di terze parti, come NetApp SnapMirror a NetApp Cloud Volumes.
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 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 Pianificare i deployment dei database su GKE.
Assicurati che i metadati iniettati siano disponibili
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 l'avvio al livello di servizio 3
I carichi di lavoro di Migrate to Containers raggiungono solo il runtime 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 in modo da iniziare per impostazione predefinita runlevel 5. Tutti i servizi necessari devono essere configurati per l'avvio al livello di servizio 3.
Disattiva 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 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 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 disabilitare in un container di cui è stata eseguita la 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 saperne di più, vedi Aggiornamenti delle immagini dopo la migrazione.
Passaggi successivi
- Scopri di più sulla valutazione offline.