Actualizaciones de clústeres de Autopilot

En esta página se explica cómo funcionan las actualizaciones automáticas en los clústeres Autopilot de Google Kubernetes Engine (GKE), incluidos enlaces a más información sobre tareas y ajustes relacionados. Puedes usar esta información para mantener tus clústeres actualizados por motivos de estabilidad y seguridad con las mínimas interrupciones en tus cargas de trabajo.

Para obtener una descripción general de las actualizaciones de clústeres, consulta Acerca de las actualizaciones de clústeres de GKE. Para obtener información sobre cómo funcionan las actualizaciones de clústeres en el caso de los clústeres estándar, consulta Actualizaciones de clústeres estándar.

Actualizaciones automáticas del plano de control y de los nodos

Las actualizaciones automáticas están habilitadas en todos los clústeres de Autopilot. GKE inicia las actualizaciones automáticas cuando se seleccionan versiones de GKE para la actualización automática, observa las actualizaciones automáticas en todos los clústeres e interviene si se producen problemas, como nodos con mal estado. No puedes inhabilitar las actualizaciones automáticas, pero sí controlar su programación con ventanas y exclusiones de mantenimiento.

Para actualizar un clúster, GKE actualiza la versión en la que se ejecutan el plano de control y los nodos. Los clústeres se actualizan a una versión secundaria más reciente (por ejemplo, de 1.24 a 1.25) o a una versión de parche más reciente (por ejemplo, de 1.24.2-gke.100 a 1.24.5-gke.200). Para obtener más información, consulta Versiones y asistencia de GKE.

Todos los clústeres de Autopilot están registrados en un canal de lanzamiento, por lo que GKE actualiza automáticamente el plano de control y los nodos para que ejecuten la misma versión de GKE.

GKE actualiza el plano de control de un clúster antes de actualizar los nodos.

Actualizaciones automáticas del plano de control

Todos los clústeres de Autopilot son regionales. Los clústeres regionales tienen varias réplicas del plano de control y solo se actualiza una réplica a la vez, en un orden indefinido. De esta forma, el clúster mantiene una alta disponibilidad durante las actualizaciones automáticas. Cada réplica del plano de control solo no está disponible mientras se lleva a cabo la actualización.

Si configuras una ventana de mantenimiento o una exclusión, GKE respetará la configuración si es posible.

GKE no puede crear nodos cuando se está actualizando el plano de control. Si implementas pods que requieren nuevos tipos de nodos mientras se está actualizando el plano de control, es posible que se produzcan retrasos hasta que se complete la actualización.

Actualizaciones automáticas de nodos

Después de que GKE actualice el plano de control de tu clúster de Autopilot, GKE actualizará los nodos a la misma versión de GKE.

En Autopilot, GKE agrupa los nodos que comparten características similares. GKE usa actualizaciones de picos para los nodos de Autopilot, actualizando hasta 20 nodos de un grupo al mismo tiempo. El número exacto de nodos que se actualizan al mismo tiempo varía para asegurar que los nodos y las cargas de trabajo sigan teniendo una alta disponibilidad.

Las actualizaciones de nodos pueden tardar varias horas en función del número de nodos y de la configuración de las cargas de trabajo que se ejecutan en los nodos. Por ejemplo, las siguientes configuraciones pueden contribuir a que las actualizaciones sean más largas:

Si configuras una ventana de mantenimiento o una exclusión, GKE respeta la configuración si es posible.

Cuando GKE actualiza un nodo, se siguen estos pasos:

  1. GKE crea un nuevo nodo de aumento con la nueva versión de GKE y espera a que el nodo de aumento se registre en el plano de control.
  2. GKE selecciona un nodo, el nodo de destino, para actualizarlo.
  3. GKE aisla el nodo de destino, lo que impide que se coloquen nuevos pods en él.
  4. GKE agota el nodo de destino, lo que provoca que se expulsen los pods del nodo de destino.

  5. GKE vuelve a programar los pods gestionados por un controlador de carga de trabajo en otros nodos disponibles. Los pods que no se pueden reprogramar permanecen en estado PENDING hasta que GKE pueda reprogramarlos.

  6. GKE elimina el nodo de destino.

