Personalizza il piano di migrazione per le VM Linux
Prima di eseguire un piano di migrazione, è consigliabile esaminarlo e, facoltativamente, personalizzarlo. I dettagli del piano di migrazione vengono utilizzati per estrarre gli artefatti dei container del carico di lavoro dalla VM di origine e anche per generare file di deployment di Kubernetes che puoi utilizzare per eseguire il deployment dell'immagine container in altri cluster, ad esempio un cluster di produzione.
Questa pagina descrive i contenuti del piano di migrazione e i tipi di personalizzazioni che potresti prendere in considerazione prima di eseguire la migrazione e generare artefatti di deployment.
Prima di iniziare
Questo argomento presuppone che tu abbia già creato un piano di migrazione e disponga del file del piano di migrazione risultante.
Modifica il piano di migrazione
Dopo aver copiato e analizzato il file system, puoi trovare il piano di migrazione nella nuova directory creata nel percorso di output specificato: ANALYSIS_OUTPUT_PATH/config.yaml
.
Modifica il piano di migrazione in base alle esigenze e salva le modifiche.
Rivedi i dettagli del piano di migrazione e i commenti guida per aggiungere informazioni, se necessario. In particolare, prendi in considerazione le modifiche apportate alle sezioni seguenti.
Specifica i contenuti da escludere dalla migrazione
Per impostazione predefinita, Migrate to Containers esclude i contenuti tipici delle VM non pertinenti nel contesto di GKE. Puoi personalizzare il filtro.
Il valore del campo filters
elenca i percorsi che devono essere esclusi dalla migrazione e non faranno parte dell'immagine container.
Il valore del campo elenca le regole di filtro rsync che specificano quali file trasferire e quali ignorare. La presenza di un segno meno (-) davanti a ogni percorso e file specifica che l'elemento nell'elenco deve essere escluso dalla migrazione. L'elenco viene elaborato in base all'ordine delle righe nel YAML e le esclusioni/inclusioni vengono valutate di conseguenza.
Scopri di più sulle regole di filtro rsync.
I file troppo grandi per essere inclusi nell'immagine Docker sono elencati nel file YAML. In questo modo verranno segnalati i file di dimensioni superiori a 1 GB. Le immagini Docker troppo grandi o più grandi di 15 GB rischiano di non funzionare durante la migrazione.
Puoi modificare l'elenco YAML per aggiungere o rimuovere percorsi. Di seguito è riportato un codice YAML di esempio, che include esclusioni di esempio e notifiche per file sparsi e di grandi dimensioni. Segui le indicazioni incorporate per eseguire una delle seguenti azioni:
- Escludi le cartelle rilevate rimuovendo il commento e posizionandole nella sezione dei filtri globali.
- Sposta le cartelle rilevate in un volume permanente rimuovendo il commento e posizionandole nella sezione delle cartelle dei dati.
Puoi anche escludere o spostare i file sparsi rilevati allo stesso modo.
global:
# Files and directories to exclude from the migration, in rsync format.
filters:
- "- *.swp"
- "- /etc/fstab"
- "- /boot/"
- "- /tmp/*"
- "- /var/log/*.log*"
- "- /var/log/*/*.log*"
- "- /var/cache/*"
## The data folders below are too large to be included in the docker image.
## Consider uncommenting and placing them under either the global filters
## or the data folder section.
# - '- /a' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
# - '- /a/c' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
## Sparse files will fail the run of a docker image. Consider excluding the below
## detected files and any other sparse files by uncommenting and placing them in
## the global filters section, or export them to a persistent volume by specifying
## them in the data folder section.
# - '- /a/b' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
# - '- /a/d' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
Imposta il nome dell'immagine container
Il valore del campo name
nella sezione image
definisce il nome dell'immagine creata da una VM migrata utilizzata per il container. Puoi modificare questo valore se preferisci usare un altro nome.
image:
# Review and set the name for runnable container image.
name: linux-system
Personalizzare l'elenco dei servizi
Per impostazione predefinita, Migrate to Containers disabilita i servizi non necessari su una VM quando ne esegui la migrazione in un container. Questi servizi a volte possono causare problemi con il container di cui è stata eseguita la migrazione o non sono necessari in un contesto di container.
Insieme ai servizi disattivati automaticamente da Migrate to Containers, puoi scegliere se disabilitare altri servizi:
Migrate to Containers rileva automaticamente i servizi che puoi disabilitare facoltativamente e li elenca nel piano di migrazione. Questi servizi, come
ssh
o un server web, potrebbero non essere necessari nel carico di lavoro di cui è stata eseguita la migrazione, ma spetta a te decidere. Se necessario, modifica il piano di migrazione per disabilitare questi servizi.Migrate to Containers non elenca tutti i servizi in esecuzione sulla VM di origine. Ad esempio, vengono omessi i servizi relativi al sistema operativo. Se vuoi, puoi modificare il piano di migrazione per aggiungere il tuo elenco di servizi da disabilitare nel container di cui è stata eseguita la migrazione.
Il campo systemServices
specifica l'elenco dei servizi rilevati da Migrate to Containers.
Ad esempio:
systemServices: - enabled: true|false name: service-name probed: true|false - enabled: true|false name: service-name probed: true|false ...
Per disattivare un servizio, imposta enabled
su false
.
Migrate to Containers non elenca tutti i servizi in esecuzione sulla VM di origine, ad esempio i servizi relativi al sistema operativo. Puoi anche aggiungere altri servizi all'elenco.
Ad esempio, per disattivare service2
e il servizio cron
:
systemServices: - enabled: true name: service1 probed: false - enabled: false name: service2 probed: false - enabled: false name: cron probed: false
Quando esegui una migrazione per generare gli artefatti di migrazione, Migrate to Containers crea il file blocklist.yaml
.
Questo file elenca i servizi container da disabilitare in base alle impostazioni nel piano di migrazione.
Ad esempio:
service_list: - name: disabled-services services: # Because you used systemServices above to disabled service2 and cron: - service2 - cron
Per modificare in un secondo momento l'elenco dei servizi disattivati:
- Modifica l'elenco dei servizi nel piano di migrazione.
- Esegui la migrazione per rigenerare gli artefatti di migrazione, incluso un
blocklist.yaml
aggiornato.
In alternativa, dopo aver eseguito una migrazione per generare gli artefatti di migrazione, puoi modificare direttamente il file blocklist.yaml
e poi creare ed eseguire il deployment dell'immagine container utilizzando Skaffold.
Personalizza gli endpoint dei servizi
Il piano di migrazione include l'array endpoints
che definisce le porte e i protocolli utilizzati per creare i servizi Kubernetes forniti dal carico di lavoro di cui è stata eseguita la migrazione.
Puoi aggiungere, modificare o eliminare le definizioni degli endpoint per personalizzare il piano di migrazione.
Per recuperare le porte degli endpoint, controlla i programmi che ascoltano le porte:
sudo netstat --programs --listening --tcp --udp [--sctp]
Per ogni endpoint di servizio, aggiungi la seguente definizione al piano di migrazione:
endpoints: - port: PORT_NUMBER protocol: PORT_PROTOCOL name: PORT_NAME
Dove:
- PORT_NUMBER specifica il numero di porta del container a cui vengono instradate le richieste al servizio.
- PORT_PROTOCOL specifica il protocollo della porta, ad esempio HTTP, HTTPS o TCP. Vedi Protocolli supportati per l'elenco completo dei protocolli.
- PORT_NAME specifica il nome utilizzato per accedere all'endpoint del servizio. Migrate to Containers genera un PORT_NAME univoco per ogni definizione di endpoint generata.
Ad esempio, Migrate to Containers rileva i seguenti endpoint:
endpoints: - port: 80 protocol: HTTP name: backend-server-nginx - port: 6379 protocol: TCP name: backend-server-redis
Per impostare il valore della proprietà name
, Migrate to Containers combina il nome della VM di origine, backend-server
in questo esempio, con il nome del programma del servizio.
I nomi generati sono compatibili con le convenzioni di denominazione di Kubernetes e sono univoci
all'interno del piano di migrazione. Ad esempio, il piano di migrazione riportato sopra crea un servizio che ha come target Nginx sulla porta 80 tramite HTTP.
A tutti i nomi duplicati, Migrate to Containers aggiunge un suffisso del contatore. Ad esempio, se Nginx è associato a due porte, aggiunge il suffisso -2
a name
nella seconda definizione:
endpoints: - port: 80 protocol: HTTP name: backend-server-nginx - port: 8080 protocol: HTTPS name: backend-server-nginx-2 - port: 6379 protocol: TCP name: backend-server-redis
Quando esegui una migrazione per generare gli artefatti di migrazione, Migrate to Containers crea una definizione di Servizio nel file deployment_spec.yaml
per ciascun endpoint.
Ad esempio, di seguito è riportata una definizione di Service
nel file deployment_spec.yaml
:
apiVersion: v1 kind: Service metadata: creationTimestamp: null name: backend-server-nginx spec: ports: - port: 80 protocol: HTTP targetPort: 80 selector: app: backend-server status: loadBalancer: {}
Personalizza i montaggi NFS
Migrate to Containers include i montaggi NFS nel piano di migrazione generato.
Queste informazioni vengono raccolte dal file fstab
e scritte nell'array nfsMounts
del piano di migrazione. Puoi aggiungere o modificare le definizioni del punto di montaggio NFS per personalizzare il piano di migrazione.
Quando generi il piano di migrazione, Migrate to Containers:
- Ignora i montaggi NFS per
/sys
e/dev
. - Ignora i montaggi NFS con un tipo diverso da
nfs
onfs4
.
Ogni montaggio NFS nel piano di migrazione include l'indirizzo IP e il percorso di montaggio locale del server nel formato:
nfsMounts: - mountPoint: MOUNT_POINT exportedDirectory: DIR_NAME nfsServer: IP mountOptions: - OPTION_1 - OPTION_2 enabled: false|true
Dove:
- MOUNT_POINT specifica il punto di montaggio ottenuto da
fstab
. - DIR_NAME specifica il nome della directory condivisa.
- IP specifica l'indirizzo IP del server che ospita il punto di montaggio.
- OPTION_N specifica qualsiasi opzione estratta da
fstab
per il punto di montaggio.
Ad esempio, per la seguente voce in fstab
:
<file system> <mount point> <type> <options> <dump> <pass> 10.49.232.26:/vol1 /mnt/test nfs rw,hard 0 0
Migrate to Containers genera la voce seguente nel piano di migrazione:
nfsMounts: - mountPoint: /mnt/test exportedDirectory: /vol1 nfsServer: 10.49.232.26 mountOptions: - rw - hard enabled: false
Per configurare Migrate to Containers in modo che elabori le voci nell'array nfsMounts
,
imposta enabled
su true
per la voce mountPoint
. Puoi abilitare una, alcune o tutte le voci mountPoints
, modificare le voci o aggiungerne di tue.
Quando esegui una migrazione per generare gli artefatti di migrazione, Migrate to Containers crea una definizione di volumi e volumeMounts e una definizione di PersistentVolume e PersistentVolumeClaim nel file deployment_spec.yaml
per ogni montaggio NFS abilitato.
Ad esempio, di seguito è riportata una definizione di volumeMounts
nel file deployment_spec.yaml
:
spec: containers: - image: gcr.io/myimage-1/image-name name: some-app volumeMounts: - mountPath: /sys/fs/cgroup name: cgroups - mountPath: /mnt/test name: nfs-pv
Dove il valore di name
è un identificatore univoco generato da Migrate to Containers.
Di seguito è riportato un esempio di definizioni PersistentVolumeClaim
e PersistentVolume
nel file deployment_spec.yaml
:
apiVersion: v1 kind: PersistentVolumeClaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Mi storageClassName: "" volumeName: nfs-pv apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv spec: mountOptions: - rw - hard nfs: path: /vol1 server: 10.49.232.26
Personalizza i dati di log scritti in Cloud Logging
In genere una VM di origine scrive informazioni in uno o più file di log. Nell'ambito della migrazione della VM, puoi configurare il carico di lavoro di cui è stata eseguita la migrazione in modo che scriva le informazioni di log in Cloud Logging.
Quando generi il piano di migrazione, Migrate to Containers cerca automaticamente i file di destinazione dei log nella VM di origine. Migrate to Containers scrive quindi le informazioni sui file rilevati nell'area logPaths
del piano di migrazione:
deployment: ... logPaths: - appName: APP_NAME globs: - LOG_PATH
Ad esempio:
deployment: ... logPaths: - appName: tomcat globs: - /var/log/tomcat*/catalina.out
Quando generi gli artefatti di migrazione, Migrate to Containers genera il file logs.yaml
dal piano di migrazione. Questo file contiene l'elenco dei file di log rilevati dalla VM di origine. Ad esempio, dalla definizione di logsPath
riportata sopra, logs.yaml
contiene:
logs: tomcat: - /var/log/tomcat*/catalina.out
In questo esempio, quando esegui il deployment del carico di lavoro di cui è stata eseguita la migrazione, le informazioni di log scritte in catalina.out
vengono automaticamente scritte in Cloud Logging.
Le voci vengono visualizzate ciascuna su una riga del log nel seguente formato:
DATE TIME APP_NAME LOG_OUTPUT
L'esempio seguente illustra il modulo con una voce da Tomcat:
2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output
Per configurare il logging, puoi:
Modifica il piano di migrazione prima di generare gli artefatti di migrazione per aggiungere, rimuovere o modificare le voci
logPaths
. Quando generi gli artefatti di migrazione, queste modifiche si riflettono nel filelogs.yaml
.Modifica
logs.yaml
dopo aver generato gli artefatti di migrazione per aggiungere, rimuovere o modificare le vocilogs
.
Il vantaggio della modifica del piano di migrazione è che le modifiche vengono applicate in logs.yaml
ogni volta che generi gli artefatti. Se modifichi logs.yaml
direttamente e poi rigeneri gli artefatti per qualche motivo, devi applicare di nuovo le modifiche a logs.yaml
.
Imposta probe di integrità v2kServiceManager di Linux
Puoi monitorare i tempi di inattività e lo stato di pronto dei container gestiti specificando i probe nel piano di migrazione del server web Tomcat. Il monitoraggio del probe di integrità può aiutare a ridurre i tempi di inattività dei container di cui è stata eseguita la migrazione e a fornire un monitoraggio migliore.
Gli stati di integrità sconosciuti possono causare un peggioramento della disponibilità, il monitoraggio della disponibilità di falsi positivi e la potenziale perdita di dati. Senza un probe di integrità, kubelet può solo presumere l'integrità di un container e può inviare il traffico a un'istanza di container non pronta. Ciò può causare una perdita di traffico. kubelet potrebbe inoltre non rilevare i container che sono in stato bloccato e non li riavvia.
Un probe di integrità funziona eseguendo una piccola istruzione basata su script all'avvio del container.
Lo script verifica a ogni periodo la presenza di condizioni di esito positivo, definite in base al tipo di probe utilizzato. Il periodo è definito nel piano di migrazione da un campo periodSeconds
.
Puoi eseguire o definire questi script manualmente.
Per scoprire di più sui probe kubelet, consulta Configurare probe di attività, idoneità e avvio nella documentazione di Kubernetes.
Sono disponibili due tipi di probe da configurare. Entrambi i probe sono probe-v1-core definiti nel riferimento probe-v1-core e condividono la stessa funzione dei campi corrispondenti di container-v1-core
- Probe di attività: i probe di attività vengono utilizzati per sapere quando è necessario riavviare un container.
- Probe di idoneità: vengono utilizzati i probe di idoneità per sapere quando un container è pronto per iniziare ad accettare traffico. Per iniziare a inviare traffico a un pod solo quando un probe ha esito positivo, specifica un probe di idoneità. Un probe di idoneità può funzionare in modo simile a un probe di attività, ma nelle specifiche indica che un pod verrà avviato senza ricevere traffico e inizierà a ricevere traffico solo dopo l'esito positivo del probe.
Dopo il rilevamento, la configurazione del probe viene aggiunta al piano di migrazione. I probe possono essere utilizzati nella loro configurazione predefinita, come mostrato di seguito. Per disabilitare i probe, rimuovi la sezione probes
dal file YAML.
deployment:
probes:
livenessProbe:
exec:
command:
- /ko-app/service-manager-runtime
- /probe
readinessProbe:
exec:
command:
- gamma
- /probe
initialDelaySeconds: 60
periodSeconds: 5
image:
# Disable system services that do not need to be executed at the migrated workload containers.
# Enable the 'probed' property to include system services in the container health checks.
systemServices:
- enabled: true
name: apache2
probed: true
- enabled: true
name: atd
probed: false
Per impostazione predefinita, tutti i probe di servizi sono disabilitati. Devi definire quale sottoinsieme di servizi verrà monitorato.
Esistono quattro modi predefiniti per controllare un container utilizzando un probe. Ogni probe deve definire esattamente uno di questi quattro meccanismi:
exec
: esegue un comando specificato all'interno del container. L'esecuzione viene considerata riuscita se il codice di stato di uscita è 0.grpc
- Esegue una chiamata di procedura remota utilizzando "gRPC". I probe "gRPC" sono una funzionalità alpha.httpGet
: esegue una richiesta HTTP GET sull'indirizzo IP del pod su una porta e un percorso specificati. La richiesta viene considerata riuscita se il codice di stato è maggiore o uguale a 200 e inferiore a 400.tcpSocket
: esegue un controllo TCP rispetto all'indirizzo IP del pod su una porta specificata. La diagnostica viene considerata riuscita se la porta è aperta.
Per impostazione predefinita, un piano di migrazione attiva il metodo di probe exec
. Utilizza la configurazione manuale per il tuo piano di migrazione per attivare un altro metodo.
Per aggiungere dipendenze esterne per il probe di idoneità, mentre utilizzi il probe di attività predefinito, definisci un probe di idoneità exec e uno script che implementa la logica.
Passaggi successivi
- Scopri come eseguire la migrazione.