Tu proceso de migración a GKE

En este tema, se describe la secuencia de pasos recomendada que debes seguir cuando migras cargas de trabajo a Google Kubernetes Engine (GKE) o Anthos.

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 pueden migrarse a la nube.

Luego, participarás en una fase de planificación de migración. En ella, desglosarás la flota de cargas de trabajo en grupos de cargas de trabajo relacionados que deberán migrarse juntos (según el resultado de la evaluación) y, a continuación, determinarás el orden en que se migrarán los grupos.

Además, puedes determinar qué cargas de trabajo se pueden 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, si lo deseas, puedes dividir el proceso de migración de la carga de trabajo en dos fases distintas, incluso en las cargas de trabajo adecuadas para GKE:

  1. Migra 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 los que desees realizar una migración del centro de datos y migrar todas las cargas de trabajo a Compute Engine y, solo en una segunda etapa, modernizar de manera selectiva las cargas de trabajo adecuadas a GKE. Como se muestra en el diagrama, una vez que seleccionas la ruta deseada para una carga de trabajo determinada, debes realizar una migración de configuración de zona de destino y, luego, de forma opcional, realizar las fases de optimización posteriores a la migración.

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

Descubrimiento

Recopila la información necesaria a fin de realizar una migración. Para ello, debes comprender tus aplicaciones y sus dependencias. Esto incluye el siguiente inventario:

  • VM cuyas cargas de trabajo deseas migrar
  • Las conexiones y los puertos de red requeridos de tus aplicaciones
  • Dependencias en los niveles de la 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 la migración

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

Funciones

  • Ingeniero o analista de migración de aplicaciones. Esta persona necesita un conocimiento básico 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:

  • Crearás o identificarás el clúster de GKE para alojar las cargas de trabajo migradas. Los clústeres de procesamiento de GKE se pueden ubicar en la nube o de forma local.
  • Crearás reglas de red de VPC y políticas de red de Kubernetes para tus aplicaciones.
  • Aplicarás definiciones de servicio de Kubernetes.
  • Realizarás elecciones de balanceo de cargas.
  • Configurarás un DNS.

Funciones

  • Administrador de clústeres de GKE, familiarizado con la implementación de clústeres, las Herramientas de redes de Google Cloud, las reglas de firewall, las funciones y las cuentas de servicio de la administración de identidades y accesos, y el lanzamiento de implementaciones desde el Google Cloud Marketplace.

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 de 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. En el siguiente diagrama, se muestra el flujo de trabajo de migración:

Diagrama que muestra una descripción general de la configuración y los pasos de la 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 migctl de Migrate for Anthos para las cargas de trabajo de Linux o la secuencia de comandos de migración de las cargas de trabajo de Windows. Luego, revisa y actualiza el plan con las entradas de las partes interesadas clave, como el propietario, el administrador de seguridad, el administrador de almacenamiento, etc., de la aplicación.
  2. Genera artefactos: Usa el plan de migración como entrada para la CLI a fin de procesar la VM de origen y producir los artefactos relevantes:
    • Para las cargas de trabajo de Linux: una imagen de contenedor, un Dockerfile, los YAML de implementación de referencia y, si se especifica en las cargas de trabajo con estado, un volumen de datos
    • Para las cargas de trabajo de Windows: los archivos de aplicación extraídos en un archivo ZIP y un Dockerfile Nota: Deberás compilar una imagen de contenedor mediante 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 para la validación a nivel de la 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 la imagen de contenedor extraídos funcionen de forma correcta cuando se ejecutan en un contenedor. Puedes ejecutar una “prueba de estado” en el clúster de procesamiento, identificar cualquier problema o realizar los cambios necesarios 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 Linux) y la carga de trabajo continúa acumulando datos y estados nuevos mientras se ejecutan en la fuente, te recomendamos que iteres uno o más ciclos de sincronización de datos antes de realizar una sincronización final de datos con la fuente apagada. Esto permitirá reducir el tiempo de inactividad. Cada ejecución de la sincronización de datos solo transferirá los datos que se modificaron desde el último ciclo de sincronización de datos.
  5. Implementa o integra con CI/CD: Ahora que los artefactos de 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 compilación e implementació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 del modelo de objetos administrados de Kubernetes, las implementaciones de GKE y la edición de YAML
  • OPCIONAL: Para la migración del almacenamiento de datos a un volumen persistente distinto del PD de GCP:
    • Administrador del almacenamiento o Administrador de GKE, familiarizado con la administración de volumen persistente de Kubernetes en GKE

Opera y optimiza

Ahora puedes aprovechar las herramientas que proporciona Anthos y el gran ecosistema de Kubernetes. En este paso, puedes agregar políticas de acceso, encriptación y autenticación mediante Istio, supervisar y registrar con Cloud Logging y Cloud Monitoring, todo mediante el cambio de configuración sin tener que volver a compilar las aplicaciones. También puedes integrar en 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.