Prácticas recomendadas de planificación

En este tema, se ofrecen consejos para las migraciones de aplicaciones a GKE, en función de las migraciones de aplicaciones reales que se realizaron mediante Migrate for Anthos.

Se recomienda Migrate for Anthos para ciertos tipos de cargas de trabajo, que se detallan a continuación.

Opciones aptas

Las aplicaciones que son aptas para la migración mediante Migrate for Anthos 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 for Anthos 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 encendidos

Compatibilidad con el sistema operativo

Migrate for Anthos tiene una compatibilidad limitada con el sistema operativo de origen. Consulta Sistemas operativos de VM compatibles para obtener una lista de los sistemas operativos probados.

Opciones no aptas

Las aplicaciones y los servidores que no son adecuados para la migración mediante Migrate for Anthos 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

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 servicio 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”. Esto 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 modificará 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.

Crea y aplica servicios para las conexiones a pods y contenedores

Los nombres de host para las VM migradas ya no se resuelven en un Pod o un contenedor específico. 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 for Anthos, 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.

Coloca servicios codependientes en el mismo espacio de nombres

Los servicios codependientes deben estar ubicados en el mismo espacio de nombres de Kubernetes y usar nombres de DNS cortos (por ejemplo, appdb) 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 mediante los controles de GKE Ingress

GKE tiene controles sofisticados de entrada de red. 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 serán 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

Las activaciones de clientes de NFS no se configuran automáticamente después de la migración mediante Migrate for Anthos. Estas activaciones de NFS deberán definirse en el YAML del Pod como volúmenes persistentes de NFS. Consulta las instrucciones detalladas para activar volúmenes externos en contenedores de Migrate for Anthos en Activa volúmenes externos.

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 for Anthos. Deberán 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 migrarán 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. El servicio de Cloud Data Transfer o Data Transfer Appliance

  2. Copia datos mediante gsutil rsync (del archivo compartido de origen al depósito y, luego, del depósito 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 los metadatos inyectados estén disponibles

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

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

Las cargas de trabajo de Migrate for Anthos solo alcanzan el nivel de ejecución 3. Las VM migradas a GKE mediante Migrate for Anthos 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 for Anthos inhabilitará automáticamente los servicios específicos de hardware o entornos, además de un conjunto predefinido de servicios adicionales que se ejecutan en las VM. La lista de estos servicios se encuentra a continuación.

Servicios que Migrate for Anthos inhabilita

Tipo de servicio Nombres de servicios
Daemon de auditoría auditd
Amazon EC2 amazon-ssm-agent
Azure waagent, walinuxagent
Inicio boot.apparmor, boot.clock, boot.crypto, boot.crypto-early, boot.debugfs, boot.device-mapper, boot.dmraid, boot.kdump, boot.klog, boot.loadmodules, boot.lvm, boot.lvm_monitor, boot.md, boot.multipath, boot.open-iscsi, boot.sysctl
Compute Engine cloud-init, cloud-init-local, cloud-final, cloud-config, google-accounts-daemon, google-clock-skew-daemon, google-instance-setup, google-network-daemon, google-shutdown-scripts, google-startup-scripts
Partición expand-root
Firewalls iptables, ip6tables, firewalld
GUI xdm, splash, splash_early
Hardware relacionado microcode, microcode.ctl, mcelog, irqbalance, irq_balancer, acpid, hald, - haldaemon, alsasound, ondemand
Administrador de volúmenes de Linux lvm2-lvmetad, lvm2-monitor
iSCSI y varias rutas multipathd, iscsid, iscsi, open-iscsi
NTP ntp
Ajuste snapd, snapd.autoimport, snapd.core-fixup, snapd.seeded
Systemd systemd-modules-load, sys-kernel-config.mount, dev-hugepages.mount, systemd-journald-audit.socket, var-lib-nfs-rpc_pipefs.mount
Herramientas de VM vmtoolsd
Velostrata velostrata, velostrata-keep-alive

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 for Anthos.

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