Personaliza el plan de migración para VMs de Linux

Antes de ejecutar un plan de migración, debes revisarlo y, de forma opcional, personalizarlo. Los detalles de tu plan de migración se usarán a fin de extraer los artefactos del contenedor de carga de trabajo de la VM de origen y también para generar archivos de implementación de Kubernetes que puedes usar a fin de implementar 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 tener en cuenta antes de ejecutar la migración y generar artefactos de implementación.

Antes de comenzar

En este tema, se supone que ya creaste un plan de migración y que tienes el archivo del plan de migración resultante.

Edita el plan de migración

Después de copiar el sistema de archivos y analizarlo, puedes encontrar el plan de migración en el directorio nuevo 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 de tu plan de migración y los comentarios guías para agregar información según sea necesario. En particular, considera las ediciones en las siguientes secciones.

Especifica el contenido que no se incluirá en la migración

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

El valor del campo filters enumera las rutas que deben excluirse de la migración y que no serán parte de la imagen del contenedor. El valor del campo enumera las reglas del filtro rsync que especifican qué archivos se deben transferir y cuáles se deben omitir. Con un signo menos antes de la ruta y el archivo, se especifica que el elemento de la lista debe excluirse de la migración. La lista se procesa según el orden de las líneas de YAML, y las exclusiones/inclusiones se evalúan en consecuencia.

Obtén más información sobre las reglas de filtro de rsync.

Los archivos que son demasiado grandes para incluirlos en la imagen de Docker se enumeran en el archivo YAML. Esto marcará los archivos que superen los 1 GB para su consideración. Las imágenes de Docker que son demasiado grandes o mayores que 15 GB, corren el riesgo de fallar durante la migración.

Puedes editar la lista YAML para agregar o quitar rutas. Consulta un ejemplo de YAML a continuación, que incluye ejemplos de exclusiones, así como notificaciones para archivos grandes y dispersos. Sigue las instrucciones intercaladas para realizar una de las siguientes acciones:

• Para excluir las carpetas detectadas, quita los comentarios y colócalas en la sección de filtros globales.
• Para mover las carpetas detectadas a un volumen persistente, quita los comentarios y colócalas en la sección de la carpeta de datos.

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

  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)

Establece el nombre de la imagen del contenedor

El valor del campo name en la sección image define el nombre de la imagen creada a partir de una VM migrada que se usa para el contenedor. Si prefieres usar un nombre diferente, puedes cambiar este valor.

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

Personaliza la lista de servicios

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

Además de los servicios que Migrate to Container inhabilita de forma automática, puedes inhabilitar otros servicios de esta forma:

• Migrate to Containers descubre de forma automática los servicios que puedes inhabilitar y los enumera en el plan de migración. Es posible que estos servicios, como ssh o un servidor web, no sean necesarios en la carga de trabajo migrada, pero depende de ti tomar esa decisión. Si es necesario, edita el plan de migración para inhabilitar estos servicios.

• Migrate to Containers no enumera todos los servicios que se ejecutan en la VM de origen. Por ejemplo, omite los servicios relacionados con el sistema operativo. De manera opcional, puedes editar el plan de migración para agregar tu propia lista de servicios que deseas inhabilitar en el contenedor migrado.

El campo systemServices especifica la lista de servicios que Migrate to Container descubre. 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, configura enabled como false.

Migrate to Containers no enumera todos los servicios que se ejecutan en la VM de origen, como los servicios relacionados con el sistema operativo. También puedes agregar servicios adicionales a la lista. Por ejemplo, para inhabilitar service2 y el servicio cron:

    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. En este archivo, se enumeran los servicios de contenedores que se inhabilitarán según la configuración en el 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 la lista de servicios inhabilitados más adelante:

• Edita la lista de servicios en el plan de migración.
• Ejecuta la migración para volver a generar los artefactos de migración, lo que incluye un blocklist.yaml actualizado.

Como alternativa, después de ejecutar una migración para generar los artefactos de migración, puedes editar el archivo blocklist.yaml directamente y, luego, compilar e implementar la imagen del contenedor con Skaffold.

Personaliza los extremos de servicio

