Personalizar el plan de migración de máquinas virtuales Linux

Antes de ejecutar un plan de migración, debes revisarlo y, si quieres, personalizarlo. Los detalles de tu plan de migración se usan para extraer los artefactos del contenedor de la carga de trabajo de la VM de origen, así como para generar archivos de implementación de Kubernetes que puedes usar para desplegar la imagen del contenedor en otros clústeres, como un clúster de producción.

En esta página se describe el contenido del plan de migración y los tipos de personalizaciones que puedes plantearte antes de ejecutar la migración y generar artefactos de implementación.

Antes de empezar

En este tema se presupone que ya has creado un plan de migración y que tienes el archivo correspondiente.

Editar el plan de migración

Una vez que haya copiado el sistema de archivos y lo haya analizado, podrá encontrar el plan de migración en el nuevo directorio que se crea en la ruta de salida especificada: ANALYSIS_OUTPUT_PATH/config.yaml.

Edita el plan de migración según sea necesario y guarda los cambios.

Revisa los detalles del plan de migración y los comentarios para añadir información según sea necesario. En concreto, te recomendamos que hagas cambios en las siguientes secciones.

Especificar el contenido que se va a excluir de la migración

De forma predeterminada, Migrate to Containers excluye el contenido típico de las máquinas virtuales que no es relevante en el contexto de GKE. Puedes personalizar ese filtro.

El valor del campo filters muestra las rutas que se deben excluir de la migración y que no formarán parte de la imagen del contenedor. El valor del campo muestra una lista de reglas de filtro de rsync que especifican qué archivos se deben transferir y cuáles se deben omitir. Si se antepone un signo menos a cada ruta y archivo, se especifica que el elemento de la lista se debe excluir de la migración. La lista se procesa según el orden de las líneas del archivo YAML y las exclusiones o inclusiones se evalúan en consecuencia.

Más información sobre las reglas de filtro de rsync

Los archivos que son demasiado grandes para incluirse en la imagen de Docker se indican en el archivo YAML. De esta forma, se marcarán los archivos que tengan un tamaño superior a 1 GB para que los tengas en cuenta. Las imágenes de Docker que sean demasiado grandes (más de 15 GB) pueden fallar durante la migración.

Puedes editar la lista YAML para añadir o quitar rutas. A continuación, se muestra un ejemplo de archivo YAML que incluye exclusiones y notificaciones de archivos grandes y dispersos. Sigue las instrucciones que aparecen en pantalla para realizar una de las siguientes acciones:

  • Excluye las carpetas detectadas quitando el comentario y colocándolas en la sección de filtros globales.
  • Mueve las carpetas detectadas a un volumen persistente eliminando los comentarios y colocándolas en la sección de la carpeta de datos.

También puedes excluir o mover los archivos dispersos detectados de la misma forma.

  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)

Definir el nombre de la imagen de contenedor

El valor del campo name de la sección image define el nombre de la imagen creada a partir de una VM migrada que se utiliza en el contenedor. Puedes cambiar este valor si prefieres usar otro nombre.

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

Personalizar la lista de servicios

De forma predeterminada, Migrate to Containers inhabilita los servicios innecesarios en una VM cuando la migras a un contenedor. Estos servicios a veces pueden causar problemas con el contenedor migrado o no son necesarios en un contexto de contenedor.

Además de los servicios que inhabilita automáticamente Migrate to Containers, puedes inhabilitar otros servicios de forma opcional:

  • Migrate to Containers detecta automáticamente los servicios que puedes inhabilitar (opcionalmente) y los incluye en el plan de migración. Es posible que estos servicios, como ssh o un servidor web, no sean necesarios en tu carga de trabajo migrada, pero tú decides si los necesitas o no. Si es necesario, edita el plan de migración para inhabilitar estos servicios.

  • Migrate to Containers no muestra todos los servicios que se ejecutan en la VM de origen. Por ejemplo, omite los servicios relacionados con el sistema operativo. También puedes editar el plan de migración para añadir tu propia lista de servicios que quieras inhabilitar en el contenedor migrado.

