En esta página se ofrecen consideraciones y recomendaciones que te ayudarán a migrar cargas de trabajo de clústeres Estándar de Google Kubernetes Engine (GKE) a clústeres Autopilot con las mínimas interrupciones en tus servicios. Esta página está dirigida a administradores de clústeres que ya han decidido migrar a Autopilot. Si necesitas más información antes de decidirte a migrar, consulta Elegir un modo de funcionamiento de GKE y Comparar GKE Autopilot y Estándar.
Cómo funciona la migración
Los clústeres de Autopilot automatizan muchas de las funciones y características opcionales que requieren una configuración manual en los clústeres estándar. Además, los clústeres de Autopilot aplican configuraciones predeterminadas más seguras para las aplicaciones, lo que proporciona un entorno más preparado para la producción y reduce la sobrecarga de gestión necesaria en comparación con el modo Estándar. Los clústeres de Autopilot aplican de forma predeterminada muchas prácticas recomendadas y recomendaciones de GKE. Autopilot usa un modelo de configuración centrado en las cargas 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 los manifiestos de las cargas de trabajo para asegurarte de que sean compatibles con los clústeres de Autopilot. Por ejemplo, debes comprobar que los manifiestos soliciten la infraestructura que normalmente tendrías que aprovisionar tú.
Para preparar y llevar a cabo una migración correcta, debes realizar las siguientes tareas generales:
- Ejecuta una comprobación previa en tu clúster Standard para confirmar la compatibilidad con Autopilot.
- Si procede, modifica los manifiestos de tus cargas de trabajo para que sean compatibles con Autopilot.
- Haz una prueba para comprobar que tus cargas de trabajo funcionan correctamente en Autopilot.
- Planifica y crea el clúster de Autopilot.
- Si procede, actualiza tus herramientas de infraestructura como código.
- Realiza la migración.
Antes de empezar
Antes de empezar, asegúrate de haber realizado las siguientes tareas:
- Habilita la API de Google Kubernetes Engine. Habilitar la API de Google Kubernetes Engine
- Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando
gcloud components update.
- Asegúrate de que tienes un clúster estándar con cargas de trabajo en ejecución.
- Asegúrate de tener un clúster Autopilot sin cargas de trabajo para realizar pruebas. Para crear un clúster de Autopilot, consulta Crear un clúster de Autopilot.
Habilita el componente de comprobación previa en tu clúster
En la versión 1.31.6-gke.1027000 de GKE y posteriores, el componente de comprobación previa de Autopilot está inhabilitado de forma predeterminada. Debes habilitar el componente de comprobación previa al vuelo para poder ejecutar la comprobación en un clúster. Si tu clúster ejecuta una versión de GKE anterior a la 1.31.6-gke.1027000, ve a la siguiente sección.
Habilita el componente de comprobación previa en tu clúster:
gcloud container clusters update CLUSTER_NAME \ --location=LOCATION \ --enable-autopilot-compatibility-auditingHaz los cambios siguientes:
CLUSTER_NAME: el nombre de tu clúster Standard.LOCATION: la ubicación de tu clúster Standard, comous-central1.
La operación de actualización tarda hasta 30 minutos en completarse.
Realizar una comprobación preparatoria en un clúster estándar
La CLI de Google Cloud y la API de Google Kubernetes Engine proporcionan una herramienta de comprobación previa que valida las especificaciones de tus cargas de trabajo Standard en ejecución para identificar incompatibilidades con los clústeres Autopilot. Esta herramienta está disponible en GKE 1.26 y versiones posteriores.
- Para usar esta herramienta en la línea de comandos, ejecuta el siguiente comando:
gcloud container clusters check-autopilot-compatibility CLUSTER_NAME
Sustituye CLUSTER_NAME por el nombre de tu clúster Standard. Si quieres, añade --format=json a este comando para obtener el resultado en un archivo JSON.
El resultado contiene las conclusiones de todas las cargas de trabajo Standard en ejecución, clasificadas y con recomendaciones prácticas para asegurar la compatibilidad con Autopilot, si procede. En la siguiente tabla se describen las categorías:
| Resultados de la herramienta de comprobación previa | |
|---|---|
Passed |
La carga de trabajo se ejecutará correctamente sin necesidad de configurar Autopilot. |
Passed with optional configuration |
La carga de trabajo se ejecutará en Autopilot, pero puedes hacer cambios de configuración opcionales para optimizar la experiencia. Si no haces cambios en la configuración, Autopilot aplicará una configuración predeterminada. Por ejemplo, si tu carga de trabajo se ejecutaba en máquinas N2 en el modo estándar, GKE aplica la clase de computación de uso general para Autopilot. También puedes modificar la carga de trabajo para solicitar la clase de computación Balanced, que se basa en máquinas N2. |
Additional configuration required |
La carga de trabajo no se ejecutará en Autopilot a menos que hagas un cambio en la configuración. Por ejemplo, considera un contenedor que usa la función NET_ADMIN en Standard. Autopilot elimina esta función de forma predeterminada para mejorar la seguridad, por lo que tendrás que 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 función que Autopilot no admite. Por ejemplo, los clústeres de Autopilot rechazan los pods con privilegios ( |
Modificar las especificaciones de la carga de trabajo en función de los resultados de la comprobación previa
Después de ejecutar la comprobación previa, revisa la salida JSON e identifica las cargas de trabajo que deben modificarse. Te recomendamos que implementes incluso las recomendaciones de configuración opcionales. Cada resultado también proporciona un enlace a la documentación que muestra cómo debe ser la especificación de la carga de trabajo.
La diferencia más importante entre Autopilot y Estándar es que la configuración de la infraestructura en Autopilot se automatiza en función de la especificación de la carga de trabajo. Los controles de programación de Kubernetes, como las intolerancias y tolerancias de nodos, se añaden automáticamente a las cargas de trabajo en ejecución. Si es necesario, también debes modificar las configuraciones de infraestructura como código, como los gráficos de Helm o las superposiciones de Kustomize, para que coincidan.
Estos son algunos de los cambios de configuración habituales que tendrás que hacer:
| Cambios de configuración habituales en Autopilot | |
|---|---|
| Configuración de computación 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 computación, que indica a Autopilot que coloque esos pods en nodos que usen tipos de máquinas o arquitecturas específicos. Para obtener más información, consulta Clases de computación 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 más información, consulta el artículo Desplegar cargas de trabajo de GPUs en Autopilot. |
| Solicitudes de recursos | Todas las cargas de trabajo de Autopilot deben especificar valores para Para obtener más información, consulta Solicitudes de recursos en Autopilot. |
| Cargas de trabajo tolerantes a fallos en máquinas virtuales de acceso puntual | Si tus cargas de trabajo se ejecutan en máquinas virtuales de acceso puntual en Estándar, solicita pods de acceso puntual en la configuración de la carga de trabajo definiendo un selector de nodos para Para obtener más información, consulta el artículo sobre los pods de Spot. |
Realizar una prueba en un clúster de Autopilot de staging
Después de modificar cada manifiesto de carga de trabajo, haz una prueba de implementación en un nuevo clúster de Autopilot de staging para asegurarte de que la carga de trabajo se ejecuta correctamente.
Línea de comandos
Ejecuta el siguiente comando:
kubectl create --dry-run=server -f=PATH_TO_MANIFEST
Sustituye PATH_TO_MANIFEST por la ruta al manifiesto de carga de trabajo modificado.
IDE
Si usas el editor de Cloud Shell, el comando de prueba se incluye y se ejecuta en cualquier manifiesto abierto. Si usas los IDEs Visual Studio Code o IntelliJ, instala la extensión Cloud Code para ejecutar automáticamente la prueba sin cambios en los manifiestos abiertos.
El panel Problemas del IDE muestra los problemas de la prueba, como en la imagen siguiente, que muestra una prueba fallida de un manifiesto que especificaba privileged: true.
Planificar el clúster de Autopilot de destino
Cuando la prueba no muestre ningún problema, planifica y crea el nuevo clúster Autopilot para tus cargas de trabajo. Este clúster es diferente del clúster de piloto automático que has usado para probar las modificaciones del manifiesto en la sección anterior.
Consulta las prácticas recomendadas para incorporar GKE si quieres conocer los requisitos de configuración básicos. A continuación, consulta la descripción general de Autopilot, que proporciona información específica sobre tu caso práctico en diferentes capas.
Además, ten en cuenta lo siguiente:
- Los clústeres de Autopilot son nativos de VPC, por lo que no recomendamos migrar a Autopilot desde clústeres estándar basados en rutas.
- Usa la misma VPC o una similar para el clúster Autopilot y el clúster estándar, incluidas las reglas de cortafuegos personalizadas y la configuración de la VPC.
- Los clústeres de Autopilot usan GKE Dataplane V2 y solo admiten Cilium NetworkPolicies. No se admiten las políticas de red de Calico.
- Si quieres usar el enmascaramiento de IP en Autopilot, utiliza una política de NAT de salida.
- Especifica el intervalo IPv4 principal del clúster durante la creación del clúster, con el mismo tamaño de intervalo que el clúster estándar.
- Consulta las diferencias de cuota entre los modos, sobre todo si tienes clústeres grandes.
- Consulta los máximos de pods por nodo de Autopilot, que son diferentes a los de Estándar. Esto es más importante si usas la afinidad de nodos o pods a menudo.
- Todos los clústeres Autopilot usan Cloud DNS.
Crear el clúster de Autopilot
Cuando quieras crear el clúster, consulta el artículo Crear un clúster de Autopilot. Todos los clústeres de Autopilot son regionales y se registran automáticamente en un canal de lanzamiento, aunque puedes especificar el canal y la versión del clúster. Te recomendamos que despliegues una pequeña carga de trabajo de ejemplo en el clúster para activar el aprovisionamiento automático de nodos, de forma que tus cargas de trabajo de producción se puedan programar inmediatamente.
Actualizar las herramientas de infraestructura como código
Los siguientes proveedores de infraestructura como código admiten Autopilot:
Lee la documentación del proveedor que prefieras y modifica tus configuraciones.
Elegir un método de migración
El método de migración que utilices dependerá de tu carga de trabajo y de tu nivel de conocimiento de conceptos de redes como los servicios multiclúster y el Ingress multiclúster, así como de cómo gestiones el estado de los objetos de Kubernetes en tu clúster.
| Tipo de carga de trabajo | Resultados de la herramienta de comprobación previa | Enfoque de migración |
|---|---|---|
| Apatrida |
|
En el caso de las cargas de trabajo de |
| Con reconocimiento del estado |
|
Puedes usar uno de los siguientes métodos:
|
| Se requiere 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 Migrar manualmente cargas de trabajo con reconocimiento del estado. |
Pasos generales de la migración
Antes de iniciar una migración, asegúrate de haber resuelto los resultados Incompatible o Additional configuration required de la comprobación previa. Si despliegas cargas de trabajo con esos resultados en Autopilot sin modificaciones, las cargas de trabajo fallarán.
En las siguientes secciones se ofrece una descripción general de una migración hipotética. Los pasos reales variarán en función de tu entorno y de cada una de tus cargas de trabajo. Planifica, prueba y vuelve a probar las cargas de trabajo para detectar 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 del número de cargas de trabajo que migres.
- Es obligatorio que haya un periodo de inactividad mientras migras cargas de trabajo con reconocimiento del estado.
- La migración manual te permite centrarte en cargas de trabajo concretas durante la migración para que puedas resolver los problemas en tiempo real de forma individual.
- En todos los casos, asegúrate de migrar los servicios, los Ingresses y otros objetos de Kubernetes que faciliten la funcionalidad de tus cargas de trabajo con y sin estado.
Migrar todas las cargas de trabajo con Backup for 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 devuelve Passed o Passed with optional configuration para cada carga de trabajo, puedes usar Backup for GKE para crear una copia de seguridad de todo el estado de tu clúster Standard y de las cargas de trabajo, y restaurar la copia de seguridad en el clúster de Autopilot.
Este enfoque tiene las siguientes ventajas:
- Puedes mover todas las cargas de trabajo de Estándar a Autopilot con una configuración mínima.
- Puedes mover cargas de trabajo con y sin reconocimiento del estado, y conservar las relaciones entre las cargas de trabajo, así como los PersistentVolumes asociados.
- Las reversiones son intuitivas y las gestiona Google. Puedes revertir toda la migración o revertir selectivamente cargas de trabajo específicas.
- Puedes migrar cargas de trabajo con reconocimiento del estado entre Google Cloud regiones. 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 han recibido un resultado Passed with optional configuration
de la herramienta de comprobación previa. Antes de migrar estas cargas de trabajo, asegúrate de que estás conforme con esos valores predeterminados.
Migrar manualmente cargas de trabajo sin estado sin tiempo de inactividad
Para migrar cargas de trabajo sin estado sin que tus servicios sufran periodos de inactividad, registra los clústeres de origen y de destino en una flota de GKE y usa servicios y recursos Ingress multiclúster para asegurarte de que tus cargas de trabajo sigan disponibles durante la migración.
- Habilita los servicios y el recurso Ingress de varios clústeres en el clúster de origen y en el de destino. Para obtener instrucciones, consulta los artículos Configurar servicios de varios clústeres y Configurar Ingress con varios clústeres.
- Si tienes dependencias de backend, como una carga de trabajo de base de datos, exporta esos servicios de tu clúster estándar mediante servicios multiclúster. De esta forma, las cargas de trabajo de tu clúster Autopilot pueden acceder a las dependencias del clúster estándar. Para obtener instrucciones, consulta el artículo Registrar un servicio para la exportación.
- Despliega un Ingress de varios clústeres y un servicio de varios clústeres para controlar el tráfico entrante entre clústeres. Configura el servicio de varios clústeres para que solo envíe tráfico al clúster Standard. Para obtener instrucciones, consulta el artículo Desplegar objetos Ingress en clústeres.
- Despliega tus cargas de trabajo sin estado con los manifiestos actualizados en el clúster de Autopilot. Los servicios multiclúster exportados se emparejan automáticamente y envían tráfico a las cargas de trabajo con estado correspondientes.
- Actualiza tu servicio 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, tus cargas de trabajo sin estado se sirven 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, ve a Completar la migración. Si tienes cargas de trabajo con reconocimiento del estado, ve a Migrar manualmente cargas de trabajo con reconocimiento del estado.
Migrar manualmente cargas de trabajo con reconocimiento del estado
Después de migrar tus cargas de trabajo sin estado, debes detener y migrar tus cargas de trabajo con estado del clúster Standard. Este paso requiere que el clúster esté inactivo.
- Inicia el tiempo de inactividad de tu entorno.
- Detén tus cargas de trabajo con reconocimiento del estado.
- Asegúrate de haber modificado los manifiestos de tus cargas de trabajo para que sean compatibles con Autopilot. Para obtener más información, consulta Modificar las especificaciones de la carga de trabajo en función de los resultados de la comprobación previa.
Despliega las cargas de trabajo en tu clúster de Autopilot.
Despliega los servicios de tus cargas de trabajo con estado en el clúster de Autopilot.
Actualiza la red de tu clúster para que tus cargas de trabajo sin estado puedan seguir comunicándose con sus cargas de trabajo backend:
- Si has usado una dirección IP estática en los servicios de backend de tu clúster estándar, reutiliza esa dirección IP en Autopilot.
- Si dejas que Kubernetes asigne una dirección IP, implementa tus servicios backend, obtén la nueva dirección IP y actualiza tu DNS para usarla.
En esta fase, se deben cumplir los siguientes requisitos:
- Estás ejecutando todas tus cargas de trabajo sin estado en Autopilot.
- Las cargas de trabajo con reconocimiento del estado del backend también se ejecutan en Autopilot.
- Tus cargas de trabajo con y sin reconocimiento del estado pueden comunicarse entre sí.
- Tu servicio de varios clústeres dirige todo el tráfico entrante a tu clúster Autopilot.
Cuando hayas migrado todas las cargas de trabajo y los objetos de Kubernetes al nuevo clúster, ve a Completar la migración.
Alternativa: Migrar manualmente todas las cargas de trabajo durante el tiempo de inactividad
Si no quieres usar los servicios multiclúster y el recurso Ingress multiclúster para migrar cargas de trabajo con un tiempo de inactividad mínimo, migra todas tus cargas de trabajo durante el tiempo de inactividad. Con este método, los servicios tienen un tiempo de inactividad más largo, pero no es necesario trabajar con funciones multiclúster.
- Empieza tu tiempo de descanso.
- Despliega tus manifiestos sin estado en el clúster de Autopilot.
- Migra manualmente tus cargas de trabajo con reconocimiento del estado. Para obtener instrucciones, consulta la sección Migrar manualmente cargas de trabajo con estado.
- Modifica los registros DNS del tráfico interno y externo entrante para usar las nuevas direcciones IP de los servicios.
- Finaliza tu tiempo de descanso.
Completar la migración
Después de mover todas tus cargas de trabajo y servicios al nuevo clúster de Autopilot, finaliza el tiempo de inactividad y deja que tu entorno se estabilice durante un periodo predeterminado. Cuando estés satisfecho con el estado de la migración y tengas la certeza de que no vas a tener que deshacerla, puedes limpiar los artefactos de migración y completar la migración.
Opcional: Eliminar funciones de varios clústeres
Si has usado Ingress de varios clústeres y Servicios de varios clústeres para migrar y no quieres que tu clúster Autopilot siga registrado en una flota, haz lo siguiente:
- Para el tráfico externo entrante, implementa un objeto Ingress y asígnale la dirección IP de los servicios que expongan tus cargas de trabajo. Para obtener instrucciones, consulta Ingress para balanceadores de carga de aplicación externos.
- En el caso del tráfico dentro del clúster, como el que va de las cargas de trabajo de frontend a las dependencias con estado, actualiza los registros DNS del clúster para que usen las direcciones IP de esos servicios.
- Elimina los recursos de entrada de varios clústeres y de servicio de varios clústeres que hayas creado durante la migración.
- Inhabilita Ingress y los servicios de varios clústeres.
- Da de baja el clúster de Autopilot de la flota.
Elimina el clúster estándar
Una vez que haya transcurrido el tiempo suficiente tras completar la migración y estés conforme con el estado del nuevo clúster, elimina el clúster estándar. Te recomendamos que conserves las copias de seguridad de los manifiestos estándar.
Revertir una migración defectuosa
Si tienes problemas y quieres volver al clúster estándar, haz una de las siguientes acciones, en función de cómo hayas realizado la migración:
Si has usado Copia de seguridad de GKE para crear copias de seguridad durante la migración, restaura las copias de seguridad en el clúster Standard original. Para obtener instrucciones, consulta Restaurar una copia de seguridad.
Si has migrado cargas de trabajo manualmente, repite los pasos de migración de las secciones anteriores con el clúster Estándar como destino y el clúster Autopilot como origen. A grandes rasgos, esto implica los siguientes pasos:
- Iniciar tiempo de descanso.
- Migra manualmente las cargas de trabajo con estado al clúster Estándar. Para ver las instrucciones, consulta la sección Migrar manualmente cargas de trabajo con estado.
- Mueve las cargas de trabajo sin estado al clúster Standard usando 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 cambia tu DNS a las nuevas direcciones IP de los servicios.
- Elimina el clúster de Autopilot.
Siguientes pasos
- Planificar solicitudes de recursos de Autopilot
- Configurar la monitorización
- Configurar y usar el panel de control de postura de seguridad