Personalizzare 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 gli elementi del 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 del 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 gli 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.

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

Esamina i dettagli del piano di migrazione e i commenti guida per aggiungere le informazioni necessarie. Nello specifico, valuta la possibilità di apportare modifiche 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 questo filtro.

Il valore del campo filters elenca i percorsi che devono essere esclusi dalla migrazione e che non faranno parte dell'immagine del contenitore. Il valore del campo elenca le regole di 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ù sulle regole di filtro rsync.

I file troppo grandi per essere inclusi nell'immagine Docker sono elencati 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 rischiano di non riuscire 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 i commenti e collocandole nella sezione della cartella dei dati.

Puoi anche escludere o spostare i 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 name nella sezione image definisce il nome dell'immagine creata da una VM di cui è stata eseguita la migrazione e utilizzata per il contenitore. 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 dei servizi

Per impostazione predefinita, Migrate to Containers disattiva i servizi non necessari su una VM quando esegui la migrazione a un container. A volte questi servizi possono causare problemi con il contenitore di cui è stata eseguita la migrazione o non sono necessari in un contesto del contenitore.

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

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

• Migrate to Containers non elenca tutti i servizi in esecuzione sulla VM di origine. Ad esempio, omette i servizi relativi al sistema operativo. Se vuoi, puoi modificare il piano di migrazione per aggiungere il tuo elenco di servizi da disattivare nel contenitore sottoposto a 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 correlati 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 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 di 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 gli elementi di migrazione, puoi modificare direttamente il file blocklist.yaml e poi creare e implementare l'immagine del container utilizzando Skaffold.

Personalizzare 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 sottoposto a 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 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. Esegui 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.

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, Migrate to Containers 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 nell'array nfsMounts nel piano di migrazione. Puoi aggiungere o modificare le definizioni dei punti di montaggio NFS per personalizzare il piano di migrazione.

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 eventuali 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 elementi della migrazione, Migrate to Containers crea una definizione di volumes 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 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.

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 le informazioni su questi 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 logs.yaml file dal 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 sottoposto a migrazione, le informazioni dei log scritte in catalina.out vengono scritte automaticamente in Cloud Logging.

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

DATE TIME APP_NAME LOG_OUTPUT

L'esempio seguente mostra 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 per aggiungere, rimuovere o modificare le voci logPaths. Quando generi gli elementi della migrazione, queste modifiche vengono applicate al 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 artefatti. Se modifichi direttamente logs.yaml, poi rigeneri gli elementi per qualche motivo, devi applicare nuovamente le modifiche a logs.yaml.

Impostare i probe di integrità di v2kServiceManager Linux

Puoi monitorare il tempo di riposo e lo stato di disponibilità dei container gestiti specificando le sonde nel piano di migrazione del server web Tomcat. Il monitoraggio dei probe di salute può contribuire a ridurre i tempi di inattività dei container sottoposti a 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 presumere l'integrità di un contenitore e potrebbe inviare traffico a un'istanza del contenitore non 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.

Esistono due tipi di sonde disponibili per la configurazione, entrambe sono probe-v1-core definite in documentazione di riferimento di 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 riavviare un container.
  del pod.
• Probe di idoneità: i probe di idoneità vengono utilizzati per sapere quando un container è pronto per iniziare ad accettare il traffico. Per iniziare a inviare traffico a un pod solo quando un probe va a buon fine, specifica un probe di idoneità. Un probe di idoneità può funzionare in modo simile a un probe di attività, ma un probe di idoneità nelle specifiche indica che un pod verrà avviato senza ricevere traffico e inizierà a ricevere traffico solo dopo il completamento del probe.

Dopo la scoperta, la configurazione della sonda viene aggiunta al piano di migrazione. I sensori possono essere utilizzati nella configurazione predefinita, come mostrato 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.

Esistono quattro modi predefiniti per controllare un contenitore utilizzando una sonda. Ogni sonda deve definire esattamente uno di questi quattro meccanismi:

• exec: esegue un comando specificato all'interno del container. L'esecuzione è considerata riuscita se il codice di stato di 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 sull'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 execscansione. Utilizza la configurazione manuale per il piano di migrazione per attivare un altro metodo.

Per aggiungere dipendenze esterne per il probe di idoneità, utilizzando contemporaneamente il probe di attività predefinito, definisci un probe di idoneità all'esecuzione e uno script che implementi la logica.

Passaggi successivi

• Scopri come eseguire la migrazione.