Tu viaje de migración a GKE

En este tema, se describe la secuencia recomendada de pasos que debes seguir cuando migras cargas de trabajo a GKE.

En un nivel alto, debes pasar por una fase de descubrimiento y evaluación en la que identifiques las cargas de trabajo que tienes, las dependencias entre ellas y si se pueden migrar a la nube.

A continuación, participa en una fase de planificación de migración, en la que desglosa su flota de cargas de trabajo en grupos de cargas de trabajo que están relacionados y deben migrar juntos (según el resultado de la evaluación) y, luego, determinar el orden de los grupos que se migrarán.

Además, puedes determinar qué cargas de trabajo deben migrar a GKE en comparación con aquellas que no son adecuadas para GKE, pero que pueden migrar a Compute Engine con Migrate for Compute Engine. Ten en cuenta que puedes elegir dividir el desafío de migración de la carga de trabajo en dos fases distintas, incluso para las cargas de trabajo adecuadas para GKE:

  1. Migra las cargas de trabajo a Compute Engine con Migrate for Compute Engine.
  2. Migra de Compute Engine a GKE con Migrate for Anthos.

Este método es útil, por ejemplo, en los casos en que deseas realizar una migración de centros de datos y migrar todas las cargas de trabajo a Compute Engine, y solo migrar de forma selectiva las cargas de trabajo adecuadas a GKE. Como se muestra en el diagrama, una vez que seleccionas la ruta de acceso deseada para una carga de trabajo determinada, debes realizar una migración de configuración de la zona de destino y, luego, publicar las fases de optimización.

Los pasos de una migración a VM o contenedores mediante Migrate for Anthos.

Investigación

Recopila la información necesaria para una migración mediante la comprensión de tus aplicaciones y sus dependencias. Esto incluye un inventario de lo siguiente:

  • Las VM cuyas cargas de trabajo deseas migrar.
  • Conexiones y puertos de red requeridos de tus aplicaciones
  • Dependencias en los niveles de app.
  • Resolución de nombres de servicios o configuración de DNS

Funciones

  • Analista de TI con conocimiento de las topologías y la migración de la aplicación.

Planificación de migración

Divide tus aplicaciones en lotes y traduce la información recopilada durante el paso de descubrimiento al modelo de Kubernetes. Los entornos de aplicación, las topologías, los espacios de nombres y las políticas se centralizan en los archivos de configuración de YAML de Kubernetes. Ejemplos de archivos YAML disponibles.

Funciones

  • Ingeniero o analista de migración de aplicaciones. Esta persona necesita un conocimiento de nivel principiante del modelo de objetos administrados de Kubernetes, las implementaciones de GKE y los archivos YAML.

Configuración de la zona de destino

En este paso, harás lo siguiente:

  • Crea o identifica el clúster de GKE para alojar tus cargas de trabajo migradas.
  • Crea reglas de red de VPC y políticas de red de Kubernetes para tus aplicaciones.
  • Aplique las definiciones de servicio de Kubernetes.
  • Realizar elecciones de balanceo de cargas.
  • Configura un DNS.

Funciones

  • Administrador de clústeres de GKE, familiarizado con la implementación de clústeres, redes de Google Cloud, reglas de firewall, cuentas de servicio y funciones de Cloud Identity and Access Management, y lanzando implementaciones desde el mercado de Google Cloud.

Migración a GKE y validación

Una vez que el clúster de GKE, la red de VPC y los componentes de Migrate for Anthos estén listos para procesar las cargas de trabajo, puedes iniciar el flujo de trabajo de migración de Migrate for Anthos para cada VM de origen que desees migrar. Asegúrate de evaluar la compatibilidad de la carga de trabajo de origen y el sistema operativo con Migrate for Anthos. Para ello, sigue estos lineamientos. El flujo de trabajo de migración se muestra en el siguiente diagrama:

Diagrama que muestra una descripción general de los pasos de configuración y migración.

El flujo de trabajo de migración contiene los siguientes cinco pasos:

  1. Genera y revisa el plan de migración: Usa la CLI de Migrate for Anthos migctl para las cargas de trabajo de Linux o la secuencia de comandos de migración para las cargas de trabajo de Windows. Luego, revisa y actualiza el plan con entradas de partes interesadas clave, como el propietario de la aplicación, el administrador de seguridad, el administrador de almacenamiento, etcétera.
  2. Generar artefactos: Usa el plan de migración como entrada a la CLI para procesar la VM de origen y producir los artefactos relevantes:
    • Para cargas de trabajo de Linux: imagen de contenedor, Dockerfile, YAML de implementación de referencia y, si se especifica para cargas de trabajo con estado, un volumen de datos.
    • Para cargas de trabajo de Windows: archivos de aplicación extraídos en un archivo ZIP y un Dockerfile. Nota: Deberás compilar una imagen de contenedor con el Dockerfile y el contenido extraído antes de continuar con el siguiente paso.
  3. Prueba: Antes de continuar con la implementación de la carga de trabajo de validación de nivel de aplicación de extremo a extremo en un clúster de prueba, etapa de pruebas o producción, te recomendamos verificar que el volumen de datos (si corresponde) y el contenedor de imágenes extraído funcionan correctamente cuando se ejecutan en un contenedor. Puedes ejecutar una “prueba de estado” en el clúster de procesamiento, identificar cualquier problema o edición necesaria en el plan de migración y, luego, repetir el paso 2 y volver a realizar la prueba.
  4. Sincronización de datos: Cuando se migra una carga de trabajo con estado (solo en Linux) y la carga de trabajo continúa acumulando datos y estados nuevos mientras se ejecuta en la fuente, es posible que desees iterar uno o más ciclos de sincronización antes de realizar una sincronización de datos final con la fuente cerrada. Esto permitirá reducir el tiempo de inactividad final. Cada ejecución de sincronización de datos solo transferirá los datos modificados desde el último ciclo de sincronización de datos.
  5. Implementa o integra con CI/CD: Ahora que los artefactos del contenedor están listos y validados, puedes continuar con la implementación en un clúster de prueba, etapa de pruebas o producción. Como alternativa, puedes usar los artefactos para integrar a una canalización de implementación y compilación mediante una herramienta de organización como Cloud Build.

Funciones

  • Para la migración de cargas de trabajo:
    • Propietario de la aplicación, o analista de migración de aplicaciones, con conocimientos básicos sobre el modelo de objetos administrados de Kubernetes, las implementaciones de GKE y la edición YAML.
  • OPCIONAL: Para la migración de almacenamiento de datos a un volumen persistente que no sea un PD de GCP:
    • Administrador de almacenamiento o administrador de GKE, familiarizado con la administración de volumen persistente de Kubernetes en GKE.

Operar y optimizar

Ahora puedes aprovechar las herramientas proporcionadas por Anthos y el gran ecosistema de Kubernetes. En este paso, puedes agregar políticas de acceso, encriptación y autenticación con Istio, supervisión y registro con Cloud Logging y Cloud Monitoring, todo mediante el cambio de configuración y no la recompilación de tus aplicaciones. También puedes integrar a una canalización de CI/CD mediante herramientas como Cloud Build para implementar procedimientos de mantenimiento del día 2, como actualizaciones de versiones y paquetes de software.