Prepárate para migrar a Autopilot desde la versión Standard

En esta página, se proporcionan consideraciones y recomendaciones que te ayudarán a migrar cargas de trabajo de clústeres Standard de Google Kubernetes Engine (GKE) a clústeres de Autopilot con interrupciones mínimas en tus servicios. Esta página está destinada a los administradores de clústeres que ya decidieron migrar a Autopilot. Si necesitas más información antes de decidir migrar, consulta Elige un modo de operación de GKE y Compara GKE Autopilot y Standard.

Cómo funciona la migración

Los clústeres de Autopilot automatizan muchas de las características y funciones opcionales que requieren la configuración manual en los clústeres Standard. Además, los clústeres de Autopilot aplican configuraciones predeterminadas más seguras para las aplicaciones para proporcionar un entorno más listo para la producción y reducir la sobrecarga de administración requerida en comparación con el modo Standard. Los clústeres de Autopilot aplican muchas prácticas recomendadas y recomendaciones de GKE de forma predeterminada. Autopilot usa un modelo de configuración centrado en la carga de trabajo, en el que solicitas lo que necesitas en tus manifiestos de Kubernetes y GKE aprovisiona la infraestructura correspondiente.

Cuando migres tus cargas de trabajo Standard a Autopilot, debes preparar tus manifiestos de cargas de trabajo para asegurarte de que sean compatibles con los clústeres de Autopilot, por ejemplo, para asegurarte de que los manifiestos soliciten una infraestructura que normalmente deberías tener que aprovisionar tú mismo.

Para preparar y ejecutar una migración exitosa, realizarás las siguientes tareas de alto nivel:

1. Ejecuta una verificación de comprobación previa en tu clúster Standard existente para confirmar la compatibilidad con Autopilot.
2. Si corresponde, modifica los manifiestos de tu carga de trabajo para que sean compatibles con Autopilot.
3. Realiza una ejecución de prueba en la que verifiques que tus cargas de trabajo funcionen de forma correcta en Autopilot.
4. Planifica y crea el clúster de Autopilot.
5. Si corresponde, actualiza tus herramientas de infraestructura como código.
6. Realiza la migración.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Kubernetes Engine de Google.
Habilitar la API de Kubernetes Engine de Google
• Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.

• Asegúrate de tener un clúster Standard existente con cargas de trabajo en ejecución.
• Asegúrate de tener un clúster de Autopilot sin cargas de trabajo para realizar ejecuciones de prueba. Para crear un clúster de Autopilot nuevo, consulta Crea un clúster de Autopilot.

Ejecuta una verificación preliminar en tu clúster Standard

Google Cloud CLI y la API de Google Kubernetes Engine proporcionan una herramienta de verificación previa que valida las especificaciones de las cargas de trabajo Standard en ejecución para identificar incompatibilidades con clústeres de Autopilot. Esta herramienta está disponible en GKE versión 1.26 y posteriores.

• Para usar esta herramienta en la línea de comandos, ejecuta el siguiente comando:

gcloud container clusters check-autopilot-compatibility CLUSTER_NAME

Reemplaza CLUSTER_NAME por el nombre del clúster Standard. De forma opcional, agrega --format=json a este comando para obtener el resultado en un archivo JSON.

El resultado contiene los resultados de todas tus cargas de trabajo estándar en ejecución, categorizados y con recomendaciones prácticas para garantizar la compatibilidad con Autopilot, cuando corresponda. En la siguiente tabla, se describen las categorías:

Modifica las especificaciones de tu carga de trabajo según los resultados previos al vuelo

Después de ejecutar la verificación previa, revisa el resultado de JSON e identifica las cargas de trabajo que deben cambiar. Recomendamos implementar incluso las recomendaciones de configuración opcionales. Cada resultado también proporciona un vínculo a la documentación que te muestra cómo debería ser la especificación de la carga de trabajo.

La diferencia más importante entre Autopilot y Standard es que la configuración de la infraestructura en Autopilot está automatizada según la especificación de la carga de trabajo. Los controles de programación de Kubernetes, como los taints de nodo y las tolerancias, se agregan de forma automática a las cargas de trabajo en ejecución. Si es necesario, también debes modificar la configuración de infraestructura como código, como los gráficos de Helm o las superposiciones de Kustomize, para que coincidan.

Algunos cambios de configuración comunes que debes realizar incluyen los siguientes:

