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 Kubernetes che puoi utilizzare per eseguire il deployment dell'immagine container in altri cluster, ad esempio un cluster di produzione.

Questa sezione 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 una migrazione e disponga del file del piano di migrazione risultante.

Modifica il piano di migrazione

Puoi modificare il piano di migrazione utilizzando lo strumento migctl o la console Google Cloud.

migctl

Devi scaricare il piano di migrazione prima di poterlo modificare:

Scarica il piano di migrazione. Il piano di migrazione dei carichi di lavoro Linux è rappresentato da LinuxMigrationCommonSpec:
```
migctl migration get my-migration
```
Modifica il piano di migrazione scaricato, my-migration.yaml, in un editor di testo.
Una volta apportate le modifiche, salva e carica il piano di migrazione rivisto:
```
migctl migration update my-migration --main-config my-migration.yaml
```
Ripeti questi passaggi se sono necessarie ulteriori modifiche.

Console

Modifica il piano di migrazione nella console Google Cloud utilizzando l'editor YAML. Il piano di migrazione dei carichi di lavoro Linux è rappresentato dal CRD LinuxMigrationCommonSpec:

Apri la pagina Migrate to Containers nella console Google Cloud.

Vai alla pagina Migrate to Containers.
Fai clic sulla scheda Migrazioni per visualizzare una tabella contenente le migrazioni disponibili.
Nella riga della migrazione che ti interessa, seleziona il nome della migrazione per aprire la scheda Dettagli.
Seleziona la scheda YAML.

Nota: puoi anche selezionare Scarica piano di migrazione per scaricare una copia locale.
Modifica il piano di migrazione in base alle esigenze.
Al termine delle modifiche, puoi:
1. Salva il piano di migrazione. Dovrai quindi eseguire la migrazione manualmente per generare gli artefatti di migrazione. Utilizza la procedura descritta in Esecuzione di una migrazione.
2. Salva e genera gli artefatti. Esegui la migrazione utilizzando le modifiche per generare gli artefatti di migrazione. Il processo è lo stesso descritto in Esecuzione di una migrazione. Puoi quindi monitorare la migrazione come descritto in Monitorare una migrazione.

CRD

Devi scaricare il piano di migrazione, modificarlo e applicarlo. Il piano di migrazione dei carichi di lavoro Linux è rappresentato dal CRD LinuxMigrationCommonSpec:

Prendi il nome di AppXGenerateArtifactsFlow:
```
kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration
```
Il pattern di denominazione viene restituito sotto forma di appx-generateartifactsflow-id.

Scarica il piano di migrazione per nome e scrivi in un file denominato my-plan.yaml:

kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml

Modifica il piano di migrazione in base alle esigenze.

Applica il file:

kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id

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.

Per ulteriori informazioni, consulta la sezione INCLUDE/ESCLUDI REGOLE DI MODIFICHE della pagina di manuale rsync

I file troppo grandi per essere inclusi nell'immagine Docker verranno 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. Vedi un esempio YAML di seguito, che include esclusioni di esempio, nonché notifiche per file sparsi e di grandi dimensioni. Segui le indicazioni incorporate per:

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.

Potresti anche prendere in considerazione l'esclusione o lo spostamento dei file sparsi rilevati nello 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 image definisce i nomi e le posizioni di due immagini create da una VM di cui è stata eseguita la migrazione. Se preferisci utilizzare altri nomi, puoi modificare questi valori.

Durante la migrazione, Migrate to Containers copia (per impostazione predefinita) i file e le directory che rappresentano il carico di lavoro di migrazione in Container Registry per utilizzarli durante la migrazione. Il processo di migrazione adatta il carico di lavoro estratto a un'immagine eseguibile su GKE.

Migrate to Containers conserva i file e le directory della VM originale (nel percorso base) nel registro. Questa immagine funziona come un livello base non eseguibile che include i file dei carichi di lavoro estratti, che vengono poi combinati con il livello del software di runtime Migrate to Containers per creare un'immagine container eseguibile.

L'utilizzo di livelli separati semplifica gli aggiornamenti successivi all'immagine container consentendo aggiornamenti separati al livello base o al livello software Migrate to Containers, se necessario.

Questa immagine non è eseguibile, ma consente a Migrate to Containers di aggiornare il container da quello originale quando esegui l'upgrade di Migrate to Containers.

I valori dei campi base e name specificano le immagini create nel Registro di sistema.

base - Nome dell'immagine creata dai file e dalle directory VM copiati dalla piattaforma di origine. Questa immagine non è eseguibile su GKE perché non è stata adattata per il deployment in quel livello.
name: nome dell'immagine eseguibile utilizzata per il container. Questa immagine contiene sia i contenuti della VM di origine sia il runtime di Migrate to Containers, che ne consente l'esecuzione.

        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "centos-mini-non-runnable-base"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "centos-mini"

Per impostazione predefinita, a questi valori viene applicato automaticamente un tag corrispondente al timestamp della migrazione. Questo tag ha il seguente formato:

MM-DD-YYYY--hh:mm:ss

Per applicare un tag personalizzato, sostituendo quello predefinito, modifica il CRD e aggiungilo come illustrato di seguito:

        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "centos-mini-non-runnable-base:tag"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "centos-mini:tag"

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, inclusi un file blocklist.yaml, un file deployment_spec.yaml e un Dockerfile aggiornati.

In alternativa, dopo aver eseguito una migrazione per generare gli artefatti di migrazione, puoi modificare direttamente il file blocklist.yaml, quindi ricreare l'immagine container ed eseguirne il push. Ad esempio:

Aggiorna il file blocklist.yaml.
Ricrea ed esegui il push dell'immagine container.

Il modo in cui ricrei ed esegui il push dell'immagine container dipende dall'ambiente di build. Puoi utilizzare:
1. gcloud per ricreare l'immagine ed eseguirne il push in Container Registry come descritto in Guida rapida: creazione.
2. docker build come descritto in Creare ed eseguire l'immagine.
Dopo aver ricreato ed eseguito il push della nuova immagine, apri il file deployment_spec.yaml in un editor per aggiornare la posizione dell'immagine:
```
spec:
 containers:
   - image: new-image-location
```
Ad esempio, new-image-location potrebbe essere my-new-image:v1.0 se hai utilizzato gcloud per ricreare l'immagine ed eseguirne il push su Container Registry.

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 ogni endpoint del 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 o nfs4.

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 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 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.

Nota: se un processo nel tuo container riesce ad arrestarsi in modo anomalo quando rileva un problema o non è integro, non è necessario un probe di attività. Il kubelet eseguirà automaticamente l'azione corretta in base alle restartPolicy del pod.

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.

v2kServiceManager: true
deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - gamma
        - /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.