El campo systemServices especifica la lista de servicios descubiertos por Migrate to Containers. Por ejemplo:

    systemServices:
    - enabled: true|false
      name: service-name
      probed: true|false
    - enabled: true|false
      name: service-name
      probed: true|false
      ...

Para inhabilitar un servicio, asigna el valor false a enabled.

Migrate to Containers no muestra todos los servicios que se ejecutan en la VM de origen, como los servicios relacionados con el sistema operativo. También puedes añadir más servicios a la lista. Por ejemplo, para inhabilitar service2 y el servicio cron, utiliza este código:

    systemServices:
    - enabled: true
      name: service1
      probed: false
    - enabled: false
      name: service2
      probed: false
    - enabled: false
      name: cron
      probed: false

Cuando ejecutas una migración para generar los artefactos de migración, Migrate to Containers crea el archivo blocklist.yaml. Este archivo muestra los servicios del contenedor que se van a inhabilitar en función de los ajustes del plan de migración. Por ejemplo:

service_list:
- name: disabled-services
  services:
  # Because you used systemServices above to disabled service2 and cron:
  - service2
  - cron

Para modificar más adelante la lista de servicios inhabilitados, sigue estos pasos:

  • Edita la lista de servicios del plan de migración.
  • Ejecuta la migración para volver a generar los artefactos de migración, incluido un blocklist.yaml actualizado.

También puedes editar directamente el archivo blocklist.yaml después de ejecutar una migración para generar los artefactos de migración y, a continuación, compilar y desplegar la imagen de contenedor con Skaffold.

Personalizar los endpoints de servicio

El plan de migración incluye la matriz endpoints que define los puertos y protocolos que se usan para crear los servicios de Kubernetes proporcionados por la carga de trabajo migrada. Puede añadir, editar o eliminar definiciones de endpoint para personalizar el plan de migración.

Para obtener los puertos de los endpoints, comprueba los programas que están escuchando puertos:

sudo netstat --programs --listening --tcp --udp [--sctp]

Añade la siguiente definición al plan de migración de cada punto final de servicio:

    endpoints:
    - port: PORT_NUMBER
      protocol: PORT_PROTOCOL
      name: PORT_NAME

Donde:

  • PORT_NUMBER especifica el número de puerto del contenedor al que se dirigen las solicitudes al servicio.
  • PORT_PROTOCOL especifica el protocolo del puerto, como HTTP, HTTPS o TCP. Consulta la lista completa de protocolos admitidos.
  • PORT_NAME especifica el nombre que se usa para acceder al endpoint del servicio. Migrar a contenedores genera un PORT_NAME único para cada definición de endpoint generada.

Por ejemplo, Migrate to Containers detecta los siguientes endpoints:

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 6379
      protocol: TCP
      name: backend-server-redis

Para definir el valor de la propiedad name, Migrate to Containers combina el nombre de la VM de origen, backend-server en este ejemplo, con el nombre del programa del servicio. Los nombres generados son compatibles con las convenciones de nomenclatura de Kubernetes y son únicos en el plan de migración. Por ejemplo, el plan de migración anterior crea un servicio que tiene como destino Nginx en el puerto 80 a través de HTTP.

Si hay nombres duplicados, Migrate to Containers añade un sufijo de contador. Por ejemplo, si Nginx está asociado a dos puertos, añade el sufijo -2 al name en la segunda definición:

  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

Cuando ejecutas una migración para generar los artefactos de migración, Migrate to Containers crea una definición de Service en el archivo deployment_spec.yaml de cada endpoint.

Por ejemplo, a continuación se muestra una definición de Service en el archivo 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: {}

Personalizar montajes NFS

