Planifica las prácticas recomendadas

En este tema, se ofrecen consejos para las migraciones de aplicaciones a Google Kubernetes Engine (GKE) o GKE Enterprise en función de las migraciones de aplicaciones reales que se realizaron con Migrate to Containers.

La CLI del cliente de descubrimiento de Migration Center o la CLI de mcdc es una herramienta que usas para determinar la idoneidad de la carga de trabajo de VMs para la migración a un contenedor.

Cargas de trabajo recomendadas

Se recomienda Migrate to Containers para ciertos tipos de cargas de trabajo de Linux y Windows, que se detallan a continuación.

Compatibilidad adecuada

Linux

Las aplicaciones que son aptas para la migración mediante Migrate to Containers incluyen las siguientes arquitecturas de aplicación:

• Servidores web o de aplicaciones
• Middleware de lógica empresarial (por ejemplo, Tomcat)
• Pilas de varias VM y varios niveles (por ejemplo, LAMP)
• Bases de datos pequeñas o medianas (por ejemplo, MySQL y PostgreSQL)

Además, las aplicaciones más adecuadas para la migración mediante Migrate to Containers tienen las siguientes características operativas:

• Cargas de trabajo inestables y con ciclos de trabajo bajos
• Entornos de Lab de desarrollo, prueba y entrenamiento
• Servicios de carga baja y siempre activos

En general, la mayoría de las cargas de trabajo de Linux son compatibles con la migración, excepto las que se mencionan de forma explícita a continuación, en Opciones no aptas.

Windows

Las aplicaciones de Windows que son aptas para la migración con Migrate for Anthos incluyen cargas de trabajo que cumplen con las siguientes características:

• IIS 7 o versiones posteriores, ASP.NET con .NET Framework 3.5 o versiones posteriores
• Niveles web y lógicos
• WS2008 R2 o superior

Compatibilidad con el sistema operativo

Migrate to Containers es compatible con estos sistemas operativos de VM.

Opciones no aptas

Linux

En el caso de Linux, las aplicaciones y los servidores que no son aptos para la migración con Migrate to Containers incluyen lo siguiente:

• Bases de datos en memoria grandes y de alto rendimiento
• VM con controladores de kernel especiales (por ejemplo, NFS en modo de kernel)
• Dependencias en hardware específico
• Software con licencias vinculadas a un determinado registro de ID de hardware

Windows

En Windows, las cargas de trabajo sin IIS 7 o versiones posteriores no son compatibles con la migración. Entre otros tipos de aplicaciones que no son adecuados para la migración, se incluyen los siguientes:

• Aplicaciones con dependencias en GPU o TPU
• Aplicaciones de herramientas de redes de bajo nivel
• Aplicaciones de escritorio, RDP y VDI
• Aplicaciones con BYOL

Reglas de acceso a la red y al DNS

Antes de migrar a GKE, asegúrate de comprender los servicios y los recursos de red que usan las cargas de trabajo migradas y asegúrate de que sean accesibles y se puedan direccionar desde la nube privada virtual.

Planifica los nombres de los servicios de Kubernetes

Si las cargas de trabajo dependen del DNS para acceder a los servicios, debes planificar el esquema de espacio de nombres, las políticas de red y los nombres de los servicios de Kubernetes.

La especificación de implementación que generó el proceso de migración contiene un objeto Service sin interfaz gráfica sugerido del tipo “ClusterIP”. “ClusterIP” significa que no hay balanceo de cargas y que hay una sola IP interna del clúster a la que solo se puede acceder desde este. El controlador de extremos de Kubernetes modifica la configuración del DNS para mostrar los registros (direcciones) que apuntan a los pods, que están etiquetados con "app": "app-name" en deployment_spec.yaml.

Nota: Los nombres de los servicios de Kubernetes son más limitados de lo que permite el DNS.

Crea y aplica servicios para las conexiones a pods y contenedores

Después de migrar una carga de trabajo, los nombres de host ya no son aplicables. Para permitir conexiones a las cargas de trabajo, crea y aplica servicios.

Identifica y configura IP y nombres migrados

GKE administra el archivo /etc/hosts. En Migrate to Containers, aún no se automatizó la adaptación del archivo de hosts de la VM de origen a GKE. Los nombres y las IP del archivo de hosts en la VM migrada deben identificarse y configurarse como hostAliases.

Ubica los servicios dependientes en el mismo espacio de nombres

Los servicios que dependen del otro deben estar ubicados en el mismo espacio de nombres de Kubernetes y usar nombres de DNS cortos (por ejemplo, app y db) para comunicarse. Esta configuración también ayuda a replicar varios entornos de aplicaciones, como producción, etapa de pruebas y prueba.

Controla la superficie de acceso con las herramientas de redes de GKE

GKE tiene controles sofisticados de herramientas de redes. Se puede acceder a los pods desde diferentes redes, como la Internet pública, la red de VPC o la red interna del clúster. Esto ofrece la oportunidad de controlar y restringir aún más la superficie de acceso a una carga de trabajo sin la complejidad adicional de administrar las VLAN, los filtros o las reglas de enrutamiento.

