Personalizza il piano di migrazione per le VM Linux

Prima di eseguire un piano di migrazione, devi esaminarlo e, se vuoi, personalizzarlo. I dettagli del piano di migrazione vengono utilizzati per estrarre il container del carico di lavoro gli artefatti dalla VM di origine e anche per generare file di deployment Kubernetes che puoi utilizzare per eseguire il deployment dell'immagine container in altri cluster, ad esempio di produzione.

In questa pagina vengono descritti i contenuti del piano di migrazione e i tipi di personalizzazioni che potresti prendere in considerazione prima di eseguire la migrazione artefatti di deployment.

Prima di iniziare

Questo argomento presuppone che tu abbia già creato un piano di migrazione e che tu abbia il file del piano di migrazione risultante.

Modifica il piano di migrazione

Dopo aver copiato il file system e analizzato il file, puoi trovare il piano di migrazione nella nuova directory creata nell'output specificato percorso: ANALYSIS_OUTPUT_PATH/config.yaml.

Modifica il piano di migrazione in base alle tue esigenze e salva le modifiche.

Esamina i dettagli del piano di migrazione e i commenti guida per aggiungere le informazioni necessarie. In particolare, prendi in considerazione le modifiche apportate alle seguenti sezioni.

Specifica i contenuti da escludere dalla migrazione

Per impostazione predefinita, Migrate to Containers esclude i contenuti tipici delle VM che non sono 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 farà parte dell'immagine container. Il valore del campo elenca le regole del filtro rsync che specificano quali file trasferire e quali saltare. Se precedi ogni percorso e file con un segno meno, specifichi che l'elemento nell'elenco deve essere escluso dalla migrazione. L'elenco viene elaborato in base all'ordine delle righe nel file YAML e le esclusioni/inclusioni vengono valutate di conseguenza.

Scopri di più su regole del filtro rsync.

Vengono elencati i file troppo grandi per essere inclusi nell'immagine Docker nel file YAML. In questo modo, i file di dimensioni superiori a 1 GB verranno segnalati per la tua attenzione. Le immagini Docker troppo grandi o superiori a 15 GB sono a rischio di errori durante la migrazione.

Puoi modificare l'elenco YAML per aggiungere o rimuovere percorsi. Di seguito è riportato un esempio di file YAML, che include esclusioni di esempio, nonché notifiche per file di grandi dimensioni e sparsi. Segui le indicazioni in linea per eseguire una delle seguenti azioni:

• Escludi le cartelle rilevate disattivando il commento e inserendole nella sezione dei filtri globali.
• Sposta le cartelle rilevate in un volume permanente rimuovendo il commento dalle cartelle e e posizionarli nella sezione della cartella 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 vengono create da una VM migrata utilizzata per il container. Puoi modificare questo valore se preferisci utilizzare un nome diverso.

image:
     # Review and set the name for runnable container image.
     name: linux-system

Personalizzare l'elenco di 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 problemi con il container di cui è stata eseguita la migrazione o che non sono necessari in un contesto del container.

Oltre ai servizi disattivati automaticamente da Migrate to Containers, puoi disattivare facoltativamente altri servizi:

• Migrate to Containers rileva automaticamente i servizi che puoi disattivare facoltativamente e li elenca nel piano di migrazione. Questi servizi, ad esempio ssh o un server web, potrebbe non essere necessario nel carico di lavoro migrato, ma spetta a te prendere questa decisione. Se necessario, modifica il piano di migrazione per disabilitare questi servizi.

• La migrazione a Containers non elenca tutti i servizi in esecuzione sulla VM di origine. Ad esempio, omette i servizi relativi al sistema operativo. In via facoltativa, modifica 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, come e servizi correlati al sistema operativo. Puoi anche aggiungere ulteriori 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 degli artefatti di migrazione, Migrate to Containers crea il file blocklist.yaml. Questo file elenca i servizi dei container da disattivare 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 elementi della migrazione, incluso un blocklist.yaml aggiornato.

In alternativa, dopo aver eseguito una migrazione per generare la migrazione puoi modificare direttamente il file blocklist.yaml e poi creare ed eseguire il deployment dell'immagine container utilizzando Skaffold.

Personalizza gli endpoint di servizio

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 migrato. 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 sono porte di ascolto:

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 contenitore a cui vengono inoltrate le richieste al servizio.
• PORT_PROTOCOL specifica il protocollo della porta, ad esempio HTTP, HTTPS o TCP. Per un elenco completo dei protocolli, consulta Protocolli supportati.
• PORT_NAME specifica il nome utilizzato per accedere all'endpoint di servizio. Migrate to Containers genera un valore 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, Migrazione a contenitori 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.

Per eventuali 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 elementi della migrazione, Migrazione a contenitori crea una definizione di servizio nel file deployment_spec.yaml per ogni 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: {}

Personalizzare i mount NFS

Migrate to Containers include i mount NFS nel piano di migrazione generato. Queste informazioni vengono raccolte dal file fstab e scritte nella Array nfsMounts nel piano di migrazione. Puoi aggiungere o modificare Definizioni dei punti di montaggio NFS per personalizzare il piano di migrazione.

Nota: le voci nell'array nfsMounts sono disattivate per impostazione predefinita. Devi attivarle se vuoi che Migrate to Containers generi voci nel file deployment_spec.yaml per ogni montaggio NFS.

Quando genera il piano di migrazione, Migrate to Containers:

• Ignora i mount NFS per /sys e /dev.
• Ignora i mount NFS con un tipo diverso da nfs o nfs4.

Ogni montaggio NFS nel piano di migrazione include l'indirizzo IP del server e il percorso di montaggio locale nel seguente 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 le opzioni estratte 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 seguente voce 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 attivare una, alcune o tutte le voci mountPoints, modificarle o aggiungerne di tue.

