Prácticas recomendadas de planificación
En este tema se ofrecen consejos para migrar aplicaciones a Google Kubernetes Engine (GKE) o GKE Enterprise, basándose en migraciones de aplicaciones reales que se han llevado a cabo con Migrate to Containers.
La CLI del cliente de descubrimiento de Migration Center o la CLI de mcdc es una herramienta que se usa para determinar la idoneidad de la carga de trabajo de una VM para migrarla a un contenedor.
Cargas de trabajo recomendadas
Migrate to Containers se recomienda para determinados tipos de cargas de trabajo de Linux y Windows, que se detallan a continuación.
Adecuado
Linux
Las aplicaciones Linux que se adaptan bien a la migración con Migrate to Containers incluyen las siguientes arquitecturas de aplicaciones:
- Servidores web o de aplicaciones
- Middleware de lógica empresarial (por ejemplo, Tomcat)
- Pilas de varias VMs y 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 con Migrate to Containers tienen las siguientes características operativas:
- Cargas de trabajo con ráfagas y ciclo de trabajo bajo
- Entornos de laboratorio de desarrollo, pruebas y formación
- Servicios de baja carga siempre activos
En general, la mayoría de las cargas de trabajo de Linux son compatibles con la migración, excepto las que se indican explícitamente a continuación en la sección No es una buena opción.
Windows
Las aplicaciones de Windows que se pueden migrar con Migrate to Containers son las cargas de trabajo que cumplen todas las características siguientes:
- IIS 7 o una versión posterior, ASP.NET con .NET Framework 3.5 o una versión posterior
- Niveles web y de lógica
- WS2008 R2 o versiones posteriores
Asistencia para sistemas operativos
Migrate to Containers es compatible con estos sistemas operativos de máquinas virtuales.
No es la opción adecuada
Linux
En Linux, las aplicaciones y los servidores que no son adecuados para la migración con Migrate to Containers son los siguientes:
- Bases de datos en memoria grandes y de alto rendimiento
- Máquinas virtuales con controladores de kernel especiales (por ejemplo, NFS en modo kernel)
- Dependencias de hardware específico
- Software con licencias vinculadas a un registro de ID de hardware concreto
Windows
En Windows, las cargas de trabajo que no tengan instalado IIS 7 o una versión posterior no son aptas para la migración. Otros tipos de aplicaciones que no son aptas para la migración:
- Aplicaciones con dependencias de GPUs o TPUs
- Aplicaciones 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 que conoces los recursos de red y los servicios que usan tus cargas de trabajo migradas, y de que se puede acceder a ellos y se pueden direccionar desde tu nube privada virtual.
Planificar los nombres de los servicios de Kubernetes
Si tus cargas de trabajo dependen del DNS para acceder a los servicios, debes planificar tu esquema de espacio de nombres, políticas de red y nombres de servicio de Kubernetes.
La especificación de implementación generada por el proceso de migración
contiene un objeto Service sin encabezado sugerido de tipo "ClusterIP". "ClusterIP" significa que no hay balanceo de carga y que hay una única IP interna del clúster a la que solo se puede acceder desde el clúster. El controlador de endpoints de Kubernetes modifica la configuración de DNS para devolver registros (direcciones) que apuntan a los pods, que están etiquetados con "app": "app-name" en deployment_spec.yaml.
Crear y aplicar servicios para conexiones a pods y contenedores
Después de migrar una carga de trabajo, los nombres de host ya no se aplican. Para permitir las conexiones a tus cargas de trabajo, crea y aplica servicios.
Identificar y configurar nombres e IPs migrados
GKE gestiona el archivo /etc/hosts. En Migrate to Containers, aún no se ha automatizado la adaptación del archivo hosts de la máquina virtual de origen a GKE. Los nombres y las IPs del archivo hosts de la máquina virtual migrada deben identificarse y configurarse como hostAliases.
Colocar los servicios dependientes en el mismo espacio de nombres
Los servicios que dependen unos de otros deben colocarse 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 los de producción, preproducción y prueba.
Controlar la superficie de acceso con la red de GKE
GKE tiene controles de red sofisticados. Se puede acceder a los pods desde diferentes redes, como Internet público, una red de VPC o una red de clúster interna. Esto ofrece la oportunidad de controlar y restringir aún más la superficie de acceso a una carga de trabajo sin la complejidad añadida de gestionar VLANs, filtros o reglas de enrutamiento.
Por ejemplo, una aplicación de tres niveles típica tiene niveles de frontend, aplicación y base de datos. Cuando se migra a Google Cloud, el servicio frontend se configura con un LoadBalancer en la red de VPC. No se puede acceder directamente a los demás niveles desde fuera del clúster de GKE. Una política de acceso a la red asegura que solo se pueda acceder al servicio de aplicación desde los pods frontend de la red de clústeres interna. Otra política asegura que solo los pods de la aplicación puedan acceder a los pods de la base de datos.
NFS
Definir montajes de NFS como volúmenes persistentes
Cuando crees el plan de migración, se detectarán automáticamente los montajes del cliente NFS en la VM de origen y se añadirán al plan generado.
Aunque los montajes se añaden al plan, están inhabilitados 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 quieres que Migrate to Containers genere definiciones de PersistentVolume y PersistentVolumeClaim, primero debes editar el plan de migración para habilitar el montaje del cliente NFS.
Para obtener más información, consulta el artículo sobre cómo personalizar los montajes de NFS.
Servidores NFS en modo kernel
Las máquinas virtuales con servidores NFS que se ejecutan en modo kernel no se pueden migrar a GKE con Migrate to Containers. Estas VMs deben migrarse a VMs de Compute Engine. También puedes usar Filestore para obtener una solución NFS nativa de la nube.
Migrar datos de recursos compartidos NFS de origen
Si tu VM de origen usa un montaje de recurso compartido NFS, estos datos no se pueden migrar automáticamente. Monta el recurso compartido en el contenedor de la carga de trabajo migrada mediante un volumen persistente de NFS o, si el recurso compartido de NFS de origen es remoto, copia los datos en otro recurso compartido de archivos que proporcione un acceso con menor latencia al clúster.
Para ver las opciones de copia de datos, consulta lo siguiente:
Copiar datos con
gcloud storage rsync(desde el sistema de archivos compartidos de origen al bucket y, a continuación, del bucket al sistema de archivos compartidos en la nube).Soluciones de terceros, como NetApp SnapMirror a NetApp Cloud Volumes.
Utilidades de OSS, como Rsync.
Asegurarse de que se pueda acceder a las bases de datos
Si tu aplicación depende de una base de datos, ya sea una que se ejecute localmente en la VM o en una máquina externa, debes asegurarte de que se pueda acceder a ella desde el nuevo pod migrado. Debes validar que tu política de cortafuegos de red permite el acceso del clúster a la base de datos.
Para migrar la base de datos a Google Cloud, te recomendamos que uses Database Migration Service.
También puedes ejecutar la base de datos dentro del clúster. Para obtener más información, consulta Planificar las implementaciones de bases de datos en GKE.
Asegurarse de que los metadatos insertados estén disponibles
Si tus aplicaciones dependen de metadatos insertados (por ejemplo, variables de entorno), debes asegurarte de que estos metadatos estén disponibles en GKE. Si no está disponible el mismo método de inyección de metadatos, GKE ofrece ConfigMaps y Secrets.
Configurar los servicios necesarios para que se inicien en el nivel de ejecución 3
Las cargas de trabajo de Migrate to Containers solo alcanzan el nivel de ejecución 3. Las VMs migradas a GKE con Migrate to Containers se iniciarán en el contenedor en el nivel de ejecución 3 de Linux. Algunos servicios (por ejemplo, X11 o XDM, para el acceso remoto a la interfaz gráfica de usuario mediante VNC) están configurados de forma predeterminada para iniciarse solo en el nivel de ejecución 5. Los servicios necesarios deben configurarse para que se inicien en el nivel de ejecución 3.
Inhabilitar servicios innecesarios
Migrate to Containers inhabilita automáticamente los servicios específicos del hardware o del entorno, así como un conjunto predefinido de servicios adicionales que se ejecutan en máquinas virtuales. Estos servicios no son necesarios después de migrar tus cargas de trabajo a contenedores.
Por ejemplo, Migrate to Containers inhabilita automáticamente iptables, ip6tables y firewalld. Para ver una lista completa de los servicios inhabilitados por Migrate to Containers, descarga el archivo blocklist.yaml.
Personalizar servicios inhabilitados
De forma predeterminada, Migrate to Containers inhabilita los servicios innecesarios que se indican arriba. También puede definir su propia lista personalizada de servicios que quiera inhabilitar en un contenedor migrado personalizando el plan de migración para definir una lista de bloqueo. Con una lista de bloqueo, puedes especificar uno o varios servicios que quieras inhabilitar en un contenedor migrado.
Mantener y actualizar las VMs migradas
Con los artefactos que generes durante la migración, podrás aplicar actualizaciones de software del SO en modo de aplicación y de usuario, parches de seguridad, editar configuraciones insertadas, añadir o sustituir archivos y actualizar el software de tiempo de ejecución de Migrate to Containers.
Para obtener más información, consulta Actualizaciones de imágenes posteriores a la migración.
Siguientes pasos
- Consulta más información sobre la evaluación sin conexión.