Por ejemplo, una aplicación típica de tres niveles tiene niveles de frontend, aplicación y base de datos. Cuando se migra a Google Cloud, el servicio de frontend se configura con un LoadBalancer en la red de VPC. Los otros niveles no son directamente accesibles desde fuera del clúster de GKE. Una política de acceso a la red garantiza que se pueda acceder al servicio de las aplicaciones solo desde los pods de frontend en el interior de la red interna del clúster. Otra política garantiza que se pueda acceder a los pods de la base de datos solo desde los pods de la aplicación.

NFS

Define activaciones de NFS como volúmenes persistentes

Cuando creas el plan de migración, las activaciones de clientes de NFS en la VM de origen se descubren y se agregan de forma automática al plan generado.

Si bien las activaciones se agregan al plan, están inhabilitadas de forma predeterminada. Esto significa que las definiciones de PersistentVolume y PersistentVolumeClaim no se incluyen en el archivo deployment_spec.yaml cuando generas artefactos de migración. Si deseas que Migrate to Containers genere definiciones de PersistentVolume y PersistentVolumeClaim, primero debes editar el plan de migración para habilitar la activación del cliente de NFS.

Consulta Personaliza activaciones de NFS para obtener más información.

Nota: Migrate to Containers requiere que se pueda acceder a las activaciones de 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. Para obtener más información, consulta Accede a las instancias de Filestore con el controlador de CSI de Filestore.

Nota: Si se usa NFS en un vínculo de la VPN, es posible que disminuya el rendimiento debido a la latencia aumentada y el ancho de banda reducido.

Servidores NFS en modo de kernel

Las VM con servidores NFS que se ejecutan en modo de kernel no se pueden migrar a GKE mediante Migrate to Containers. Estas VM deben migrarse a las VM en Compute Engine. Como alternativa, puedes usar Filestore para obtener una solución de NFS nativa de la nube.

Migra datos desde recursos compartidos de NFS de origen

Si la VM de origen usa una activación de recursos compartidos de NFS, estos datos no se pueden migrar automáticamente. Activa el recurso compartido en el contenedor migrado de la carga de trabajo mediante un volumen persistente de NFS o, si el recurso compartido de NFS de origen es remoto, copia los datos en otro archivo compartido que proporcione acceso de menor latencia al clúster.

Para ver las opciones de copia de datos, consulta la siguiente información:

1. Servicio de transferencia de almacenamiento o Transfer Appliance.

2. Copia datos mediante gsutil rsync (del archivo compartido de origen al bucket y, luego, del bucket al archivo compartido en la nube)

3. Soluciones de terceros, como SnapMirror u Cloud Volumes de NetApp.

4. Utilidades de OSS como Rsync

Asegúrate de que se pueda acceder a las bases de datos

En el caso de que tu aplicación se base en una base de datos, ya sea una que se ejecute de forma local en la VM o en una máquina externa, debes asegurarte de que se pueda acceder a la base de datos desde el nuevo Pod migrado. Debes validar que tu política de firewall de red permita el acceso del clúster a la base de datos.

Para migrar la base de datos a Google Cloud, recomendamos usar Database Migration Service.

Como alternativa, puedes ejecutar la base de datos dentro del clúster. Para obtener más información, consulta Planifica las implementaciones de bases de datos en GKE.

Asegúrate de que los metadatos inyectados estén disponibles

Si las aplicaciones dependen de metadatos inyectados (por ejemplo, variables de entorno), debes asegurarte de que estos metadatos estén disponibles en GKE. Si el mismo método de inyección de metadatos no está disponible, GKE ofrece ConfigMaps y Secrets.

Configura los servicios necesarios para iniciar en el nivel de ejecución 3

Las cargas de trabajo de Migrate to Containers solo alcanzan el nivel de ejecución 3. Las VM migradas a GKE mediante Migrate to Containers se iniciarán en el contenedor de Linux en el nivel de ejecución 3. Ciertos servicios (por ejemplo, X11 o XDM, para el acceso remoto a la GUI mediante VNC) están configurados de forma predeterminada a fin de que se inicien solo en el nivel de ejecución 5. Todos los servicios necesarios deben estar configurados para iniciarse en el nivel de ejecución 3.

Inhabilita los servicios que no sean necesarios

Migrate to Containers inhabilita automáticamente los servicios específicos de hardware o entornos, y un conjunto predefinido de servicios adicionales que se ejecutan en las VM. Estos servicios no son necesarios después de migrar las cargas de trabajo a los contenedores.

Por ejemplo, Migrate to Containers inhabilita de forma automática iptables, ip6tables y firewall. Para obtener una lista completa de los servicios que inhabilita Migrate to Containers, descarga el archivo blocklist.yaml.

Personaliza los servicios inhabilitados

De manera predeterminada, Migrate to Containers inhabilita los servicios que no son necesarios mencionados antes. También puedes definir tu propia lista personalizada de servicios que deseas inhabilitar en un contenedor migrado si personalizas el plan de migración para definir una lista de entidades bloqueadas. Con una lista de entidades bloqueadas, especificas uno o más servicios para inhabilitarlos en un contenedor migrado.

Mantén y actualiza las VM migradas

Con los artefactos que generas durante la migración, puedes aplicar parches de seguridad y actualizaciones del software del SO del modo de usuario y aplicación, editar las opciones de configuración incorporadas, agregar o reemplazar archivos y actualizar el software del entorno de ejecución de Migrate to Containers.

Para obtener más información, consulta Actualizaciones de imágenes posteriores a la migración.

¿Qué sigue?

• Obtén más información sobre la evaluación sin conexión.