El plan de migración incluye el array endpoints que define los puertos y protocolos que se usarán para crear los Services de Kubernetes que proporciona la carga de trabajo migrada. Puedes agregar, editar o borrar definiciones de extremos para personalizar el plan de migración.

Para recuperar los puertos de extremos, verifica los programas que escuchan puertos:

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

Para cada extremo de Service, agrega la siguiente definición al plan de migración:

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

Dónde:

• PORT_NUMBER especifica el número de puerto del contenedor al que se enrutan las solicitudes al servicio.
• PORT_PROTOCOL especifica el protocolo de puerto, como HTTP, HTTPS o TCP. Consulta Protocolos compatibles para obtener la lista completa de protocolos.
• PORT_NAME especifica el nombre que se usa para acceder al extremo de Service. Migrate to Containers genera un PORT_NAME único para cada definición de extremo generado.

Por ejemplo, Migrate to Containers detecta los siguientes extremos:

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

Para configurar 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 Service. Los nombres generados son compatibles con las convenciones de nombres de Kubernetes y son únicos dentro del plan de migración. Por ejemplo, el plan de migración anterior crea un Service que se orienta a Nginx en el puerto 80 a través de HTTP.

En el caso de los nombres duplicados, Migrate to Containers agrega un sufijo de contador. Por ejemplo, si Nginx está asociado a dos puertos, agrega el sufijo -2 a 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 para cada extremo.

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: {}

Personaliza las activaciones de NFS

Migrate to Containers incluye activaciones de NFS en el plan de migración generado. Esta información se recopila del archivo fstab y se escribe en el array nfsMounts en el plan de migración. Puedes agregar o editar definiciones de puntos de activación de NFS para personalizar el plan de migración.

Nota: Las entradas del array nfsMounts están inhabilitadas de forma predeterminada. Debes habilitarlas si deseas que Migrate for Anthos genere entradas en el archivo deployment_spec.yaml para cada activación de NFS.

Cuando generes el plan de migración, Migrate to Containers realiza estas acciones:

• Ignora las activaciones de NFS para /sys y /dev.
• Ignora las activaciones de NFS con un tipo que no sea nfs ni nfs4.

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

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

Dónde:

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

Por ejemplo, en la siguiente entrada de 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

A fin de configurar Migrate to Containers para que procese entradas en el arreglo nfsMounts, configura enabled como true para la entrada mountPoint. Puedes habilitar una, algunas o todas las entradas mountPoints, editarlas o agregar tus propias entradas.

Cuando ejecutas una migración para generar los artefactos de migración, Migrate to Containers crea una definición de volúmenes y volumeMounts, y una definición de PersistentVolume y PersistentVolumeClaim en el archivo deployment_spec.yaml para cada activación de NFS habilitada.

Nota: Migrate to Containers requiere que se pueda acceder a los servidores NFS desde el clúster de implementación que aloja la carga de trabajo del contenedor migrado. Sin embargo, Migrate to Containers no valida esa conectividad. Un contenedor migrado con un problema de conectividad no se puede iniciar y es posible que debas editar el archivo deployment_spec.yaml para solucionar el problema. Consulta Accede a instancias de Filestore con el controlador de CSI de Filestore para obtener más información.

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

En el ejemplo anterior, el valor de name es un identificador único que genera 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

Personaliza los datos de registro escritos en Cloud Logging

Por lo general, una VM de origen escribe información en uno o más archivos de registro. Como parte de la migración de la VM, puedes configurar la carga de trabajo migrada para escribir esa información de registro en Cloud Logging.

Nota: Las versiones anteriores de Migrate to Containers admiten la personalización del registro mediante un ConfigMap en el clúster de carga de trabajo de destino, como se describe en Configura registros en Cloud Logging. En esta sección, se describe cómo usar el archivo logs.yaml a fin de configurar el registro. Si el archivo logs.yaml existe, se ignora la configuración de registro definida por un ConfigMap

.

Cuando generas el plan de migración, Migrate for Containers busca de forma automática los archivos de destino de registro en la VM de origen. Luego, migra a contenedores y escribe información sobre esos 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, de la definición de logsPath anterior, logs.yaml contiene lo siguiente:

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