Migrate to Containers incluye los montajes de NFS en el plan de migración generado. Esta información se recoge del archivo fstab y se escribe en la matriz nfsMounts del plan de migración. Puede añadir o editar definiciones de puntos de montaje NFS para personalizar el plan de migración.

Al generar el plan de migración, Migrate to Containers hace lo siguiente:

  • Ignora los montajes NFS de /sys y /dev.
  • Ignora los montajes de NFS con un tipo distinto de nfs o nfs4.

Cada montaje NFS del plan de migración incluye la dirección IP del servidor y la ruta de montaje local con el siguiente formato:

    nfsMounts:
    - mountPoint: MOUNT_POINT
      exportedDirectory: DIR_NAME
      nfsServer: IP
      mountOptions:
         - OPTION_1
         - OPTION_2
      enabled: false|true

Donde:

  • MOUNT_POINT especifica el punto de montaje obtenido de fstab.
  • DIR_NAME especifica el nombre del directorio compartido.
  • IP especifica la dirección IP del servidor que aloja el punto de montaje.
  • OPTION_N especifica las opciones extraídas de fstab para el punto de montaje.

Por ejemplo, para la siguiente entrada en 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 siguiente entrada en el plan de migración:

    nfsMounts:
    - mountPoint: /mnt/test
      exportedDirectory: /vol1
      nfsServer: 10.49.232.26
      mountOptions:
         - rw
         - hard
      enabled: false

Para configurar Migrate to Containers de forma que procese las entradas de la matriz nfsMounts, asigna el valor true a enabled en la entrada mountPoint. Puedes habilitar una, algunas o todas las entradas mountPoints, editarlas o añadir las tuyas.

Cuando ejecutas una migración para generar los artefactos de migración, Migrate to Containers crea una definición de volumes y volumeMounts y una definición de PersistentVolume y PersistentVolumeClaim en el archivo deployment_spec.yaml para cada montaje de NFS habilitado.

Por ejemplo, a continuación se muestra una definición de volumeMounts en el archivo 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

Donde el valor de name es un identificador único generado por Migrate to Containers.

A continuación se muestran ejemplos de definiciones de PersistentVolumeClaim y PersistentVolume en el archivo 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

Personalizar los datos de registro escritos en Cloud Logging

Normalmente, una VM de origen escribe información en uno o varios archivos de registro. Como parte de la migración de la VM, puedes configurar la carga de trabajo migrada para que escriba esa información de registro en Cloud Logging.

Cuando generas el plan de migración, Migrate to Containers busca automáticamente los archivos de destino de los registros en la VM de origen. Migrate to Containers escribe información sobre los archivos detectados en el área logPaths del plan de migración:

deployment:
    ...
    logPaths:
    - appName: APP_NAME
      globs:
      - LOG_PATH

Por ejemplo:

deployment:
    ...
    logPaths:
    - appName: tomcat
      globs:
      - /var/log/tomcat*/catalina.out

Cuando generas los artefactos de migración, Migrate to Containers genera el archivo logs.yaml a partir del plan de migración. Este archivo contiene la lista de archivos de registro detectados en la VM de origen. Por ejemplo, en la definición de logsPath anterior, logs.yaml contiene lo siguiente:

logs:
  tomcat:
  - /var/log/tomcat*/catalina.out

En este ejemplo, cuando despliegues la carga de trabajo migrada, la información de registro escrita en catalina.out se escribirá automáticamente en Cloud Logging.

Cada entrada aparece en una línea del registro con el siguiente formato:

DATE TIME APP_NAME LOG_OUTPUT

En el siguiente ejemplo se muestra el formulario con una entrada de Tomcat:

2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output

Para configurar el registro, puedes hacer lo siguiente:

  • Edita el plan de migración antes de generar los artefactos de migración para añadir, quitar o editar entradas de logPaths. Cuando generas los artefactos de migración, estos cambios se reflejan en el archivo logs.yaml.

  • Edita logs.yaml después de generar los artefactos de migración para añadir, quitar o editar entradas de logs.