Si un número significativo de actualizaciones automáticas a una versión específica de GKE provoca que los nodos de la flota de GKE no estén en buen estado, GKE detiene las actualizaciones a esa versión mientras investigamos el problema.

Cómo se seleccionan las versiones para la actualización automática

GKE lanza nuevas versiones secundarias con regularidad, pero una versión publicada no se selecciona inmediatamente para las actualizaciones automáticas. Para poder actualizarse automáticamente, la versión de GKE debe acumular suficiente uso para demostrar su estabilidad a lo largo del tiempo.

Google Cloud y, a continuación, selecciona esa versión como destino de actualización automática para los clústeres que ejecutan un subconjunto específico de versiones anteriores de GKE. Por ejemplo, poco después de que esté disponible una nueva versión secundaria, normalmente deja de ofrecerse asistencia técnica para la versión secundaria más antigua. GKE actualiza los clústeres que ejecutan versiones secundarias no admitidas a la versión de destino de la actualización automática.

GKE anuncia las nuevas versiones de destino de actualización automática en las notas de la versión. En ocasiones, se selecciona una versión para las actualizaciones automáticas del plano de control y de los nodos en semanas diferentes. GKE se actualiza automáticamente a las nuevas versiones de parche de una versión secundaria (como la 1.21.x). Para obtener los destinos de actualización automática de un clúster específico, consulta Obtener información sobre las actualizaciones de un clúster.

Para obtener información sobre el ciclo de vida de las versiones y el esquema de control de versiones, consulta Versiones y asistencia de GKE.

Factores que afectan a los plazos de lanzamiento de versiones

Para garantizar la estabilidad y la fiabilidad de los clústeres en las nuevas versiones, GKE sigue ciertas prácticas durante los lanzamientos de versiones.

Estas prácticas incluyen, entre otras:

  • GKE implementa los cambios de forma gradual en las Google Cloud regiones y zonas.
  • GKE lanza gradualmente versiones de parche en los canales de lanzamiento. Los parches se someten a un periodo de prueba en el canal de lanzamiento Rápido y, después, en el canal de lanzamiento Habitual, antes de pasar al canal de lanzamiento Estable una vez que se hayan usado lo suficiente y sigan demostrando estabilidad. Si se detecta un problema con una versión de parche durante el tiempo de permanencia en un canal de lanzamiento, esa versión no se promociona al siguiente canal y el problema se corrige en una versión de parche más reciente.
  • GKE lanza gradualmente versiones secundarias, siguiendo un proceso de prueba similar al de las versiones de parche. Las versiones secundarias tienen periodos de prueba más largos, ya que introducen cambios más significativos.
  • GKE puede retrasar las actualizaciones automáticas cuando una nueva versión afecte a un grupo de clústeres. Por ejemplo, GKE pausa las actualizaciones automáticas de los clústeres que detecta que están expuestos a una API o una función obsoleta que se eliminará en la próxima versión secundaria.
  • GKE puede retrasar el lanzamiento de nuevas versiones durante las horas punta (por ejemplo, en las principales festividades) para garantizar la continuidad del negocio.

Configurar cuándo se pueden realizar las actualizaciones automáticas

De forma predeterminada, las actualizaciones automáticas pueden producirse en cualquier momento. Las actualizaciones automáticas son mínimamente disruptivas, sobre todo en los clústeres de Autopilot. Sin embargo, es posible que algunas cargas de trabajo requieran un control más preciso. Puedes configurar ventanas de mantenimiento y exclusiones para gestionar cuándo se pueden y cuándo no se deben producir las actualizaciones automáticas.

Si configuras ventanas de mantenimiento y exclusiones, la actualización no se producirá hasta que la hora actual esté dentro de una ventana de mantenimiento. Si una ventana de mantenimiento caduca antes de que se complete la actualización, GKE intentará pausarla. GKE reanuda la actualización durante la siguiente ventana de mantenimiento disponible.