En este ejemplo, cuando implementas la carga de trabajo migrada, la información de registro escrita en catalina.out se escribe de forma automática 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 ilustra el formato 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 agregar, quitar o editar entradas logPaths. Cuando generas los artefactos de migración, estas ediciones se reflejan en el archivo logs.yaml.

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

La ventaja de editar el plan de migración es que tus ediciones se reflejan en logs.yaml cada vez que generas los artefactos. Si editas logs.yaml directamente, y vuelves a generar los artefactos por alguna razón, debes volver a aplicar tus ediciones a logs.yaml.

Configura sondeos de estado de Linux v2kServiceManager

Puedes supervisar el tiempo de inactividad y el estado de preparación de los contenedores administrados si especificas sondeos en el plan de migración del servidor web de Tomcat. La supervisión del sondeo de estado puede ayudar a reducir el tiempo de inactividad de los contenedores migrados y proporcionar una mejor supervisión.

Los estados desconocidos pueden causar una degradación de la disponibilidad, una supervisión de disponibilidad falso positivo y una posible pérdida de datos. Sin un sondeo de estado, kubelet solo puede suponer el estado de un contenedor y puede enviar tráfico a una instancia de contenedor que no esté lista. Esto puede provocar la pérdida de tráfico. Es posible que kubelet tampoco detecte los contenedores que están en estado inmovilizado y no los reiniciará.

Un sondeo de estado ejecuta una declaración con una secuencia de comandos pequeña cuando se inicia el contenedor. La secuencia de comandos verifica las condiciones correctas, que se definen según el tipo de sondeo que se usa, en cada período. El período se define en el plan de migración mediante un campo periodSeconds. Puedes ejecutar o definir estas secuencias de comandos de forma manual.

Para obtener más información sobre los sondeos de kubelet, consulta Configura sondeos de funcionamiento, inicio y preparación en la documentación de Kubernetes.

Hay dos tipos de sondeos disponibles para configurar, ambos sondeos son probe-v1-core definido en la referencia de probe-v1-core, y comparten la misma función que los campos correspondientes de container-v1-core

• Sondeo de funcionamiento: los sondeos de funcionamiento se usan para saber cuándo reiniciar un contenedor.
  Nota: Si un proceso de tu contenedor puede fallar por sí solo cuando se encuentra con un problema o está en mal estado, no es necesario que tengas un sondeo de funcionamiento. Kubelet realizará automáticamente la acción correcta de acuerdo con restartPolicy del Pod.
• Sondeo de preparación: los sondeos de preparación se usan para saber cuándo un contenedor está listo para comenzar a aceptar tráfico. Para comenzar a enviar tráfico a un Pod solo cuando un sondeo es correcto, especifica un sondeo de preparación. Un sondeo de preparación puede actuar de manera similar de funcionamiento, pero un sondeo de preparación en las especificaciones indica que un Pod se iniciará sin recibir tráfico y solo comenzará a recibir tráfico después de que el sondeo tenga éxito.

Después de la detección, la configuración del sondeo se agrega al plan de migración. Los sondeos se pueden usar en su configuración predeterminada, como se muestra a continuación. Para inhabilitar los sondeos, quita 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, el sondeo de servicio está inhabilitado. Debes definir qué subconjunto de servicios se supervisará.

Nota: No todos los servicios admiten el sondeo y pueden hacer que un contenedor no se inicie.

Hay cuatro formas predefinidas de verificar un contenedor mediante un sondeo. Cada sondeo debe definir exactamente uno de estos cuatro mecanismos:

• exec: ejecuta un comando especificado dentro del contenedor. La ejecución se considera exitosa si el código de estado de salida es 0.
• grpc: realiza una llamada de procedimiento remoto mediante “gRPC”. Los sondeos de "gRPC" son una función Alfa.
• httpGet: realiza una solicitud GET HTTP a la dirección IP del Pod en un puerto y una ruta específicos. La solicitud se considera exitosa si el código de estado es mayor o igual que 200 y menor que 400.
• tcpSocket: realiza una verificación de 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.

Si deseas agregar dependencias externas para el sondeo de preparación, mientras usas el sondeo en funcionamiento predeterminado, define un sondeo de preparación en ejecución y una secuencia de comandos que implemente la lógica.

¿Qué sigue?

• Obtén información sobre cómo ejecutar la migración.