La ventaja de editar el plan de migración es que los cambios se reflejan en logs.yaml cada vez que generas los artefactos. Si editas logs.yaml directamente y, por algún motivo, vuelves a generar los artefactos, tendrás que volver a aplicar los cambios a logs.yaml.

Configurar comprobaciones de estado de v2kServiceManager de Linux

Para monitorizar el tiempo de inactividad y el estado de disponibilidad de tus contenedores gestionados, especifica sondas en el plan de migración de tu servidor web Tomcat. La monitorización de los sondeos de estado puede ayudar a reducir el tiempo de inactividad de los contenedores migrados y proporcionar una mejor monitorización.

Los estados de salud desconocidos pueden provocar una degradación de la disponibilidad, una monitorización de la disponibilidad con falsos positivos y una posible pérdida de datos. Sin una sonda de estado, kubelet solo puede asumir el estado de un contenedor y puede enviar tráfico a una instancia de contenedor que no esté lista. Esto puede provocar una pérdida de tráfico. Es posible que Kubelet tampoco detecte los contenedores que estén en estado inactivo y no los reinicie.

Una sonda de estado funciona ejecutando una pequeña instrucción de script cuando se inicia el contenedor. La secuencia de comandos comprueba si se cumplen las condiciones, que se definen por el tipo de sonda utilizada, cada periodo. El periodo se define en el plan de migración mediante un campo periodSeconds. Puedes ejecutar o definir estas secuencias de comandos manualmente.

Para obtener más información sobre las comprobaciones de kubelet, consulta Configurar comprobaciones de vivacidad, preparación e inicio en la documentación de Kubernetes.

Hay dos tipos de sondas que se pueden configurar. Ambas se definen como probe-v1-core en la referencia de probe-v1-core y comparten la misma función que los campos correspondientes de container-v1-core.

  • Comprobación de actividad: se usa para saber cuándo reiniciar un contenedor.

    del pod.

  • Sondeo de disponibilidad: se usa para saber cuándo está listo un contenedor para empezar a aceptar tráfico. Para empezar a enviar tráfico a un pod solo cuando una sonda se complete correctamente, especifica una sonda de preparación. Una sonda de preparación puede actuar de forma similar a una sonda de vivacidad, pero una sonda de preparación en las especificaciones indica que un pod se iniciará sin recibir tráfico y solo empezará a recibir tráfico después de que la sonda se complete correctamente.

Una vez descubierto, la configuración de la sonda se añade al plan de migración. Las sondas se pueden usar con su configuración predeterminada, como se muestra a continuación. Para inhabilitar las sondas, elimina la sección probes del archivo 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

De forma predeterminada, todas las comprobaciones de servicios están inhabilitadas. Debes definir qué subconjunto de servicios se monitorizará.

Hay cuatro formas predefinidas de comprobar un contenedor mediante una sonda. Cada sonda debe definir exactamente uno de estos cuatro mecanismos:

  • exec: ejecuta un comando especificado dentro del contenedor. La ejecución se considera correcta si el código de estado de salida es 0.
  • grpc: realiza una llamada a procedimiento remoto mediante `gRPC`. Las sondas `gRPC` son una función alfa.
  • httpGet: realiza una solicitud HTTP GET en la dirección IP del pod en un puerto y una ruta especificados. La solicitud se considera correcta si el código de estado es igual o superior a 200 e inferior a 400.
  • tcpSocket: realiza una comprobación TCP en la dirección IP del pod en un puerto especificado. El diagnóstico se considera correcto si el puerto está abierto.

De forma predeterminada, un plan de migración habilita el método de sondeo exec. Usa la configuración manual de tu plan de migración para habilitar otro método.

Para añadir dependencias externas a la sonda de disponibilidad mientras usas la sonda de actividad predeterminada, define una sonda de disponibilidad de ejecución y una secuencia de comandos que implemente la lógica.

Siguientes pasos