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 sección, 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 una migración y que tienes el archivo del plan de migración resultante.

Edita el plan de migración

Puedes editar el plan de migración con la herramienta migctl o la consola de Google Cloud.

migctl

Debes descargar el plan de migración para poder editarlo:

  1. Descarga el plan de migración. El plan de migración de las cargas de trabajo de Linux se representa con LinuxMigrationCommonSpec:

    migctl migration get my-migration

  2. Edita el plan de migración descargado, my-migration.yaml, en un editor de texto.

  3. Cuando completes tus cambios, guarda y sube el plan de migración revisado:

    migctl migration update my-migration --main-config my-migration.yaml

  4. Repite estos pasos si se necesitan más cambios.

Consola

Edita el plan de migración en la consola de Google Cloud con el editor de YAML. El plan de migración de las cargas de trabajo de Linux se representa con la CRD de LinuxMigrationCommonSpec:

  1. Abre la página Migrate to Containers en la consola de Google Cloud.

    Ir a la página Migrate to Containers

  2. Haz clic en la pestaña Migraciones para ver una tabla con las migraciones disponibles.

  3. En la fila de la migración deseada, selecciona el Nombre de la migración para abrir la pestaña Detalles.

  4. Selecciona la pestaña YAML.

  5. Edita el plan de migración según sea necesario.

  6. Cuando termines de editar, puedes optar por una de las siguientes acciones:

    1. Guarda el plan de migración. Luego, deberás ejecutar la migración de forma manual para generar los artefactos de migración. Usa el procedimiento que se muestra en Ejecuta una migración.

    2. Guarda y genera los artefactos. Ejecuta la migración mediante tus ediciones para generar los artefactos de migración. El proceso es el mismo que se describe en Ejecuta una migración. Luego, puedes supervisar la migración como se describe en Supervisa una migración.

CRD

Debes descargar el plan de migración, editarlo, y aplicarlo. El plan de migración de las cargas de trabajo de Linux se representa con la CRD de LinuxMigrationCommonSpec:

  1. Obtén el nombre de AppXGenerateArtifactsFlow:

    kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration

    El patrón de nombres se muestra en el formato appx-generateartifactsflow-id.

  2. Obtén el plan de migración por nombre y escribe en un archivo llamado my-plan.yaml:

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

  3. Edita el plan de migración según sea necesario.

  4. Aplica el siguiente archivo:

    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

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.

Para obtener más información, consulta la sección sobre INCLUSIÓN Y EXCLUSIÓN DE REGLAS DE PATRONES, en la página del manual de rsync.

Los archivos que son demasiado grandes para incluirlos en la imagen de Docker se enumerarán 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 considerar 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 image define los nombres y las ubicaciones de dos imágenes creadas a partir de una VM migrada. Si prefieres usar otros nombres, puedes cambiar estos valores.

Durante la migración, Migrate to Containers copia los archivos y directorios que representan tu carga de trabajo de migración a Container Registry (según la configuración predeterminada) para usarlos durante la migración. En el proceso de migración, se adapta la carga de trabajo extraída a una imagen que se pueda ejecutar en GKE.

Migrate to Containers conserva los archivos y directorios de la VM original (en la ruta base) en el registro. Esta imagen funciona como una capa base no ejecutable que incluye los archivos de carga de trabajo extraídos, y que, luego, se combinan con la capa de software del entorno de ejecución de Migrate to Containers para compilar una imagen de contenedor ejecutable.

El uso de capas separadas simplifica las actualizaciones posteriores de la imagen del contenedor, ya que permite actualizar de manera independiente la capa base o la capa de software de Migrate to Containers, según sea necesario.

Esta imagen no se puede ejecutar, pero permite que Migrate for Containers actualice el contenedor desde el original cuando se actualiza Migrate to Containers.

Los valores de campo base y name especifican las imágenes creadas en el registro.

  • base: Nombre de la imagen que se crea a partir de los archivos y directorios de la VM copiados desde la plataforma de origen. Esta imagen no se puede ejecutar en GKE porque no se adaptó para su implementación allí.
  • name: Nombre de la imagen ejecutable que se usa para el contenedor. En esta imagen, se incluyen el contenido de la VM de origen y el entorno de ejecución de Migrate to Containers, que permite que se ejecute.
        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"

De forma predeterminada, una etiqueta que corresponde a la marca de tiempo de la migración se aplica automáticamente a estos valores. Esta etiqueta tiene el siguiente formato:

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

Para aplicar tu propia etiqueta, anula la etiqueta predeterminada, edita el CRD y agrégalo como se muestra a continuación:

        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"

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 regenerar los artefactos de migración, lo que incluye un archivo blocklist.yaml actualizado, un archivo deployment_spec.yaml y un Dockerfile.

De forma alternativa, después de ejecutar una migración para generar los artefactos de migración, puedes editar el archivo blocklist.yaml directamente y, luego, volver a compilar y enviar la imagen de contenedor. Por ejemplo:

  1. Actualiza el archivo blocklist.yaml:

  2. Vuelve a compilar y envía la imagen de contenedor.

    La forma de volver a compilar y enviar la imagen de contenedor depende del entorno de compilación. Puedes usar:

    1. gcloud para volver a compilar la imagen y enviarla a Container Registry como se describe en Guía de inicio rápido: compila.
    2. docker build como se describe en Compila y ejecuta tu imagen.

  3. Después de volver a compilar y enviar la imagen nueva, abre el archivo deployment_spec.yaml en un editor para actualizar la ubicación de la imagen:

    spec:
 containers:
   - image: new-image-location

    Por ejemplo, new-image-location podría ser my-new-image:v1.0 si usaste gcloud para volver a compilar la imagen y enviarla a Container Registry.

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 cada extremo de Service, agrega la siguiente definición al plan de migración:

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

Aquí:

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

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

Aquí:

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

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.

.

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.

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

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

De forma predeterminada, el sondeo de servicio está inhabilitado. Debes definir qué subconjunto de servicios se supervisará.

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 de capacidad de respuesta predeterminado, define un sondeo de funcionamiento y una secuencia de comandos que implemente la lógica.

¿Qué sigue?