Realiza una ejecución de prueba en un clúster de Autopilot de etapa de pruebas

Después de modificar cada manifiesto de carga de trabajo, realiza una implementación de ejecución de prueba en un clúster de etapa de pruebas de Autopilot nuevo para asegurarte de que la carga de trabajo se ejecute como se espera.

kubectl create --dry-run=server -f=PATH_TO_MANIFEST

Planifica el clúster de Autopilot de destino

Cuando la ejecución de prueba ya no muestre problemas, planifica y crea el clúster de Autopilot nuevo para tus cargas de trabajo. Este clúster es diferente del clúster de Autopilot que usaste para probar las modificaciones del manifiesto en la sección anterior.

Usa Prácticas recomendadas para la integración en GKE para conocer los requisitos de configuración básicos. Luego, lee la Descripción general de Autopilot, que proporciona información específica de tu caso de uso en diferentes capas.

Además, ten en cuenta lo siguiente:

• Los clústeres de Autopilot son nativos de la VPC, por lo que no recomendamos migrar a Autopilot desde clústeres Standard basados en rutas.
• Usa la misma VPC o una similar para el clúster de Autopilot y el clúster Standard, incluidas las reglas de firewall y las opciones de configuración de VPC personalizadas.
• Los clústeres de Autopilot usan GKE Dataplane V2 y solo son compatibles con NetworkPolicies de Cilium. No se admiten las NetworkPolicies de Calico.
• Si deseas usar el enmascaramiento de IP en Autopilot, usa una política de NAT de salida.
• Si tienes un clúster Standard privado, crea un clúster privado de Autopilot con una configuración de aislamiento similar.
• Especifica el rango de IPv4 principal del clúster durante la creación del clúster, con el mismo tamaño de rango que el del clúster Standard.
• Obtén información sobre las diferencias en la cuota entre modos, en especial si tienes clústeres grandes.
• Obtén más información sobre los máximos de Pods por nodo para Autopilot, que son diferentes de Standard. Esto importa más si usas la afinidad de nodos o Pods con frecuencia.
• Todos los clústeres de Autopilot usan Cloud DNS.

Crea el clúster de Autopilot

Cuando estés listo para crear el clúster, usa Crea un clúster de Autopilot. Todos los clústeres de Autopilot son regionales y se inscriben automáticamente en un canal de versiones, aunque puedes especificar el canal y la versión del clúster. Recomendamos implementar una carga de trabajo de muestra pequeña en el clúster para activar el aprovisionamiento automático de nodos para que las cargas de trabajo de producción puedan programar de inmediato.

Actualiza tus herramientas de infraestructura como código

Los siguientes proveedores de infraestructura como código admiten Autopilot:

• Terraform
• Crossplane
• Pulumi
• Config Connector

Lee la documentación de tu proveedor preferido y modifica tus configuraciones.

Elige un enfoque de migración

El método de migración que usas depende de tu carga de trabajo individual y de tu comodidad con los conceptos de herramientas de redes, como Services de varios clústeres e Ingress de varios clústeres y cómo administras el estado de los objetos de Kubernetes en el clúster.

Pasos de la migración de alto nivel

Antes de comenzar una migración, asegúrate de resolver cualquier resultado de Incompatible o Additional configuration required de la verificación previa. Si implementas cargas de trabajo con esos resultados en Autopilot sin modificaciones, las cargas de trabajo fallarán.

En las siguientes secciones, se muestra una descripción general de alto nivel de una migración hipotética. Los pasos reales variarán según el entorno y cada una de las cargas de trabajo. Planifica, prueba y vuelve a probar las cargas de trabajo en busca de problemas antes de migrar un entorno de producción Se incluyen las siguientes consideraciones:

• La duración del proceso de migración depende de la cantidad de cargas de trabajo que migres.
• El tiempo de inactividad es obligatorio mientras migras las cargas de trabajo con estado.
• La migración manual te permite enfocarte en las cargas de trabajo individuales durante la migración para que puedas resolver los problemas en tiempo real de manera individual.
• En todos los casos, asegúrate de migrar los servicios, los Ingress y otros objetos de Kubernetes que facilitan la funcionalidad de tus cargas de trabajo sin estado y con estado.

Migra todas las cargas de trabajo mediante la copia de seguridad para GKE

