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
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
ninfs4
.
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 archivologs.yaml
.Edita
logs.yaml
después de generar los artefactos de migración para agregar, quitar o editar entradaslogs
.
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.
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á.
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.