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:
- Ejecuta una verificación de comprobación previa en tu clúster Standard existente para confirmar la compatibilidad con Autopilot.
- Si corresponde, modifica los manifiestos de tu carga de trabajo para que sean compatibles con Autopilot.
- Realiza una prueba de ejecución en la que verifiques que tus cargas de trabajo funcionen correctamente en Autopilot.
- Planifica y crea el clúster de Autopilot.
- Si corresponde, actualiza las herramientas de infraestructura como código.
- Realiza la migración.
Antes de comenzar
Antes de comenzar, asegúrate de haber realizado las siguientes tareas:
- Habilita la API de Google Kubernetes Engine. Habilitar la API de Google Kubernetes Engine
- Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta
gcloud components updatepara 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 pruebas sin conexión. Para crear un clúster 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:
| Resultados preliminares de la herramienta | |
|---|---|
Passed |
La carga de trabajo se ejecutará como se espera sin necesidad de configurar Autopilot. |
Passed with optional configuration |
La carga de trabajo se ejecutará en Autopilot, pero puedes realizar cambios de configuración opcionales para optimizar la experiencia. Si no realizas cambios de configuración, Autopilot aplica una configuración predeterminada por ti. Por ejemplo, si tu carga de trabajo se ejecutaba en máquinas N2 en modo Standard, GKE aplica la clase de procesamiento de uso general para Autopilot. De manera opcional, puedes modificar la carga de trabajo para solicitar la clase de procesamiento balanceada, que está respaldada por máquinas N2. |
Additional configuration required |
La carga de trabajo no se ejecutará en Autopilot, a menos que realices un cambio de configuración. Por ejemplo, considera un contenedor que usa la función NET_ADMIN en Standard. Autopilot descarta esta capacidad de forma predeterminada para mejorar la seguridad, por lo que deberás habilitar NET_ADMIN en el clúster antes de implementar la carga de trabajo. |
Incompatibility |
La carga de trabajo no se ejecutará en Autopilot porque usa una funcionalidad que Autopilot no admite. Por ejemplo, los clústeres de Autopilot rechazan los Pods privilegiados ( |
Modifica las especificaciones de tu carga de trabajo según los resultados de la prueba previa al lanzamiento
Después de ejecutar la verificación previa, revisa el resultado de JSON y, luego, identifica las cargas de trabajo que deben cambiar. Recomendamos implementar incluso las recomendaciones de configuración opcionales. Cada hallazgo también proporciona un vínculo a la documentación que muestra cómo debería verse la especificación de la carga de trabajo.
La diferencia más importante entre Autopilot y Standard es que la configuración de infraestructura en Autopilot se automatiza según la especificación de carga de trabajo. Los controles de programación de Kubernetes, como los taints y las tolerancias de nodos, se agregan automáticamente a tus cargas de trabajo en ejecución. Si es necesario, también debes modificar tus parámetros de configuración de infraestructura como código, como los gráficos de Helm o las superposiciones de Kustomize, para que coincidan.
Debes realizar algunos cambios de configuración comunes, como los siguientes:
| Cambios de configuración comunes para Autopilot | |
|---|---|
| Configuración de procesamiento y arquitectura | Los clústeres de Autopilot usan el tipo de máquina de la serie E de forma predeterminada. Si necesitas otros tipos de máquinas, la especificación de tu carga de trabajo debe solicitar una clase de procesamiento, que le indique a Autopilot que coloque esos Pods en nodos que usen tipos o arquitecturas de máquinas específicas. Para obtener más detalles, consulta Clases de procesamiento en Autopilot. |
| Aceleradores | Las cargas de trabajo basadas en GPU deben solicitar GPUs en la especificación de la carga de trabajo. Autopilot aprovisiona automáticamente los nodos con el tipo de máquina y los aceleradores necesarios. Para obtener instrucciones, consulta Implementa cargas de trabajo de GPU en Autopilot. |
| Solicitudes de recursos | Todas las cargas de trabajo de Autopilot deben especificar valores para Para obtener más detalles, consulta Solicitudes de recursos en Autopilot. |
| Cargas de trabajo tolerantes a errores en VMs Spot | Si tus cargas de trabajo se ejecutan en VMs Spot en Standard, solicita pods Spot en la configuración de la carga de trabajo mediante la configuración de un selector de nodos para Para obtener más información, consulta Pods de Spot. |
Realiza una prueba de validación en un clúster de Autopilot de preparación
Después de modificar cada manifiesto de carga de trabajo, realiza una implementación de prueba en un nuevo clúster de Autopilot de preparación para asegurarte de que la carga de trabajo se ejecute como se espera.
Línea de comandos
Ejecuta el siguiente comando:
kubectl create --dry-run=server -f=PATH_TO_MANIFEST
Reemplaza PATH_TO_MANIFEST por la ruta de acceso al manifiesto de la carga de trabajo modificado.
IDE
Si usas el editor de Cloud Shell, el comando de ejecución de prueba está integrado y se ejecuta en cualquier manifiesto abierto. Si usas código de Visual Studio o IDEs de IntelliJ, instala la extensión de Cloud Code para ejecutar de forma automática la ejecución de prueba en cualquier manifiesto abierto.
El panel Problems del IDE muestra cualquier problema de prueba preliminar, como en la siguiente imagen, que muestra una prueba preliminar fallida para un manifiesto que especificaba privileged: true.
Planifica el clúster de Autopilot de destino
Cuando tu ejecución de prueba ya no muestre problemas, planifica y crea el clúster nuevo de Autopilot 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 admiten NetworkPolicies de Cilium. Las NetworkPolicies de Calico no son compatibles.
- 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 de cuota entre los modos, en especial si tienes clústeres grandes.
- Obtén información sobre los máximos de Pods por nodo de Autopilot, que son diferentes de los de Standard. Esto es más importante 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:
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.
| Tipo de carga de trabajo | Resultados preliminares de la herramienta | Enfoque de migración |
|---|---|---|
| Sin estado |
|
En el caso de las cargas de trabajo |
| Con estado |
|
Usa uno de los siguientes métodos:
|
| Se requiere una configuración adicional | Actualiza tus manifiestos de Kubernetes y vuelve a implementarlos en Autopilot durante el tiempo de inactividad programado. Para ver los pasos generales, consulta Cómo migrar cargas de trabajo con estado de forma manual. |
Pasos de migración de alto nivel
Antes de comenzar una migración, asegúrate de haber resuelto los resultados Incompatible o Additional configuration required de la verificación preliminar. Si implementas cargas de trabajo con esos resultados en Autopilot sin modificaciones, las cargas de trabajo fallarán.
En las siguientes secciones, se proporciona una descripción general de alto nivel de una migración hipotética. Los pasos reales variarán según tu entorno y cada una de tus 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 Entre las consideraciones, se incluyen las siguientes:
- 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 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 problemas en tiempo real, caso por caso.
- En todos los casos, asegúrate de migrar los servicios, los ingresos y otros objetos de Kubernetes que faciliten la funcionalidad de tus cargas de trabajo sin estado y con estado.
Migra todas las cargas de trabajo con 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 retener las relaciones entre las cargas de trabajo, así como los PersistentVolumes asociados.
- Google administra las reversiones, que son intuitivas. Puedes revertir toda la migración o revertir cargas de trabajo específicas de forma selectiva.
- Puedes migrar cargas de trabajo con estado entre regiones de Google Cloud. La migración manual de cargas de trabajo con estado solo se puede realizar en la misma región.
Cuando usas este método, GKE aplica las configuraciones predeterminadas de Autopilot a las cargas de trabajo que recibieron un resultado Passed with optional configuration de la herramienta de verificación preliminar. Antes de migrar estas cargas de trabajo, asegúrate de estar 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.
- Habilita los servicios de varios clústeres y la entrada 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.
- 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.
- Implementa un Ingress 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 varios clústeres.
- 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.
- Actualiza el 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 publicas 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, continúa con Cómo migrar 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.
- Inicia el tiempo de inactividad de tu entorno.
- Suspende tus cargas de trabajo con estado.
- Asegúrate de haber modificado los manifiestos de tu carga de trabajo para la compatibilidad con Autopilot. Para obtener más información, consulta Modifica las especificaciones de la carga de trabajo según los resultados previos.
Implementa las cargas de trabajo en tu clúster de Autopilot.
Implementa los Services para tus cargas de trabajo con estado en el clúster de Autopilot
Actualiza tus herramientas de redes en el clúster para permitir que tus cargas de trabajo sin estado continúen comunicándose con sus 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 servicios de backend, obtén la nueva dirección IP y actualiza tu DNS para usar 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.
- Las cargas de trabajo con estado de backend también se ejecutan en Autopilot.
- Tus cargas de trabajo sin estado y con estado pueden comunicarse entre sí.
- Tu 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, procede a completar la migración.
Alternativa: Migra de forma manual 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 tus servicios, pero no requiere que se trabaje con características de varios clústeres.
- Inicia el tiempo de inactividad.
- Implementa tus manifiestos sin estado en el clúster de Autopilot.
- Migra de forma manual tus cargas de trabajo con estado. Para obtener instrucciones, consulta la sección Cómo migrar cargas de trabajo con estado de forma manual.
- Modifica los registros DNS para el tráfico externo entrante y dentro del clúster para usar las nuevas direcciones IP de los Services.
- Finaliza tu tiempo de inactividad.
Completa la migración
Después de mover todas tus cargas de trabajo y Services al clúster nuevo de Autopilot, finaliza el tiempo de inactividad y permite que tu entorno se mantenga en prueba durante un período predeterminado. 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.
Opcional: Limpia las funciones de varios clústeres
Si usaste Ingress de varios clústeres y Services de varios clústeres para migrar y no quieres que tu clúster de Autopilot permanezca registrado en una flota, haz lo siguiente:
- Para el tráfico externo entrante, implementa un Ingress y configúralo en la dirección IP de los servicios que exponen tus cargas de trabajo. Si deseas obtener instrucciones, consulta Ingress para balanceadores de cargas de aplicaciones externos.
- 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.
- Borra el Ingress de varios clústeres y los recursos de Service de varios clústeres que creaste durante la migración.
- Inhabilita Ingress de varios clústeres y Services de varios clústeres.
- 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 Cómo restablecer 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:
- Iniciar el tiempo de inactividad.
- Migra de forma manual las cargas de trabajo con estado al clúster Standard. Para obtener instrucciones, consulta la sección sobre cómo migrar cargas de trabajo con estado de forma manual.
- 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.
- Implementa tu Ingress en el clúster Standard y realiza la transición de tu DNS a las nuevas direcciones IP para los servicios.
- Borrar el clúster de Autopilot.
¿Qué sigue?
- Planifica las solicitudes de recursos de Autopilot
- Configura la supervisión
- Configura y usa el panel de postura de seguridad