Si todas las cargas de trabajo (con estado y sin estado) que se ejecutan en tu clúster Standard son compatibles con Autopilot y la herramienta de comprobación previa muestra Passed o Passed with optional configuration para cada carga de trabajo, puedes usar Copia de seguridad para GKE para crear una copia de seguridad de todo el estado del clúster Standard y las cargas de trabajo, y restablecer la copia de seguridad en el clúster de Autopilot.

Este enfoque tiene los siguientes beneficios:

• Puedes mover todas las cargas de trabajo de la operación Standard a Autopilot con una configuración mínima necesaria.
• Puedes mover cargas de trabajo sin estado y con estado y conservar las relaciones entre las cargas de trabajo, así como los PersistentVolumes asociados.
• Las reversiones son intuitivas y administradas por Google. Puedes revertir toda la migración o revertir cargas de trabajo específicas de manera selectiva.
• Puedes migrar cargas de trabajo con estado en todas las regiones de Google Cloud. La migración manual de cargas de trabajo con estado solo puede ocurrir en la misma región.

Cuando usas este método, GKE aplica la configuración predeterminada de Autopilot a las cargas de trabajo que recibieron un resultado de Passed with optional configuration de la herramienta previa al período. Antes de migrar estas cargas de trabajo, asegúrate de que te sientas cómodo con esos valores predeterminados.

Migra manualmente las cargas de trabajo sin estado sin tiempo de inactividad

Si deseas migrar cargas de trabajo sin estado sin tiempo de inactividad para tus servicios, registra los clústeres de origen y destino en una flota de GKE y usa Services de varios clústeres e Ingress de varios clústeres para realizar las siguientes acciones: asegúrate de que tus cargas de trabajo permanezcan disponibles durante la migración.

1. Habilita Services de varios clústeres e Ingress de varios clústeres para tu clúster de origen y tu clúster de destino. Para obtener instrucciones, consulta Configura Service de varios clústeres y Configura Ingress de varios clústeres.
2. Si tienes dependencias de backend, como una carga de trabajo de base de datos, exporta esos servicios de tu clúster Standard mediante los Services de varios clústeres. Esto permite que las cargas de trabajo en tu clúster de Autopilot accedan a las dependencias del clúster Standard. Para obtener instrucciones, consulta Registra un servicio para exportar.
3. Implementa un Ingress de varios clústeres y un Service de varios clústeres para controlar el tráfico entrante entre clústeres. Configura el Service de varios clústeres para enviar solo tráfico al clúster Standard. Para obtener instrucciones, consulta Implementa Ingress en clústeres.
4. Implementa tus cargas de trabajo sin estado con manifiestos actualizados en el clúster de Autopilot, Los Services de varios clústeres exportados coinciden de forma automática y envían tráfico a las cargas de trabajo con estado correspondientes.
5. Actualiza tu Service de varios clústeres para dirigir el tráfico entrante al clúster de Autopilot. Para obtener instrucciones, consulta Selección de clústeres.

Ahora entregas tus cargas de trabajo sin estado desde el clúster de Autopilot. Si solo tenías cargas de trabajo sin estado en el clúster de origen y no quedan dependencias, continúa con Completa la migración. Si tienes cargas de trabajo con estado, consulta Migra cargas de trabajo con estado de forma manual.

Migra de forma manual las cargas de trabajo con estado

Después de migrar tus cargas de trabajo sin estado, debes desactivar y migrar tus cargas de trabajo con estado desde el clúster Standard. Este paso requiere tiempo de inactividad para tu clúster.

1. Inicia el tiempo de inactividad del entorno.
2. Desactiva tus cargas de trabajo con estado.
3. Asegúrate de haber modificado los manifiestos de la carga de trabajo para la compatibilidad con Autopilot. Para obtener más información, consulta Modifica las especificaciones de tu carga de trabajo según los resultados previos al vuelo.

4. Implementa tus cargas de trabajo en tu clúster de Autopilot.

5. Implementa los Services para tus cargas de trabajo con estado en el clúster de Autopilot

6. Actualiza las herramientas de redes del clúster para permitir que las cargas de trabajo sin estado continúen comunicándose con las cargas de trabajo de backend:

   • Si usaste una dirección IP estática en los servicios de backend del clúster Standard, vuelve a usar esa dirección IP en Autopilot.
   • Si permites que Kubernetes asigne una dirección IP, implementa tus objetos Service de backend, obtén la dirección IP nueva y actualiza tu DNS para que use la dirección IP nueva.