Quando esegui una migrazione per generare gli artefatti di migrazione, Migrate to Containers crea un volume e volumeMounts e un oggetto PersistentVolume e PersistentVolumeClaim definizione nel file deployment_spec.yaml per ogni montaggio NFS abilitato.

Nota: Migrate to Containers richiede che i server 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 contenitore sottoposto a 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.

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 Esegui la migrazione ai contenitori.

Di seguito è riportato un esempio di definizioni di 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

Personalizzare i dati dei log scritti in Cloud Logging

In genere, una VM di origine scrive le informazioni in uno o più file di log. Nell'ambito della migrazione della VM, puoi configurare il carico di lavoro sottoposto a migrazione in modo che scriva le informazioni dei log in Cloud Logging.

Nota: le release precedenti di Migrate to Containers supportavano la personalizzazione il logging utilizzando ConfigMap sul cluster dei carichi di lavoro di destinazione, come descritto in Configurazione del logging in Cloud Logging. Questa sezione descrive come utilizzare il file logs.yaml per configurare il logging. Se il file logs.yaml esiste, le impostazioni di logging definite da un ConfigMap vengono ignorate.

Quando generi il piano di migrazione, Migrate to Containers cerca automaticamente i file di destinazione dei log sulla VM di origine. Migrate to Containers scrive quindi 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 logs.yaml del piano di migrazione. Questo file contiene l'elenco dei file di log rilevati sulla 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, vengono scritte le informazioni di log in catalina.out viene automaticamente scritto in Cloud Logging.

Le voci vengono visualizzate su una riga del log nel seguente formato:

DATE TIME APP_NAME LOG_OUTPUT

L'esempio seguente illustra il modulo con una voce di 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 in aggiungi, rimuovi o modifica logPaths voci. Quando generi gli artefatti di migrazione, queste modifiche saranno visibili nel file logs.yaml.

• Modifica logs.yaml dopo aver generato gli artefatti di migrazione per aggiungere, rimuovere o modificare le voci logs.

Il vantaggio della modifica del piano di migrazione è che le modifiche vengono applicate a logs.yaml ogni volta che generi gli elementi. Se modifichi direttamente logs.yaml, quindi, per qualche motivo, rigenerare gli artefatti, dovrai applicare nuovamente le modifiche a logs.yaml.

Imposta probe di integrità v2kServiceManager di Linux

Puoi monitorare il tempo di inattività e lo stato di pronto dei container gestiti specificando nel piano di migrazione del server web Tomcat. Salute il monitoraggio del probe può aiutare a ridurre il tempo di inattività dei container di cui è stata eseguita la migrazione e a fornire un monitoraggio migliore.

Gli stati di integrità sconosciuti possono causare un degrado della disponibilità, un monitoraggio della disponibilità con falsi positivi e una potenziale perdita di dati. Senza un probe di integrità, kubelet può solo assumere l'integrità di un container e inviare a un'istanza di container non ancora pronta. Ciò può causare una perdita di traffico. Kubelet potrebbe anche non rilevare i contenitori in stato di blocco e non riavviarli.

Una sonda di stato funziona eseguendo una piccola istruzione basata su script all'avvio del contenitore. Lo script controlla le condizioni di successo, definite dal tipo di sonda impiegata, in ogni periodo. 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 i probe di attività, di idoneità e di avvio nella documentazione di Kubernetes.

Sono disponibili due tipi di probe da configurare, entrambi sono probe-v1-core definiti in Riferimento probe-v1-core e condividere la stessa funzione dei campi corrispondenti di container-v1-core

• Probe di attività: i probe di attività vengono utilizzati per sapere quando riavviare un container.
  Nota: se un processo nel container può arrestarsi in modo anomalo quando rileva un problema, o non è integro, non è necessario un probe di attività. Kuvlet eseguirà automaticamente l'azione corretta in conformità con il restartPolicy
  del pod.
• Probe di idoneità: i probe di idoneità sono utilizzati per sapere quando un container viene puoi iniziare ad accettare traffico. Per iniziare a inviare traffico a un pod solo quando il probe di idoneità ha esito positivo, specifica un probe di idoneità. Un probe di idoneità può agire in modo simile a un probe di attività. ma un probe di idoneità nelle specifiche indica che un pod verrà avviato senza riceve traffico e inizia a riceverlo solo dopo l'esito positivo del probe.

Dopo il rilevamento, la configurazione del probe viene aggiunta al piano di migrazione. Le sonde possono essere utilizzate nella loro configurazione predefinita, come illustrato di seguito. Per disattivare i controlli, 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 controlli dei servizi sono disattivati. Devi definire quale sottoinsieme di servizi verrà monitorato.

Nota: non tutti i servizi supportano i probe e potrebbero causare la non si avviano.

Esistono quattro modi predefiniti per controllare un container con un probe. Ogni probe deve definiscono 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 dell'uscita è 0.
• grpc: esegue una chiamata di procedura remota utilizzando "gRPC". I controlli "gRPC" sono una funzionalità alpha.
• httpGet: esegue una richiesta GET HTTP all'indirizzo IP del pod su una porta e un percorso specificati. La richiesta è considerata riuscita se il codice di stato è maggiore o uguale a 200 e minore di 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 abilita il metodo di probe exec. Usa manuale configurazione per il tuo piano di migrazione per attivare un altro metodo.

Aggiungere dipendenze esterne per il probe di idoneità, utilizzando al contempo il valore predefinito un probe di attività, la definizione di un probe di idoneità exec e uno script che implementa la logica.

Passaggi successivi

• Scopri come eseguire la migrazione.