Actualizar manualmente un clúster de Autopilot

Puedes actualizar manualmente la versión de GKE del plano de control de tu clúster de Autopilot. GKE actualiza automáticamente tus nodos para que coincidan con la versión del plano de control lo antes posible, en función de la disponibilidad del mantenimiento. Para obtener instrucciones, consulta Actualizar manualmente el plano de control. No puedes gestionar manualmente la versión de los nodos de los clústeres de Autopilot.

Puedes actualizar la versión del plano de control a una versión secundaria o de parche compatible del mismo canal de lanzamiento, o bien a una versión de parche de la misma versión secundaria que tu clúster en otro canal de lanzamiento.

Por ejemplo, supongamos que tienes un clúster de Autopilot que ejecuta la versión 1.22.8-gke.202 de GKE en el canal de lanzamiento habitual. Se aplica el siguiente comportamiento:

  • Puedes cambiarte a cualquier versión de Regular.
  • Puedes cambiar a cualquier versión de parche de 1.22 en el canal Rápido.

Para obtener más información sobre cómo actualizar fuera de tu canal, consulta Ejecutar versiones de parche de un canal más reciente.

Sobreaprovisionamiento para actualizaciones

Los clústeres de Autopilot usan actualizaciones de picos para actualizar varios nodos al mismo tiempo. Las actualizaciones de picos permiten a GKE reducir el impacto de las actualizaciones de versiones en tus cargas de trabajo en ejecución, ya que mantiene suficiente capacidad de computación para ellas. Autopilot gestiona el número de nodos de aumento que se añaden al clúster durante la actualización. Este número varía en función del tamaño total del clúster. GKE también gestiona el número total de nodos de destino que pueden no estar disponibles simultáneamente durante la actualización.

El número de nodos de sobrecarga nuevos y de nodos de destino no disponibles varía para asegurar que tu clúster siempre tenga suficiente capacidad de computación para todas las cargas de trabajo en ejecución. Es posible que experimentes interrupciones leves mientras GKE migra las cargas de trabajo de los nodos de destino a los nodos de aumento durante la actualización.

Para obtener una descripción de cómo se producen las actualizaciones de picos, consulta el artículo Actualizaciones automáticas de nodos.

Requisitos de cuota para las actualizaciones de picos

A diferencia de la recreación de nodos, las actualizaciones de sobreaprovisionamiento requieren recursos adicionales de Compute Engine. La asignación de recursos depende de la cuota de Compute Engine disponible. En función de tu configuración, esta cuota puede limitar el número de actualizaciones paralelas o incluso provocar que la actualización falle. Para evitar problemas de escalado y que las actualizaciones sean más predecibles, te recomendamos que no superes el 90 % de la cuota de instancias de Compute Engine.

Para obtener más información sobre las cuotas, consulta el artículo Asegurar recursos para las actualizaciones de nodos.

Recibir notificaciones de actualización

GKE publica notificaciones de actualizaciones en Pub/Sub, lo que significa que GKE te enviará información sobre tus clústeres a través de este canal.

Para obtener más información, consulta Recibir notificaciones de clústeres.

Actualizaciones de componentes

GKE ejecuta cargas de trabajo del sistema en nodos de trabajo para admitir funciones específicas de los clústeres. Por ejemplo, la carga de trabajo del sistema gke-metadata-server admite Workload Identity Federation para GKE. GKE es responsable de la salud de estas cargas de trabajo. Para obtener más información sobre estos componentes, consulta la documentación de las funciones asociadas.

Cuando hay nuevas funciones o correcciones disponibles para un componente, GKE indica la versión del parche en la que se incluyen. Para obtener la versión más reciente de un componente, consulta la documentación asociada o las notas de la versión para obtener instrucciones sobre cómo actualizar el plano de control o los nodos a la versión adecuada.

Siguientes pasos