En esta etapa, se deben cumplir los siguientes requisitos:

• Estás ejecutando todas tus cargas de trabajo sin estado en Autopilot.
• Cualquier carga de trabajo con estado de backend también se ejecuta en Autopilot.
• Las cargas de trabajo sin estado y con estado pueden comunicarse entre sí.
• El Service de varios clústeres dirige todo el tráfico entrante a tu clúster de Autopilot.

Cuando hayas migrado todas las cargas de trabajo y los objetos de Kubernetes al clúster nuevo, continúa con la sección Completa la migración.

Alternativa: Migra manualmente todas las cargas de trabajo durante el tiempo de inactividad

Si no deseas usar Services de varios clústeres e Ingress de varios clústeres para migrar cargas de trabajo con un tiempo de inactividad mínimo, migra todas tus cargas de trabajo durante el tiempo de inactividad. Este método genera un tiempo de inactividad más largo para los servicios, pero no requiere el trabajo con funciones de varios clústeres.

1. Inicia tu tiempo de inactividad.
2. Implementa tus manifiestos sin estado en el clúster de Autopilot.
3. Migra de forma manual tus cargas de trabajo con estado. Para obtener instrucciones, consulta la sección Migra cargas de trabajo con estado de forma manual.
4. Modifica los registros DNS de tráfico externo interno y entrante para usar las nuevas direcciones IP de los servicios.
5. Finaliza el tiempo de inactividad.

Completa la migración

Después de mover todas tus cargas de trabajo y Services al nuevo clúster de Autopilot, finaliza el tiempo de inactividad y permite que tu entorno se prueba durante una duración predeterminada. Cuando estés conforme con el estado de la migración y estés seguro de que no será necesario revertirla, puedes limpiar los artefactos de migración y completarla.

Limpia atributos de varios clústeres (opcional)

Si usaste Ingress de varios clústeres y Services de varios clústeres para migrar, y no deseas que tu clúster de Autopilot permanezca registrado en una flota, haz lo siguiente:

1. Para el tráfico externo entrante, implementa un Ingress y configúralo en la dirección IP de los Services que exponen tus cargas de trabajo. Si deseas obtener instrucciones, consulta Ingress para balanceadores de cargas de aplicaciones externos.
2. Para el tráfico dentro del clúster, como las cargas de trabajo de frontend y las dependencias con estado, actualiza los registros DNS del clúster para usar las direcciones IP de esos Services.
3. Borra el Ingress de varios clústeres y los recursos de Service de varios clústeres que creaste durante la migración.
4. Inhabilita Ingress de varios clústeres y Services de varios clústeres.
5. Cancela el registro del clúster de Autopilot de la flota.

Borra el clúster Standard

Después de que haya transcurrido suficiente tiempo después de que se complete la migración y estés conforme con el estado del clúster nuevo, borra el clúster Standard. Te recomendamos que mantengas los manifiestos de copia de seguridad Standard.

Revierte una migración defectuosa

Si tienes problemas y deseas volver al clúster Standard, realiza una de las siguientes acciones, según cómo hayas realizado la migración:

• Si usaste la copia de seguridad para GKE para crear copias de seguridad durante la migración, restablece las copias de seguridad en el clúster Standard original. Para obtener instrucciones, consulta Restablece una copia de seguridad.

• Si migraste cargas de trabajo de forma manual, repite los pasos de migración en las secciones anteriores con el clúster Standard como destino y el clúster de Autopilot como fuente. En un nivel alto, esto implica los siguientes pasos:

  1. Inicia el tiempo de inactividad.
  2. Migra de forma manual las cargas de trabajo con estado al clúster Standard. Para obtener instrucciones, consulta la sección Migra cargas de trabajo con estado de forma manual.
  3. Mueve las cargas de trabajo sin estado al clúster Standard mediante los manifiestos originales de los que creaste una copia de seguridad antes de la migración.
  4. Implementa tu Ingress en el clúster Standard y realiza la transición de tu DNS a las nuevas direcciones IP para los servicios.
  5. Borra el clúster de Autopilot.

¿Qué sigue?

• Planifica solicitudes de recursos de Autopilot
• Configura la supervisión
• Configura y usa el panel de postura de seguridad.