Actualizaciones de clústeres de Autopilot

En esta página, se explica cómo funcionan las actualizaciones automáticas en los clústeres de Autopilot de Google Kubernetes Engine (GKE), incluidos los vínculos a más información sobre opciones de configuración y tareas relacionadas. Puedes usar esta información a fin de mantener tus clústeres actualizados para lograr una mayor estabilidad y seguridad con interrupciones mínimas en tus cargas de trabajo.

Actualizaciones automáticas del plano de control y los nodos

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

Para actualizar un clúster, GKE actualiza la versión que ejecutan el plano de control y los nodos. Los clústeres se actualizan a una versión secundaria más nueva (por ejemplo, de la 1.24 a la 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 Control de versiones y asistencia de GKE.

Todos los clústeres de Autopilot se inscriben en un canal de versiones, por lo que GKE actualiza automáticamente el plano de control y los nodos para ejecutar 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 clústeres regionales. Los clústeres regionales tienen varias réplicas del plano de control, y solo se actualiza una réplica a la vez, en orden aleatorio. Esto garantiza que el clúster permanezca con alta disponibilidad durante las actualizaciones automáticas. Cada réplica del plano de control deja de estar disponible solo mientras la actualización está en curso.

Si configuras un período de mantenimiento o exclusión, GKE respeta la configuración si es posible.

GKE no puede crear nodos nuevos cuando una actualización del plano de control está en curso, tanto en Autopilot como en Standard. Si implementas Pods de Autopilot que requieren tipos de nodos nuevos mientras se realiza una actualización del plano de control, es posible que experimentes demoras hasta que se complete la actualización del plano de control.

Actualizaciones de nodos automáticas

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

En Autopilot, GKE agrupa los nodos que comparten características similares. GKE usa actualizaciones de aumento para los nodos Autopilot y actualiza hasta 20 nodos de un grupo al mismo tiempo. La cantidad precisa de nodos que se actualizan al mismo tiempo varía para garantizar una alta disponibilidad continua de nodos y cargas de trabajo.

Las actualizaciones de los nodos pueden llevar varias horas según la cantidad de nodos y la configuración de las cargas de trabajo que se ejecutan en los nodos. Por ejemplo, las siguientes configuraciones podrían generar actualizaciones más largas:

Si configuras un período de mantenimiento o exclusión, GKE respeta la configuración si es posible.

Cuando GKE actualiza un nodo, se producen los siguientes 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 existente (el nodo de destino) para actualizarlo.
  3. GKE acordona el nodo de destino, lo que evita que se coloquen Pods nuevos en el nodo de destino.
  4. GKE vacía el nodo de destino y expulsa los Pods existentes del nodo de destino.

  5. GKE reprograma los Pods que administra un controlador de cargas de trabajo en otros nodos disponibles. Los Pods que no se pueden reprogramar permanecen en estado PENDING hasta que GKE puede reprogramarlos.

  6. GKE borra el nodo de destino.

Si una cantidad significativa de actualizaciones automáticas a una versión específica de GKE da como resultado nodos en mal estado en toda la flota de GKE, 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 versiones secundarias nuevas con regularidad, pero una versión lanzada no se selecciona de inmediato para las actualizaciones automáticas. Para calificar como un objetivo de actualización automática, la versión de GKE debe acumular un uso suficiente para demostrar su estabilidad en el tiempo.

Luego, Google Cloud selecciona esa versión como un objetivo de actualización automática para clústeres que ejecutan un subconjunto específico de versiones anteriores de GKE. Por ejemplo, poco después de que una versión secundaria nueva esté disponible, la versión secundaria disponible más antigua por lo general deja de ser compatible. GKE actualiza los clústeres que ejecutan versiones secundarias no compatibles a la versión de destino de actualización automática.

GKE anuncia versiones nuevas de destino de actualización automática en las notas de la versión. A veces, se selecciona una versión para las actualizaciones automáticas del plano de control y las actualizaciones automáticas de nodos durante diferentes semanas. GKE se actualiza automáticamente a versiones de parche nuevas dentro de una versión secundaria (como v1.21.x).

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

Factores que afectan el tiempo de lanzamiento de la versión

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

Algunas de las prácticas recomendadas son las siguientes:

  • GKE lanza de forma gradual cambios en las regiones y zonas de Google Cloud.
  • GKE lanza de forma gradual versiones de parches en canales de versiones. A un parche se le otorga tiempo de prueba en el canal de versiones rápido. Luego, el canal de versiones regular, antes de que se lo ascienda al canal de versiones estable una vez que se haya acumulado el uso y siga demostrando estabilidad. Si se encuentra un problema con una versión del parche durante el tiempo de prueba en un canal de versiones, esa versión no se promueve al siguiente canal y el problema se soluciona en una versión del parche más reciente.
  • GKE lanza de forma gradual versiones secundarias y sigue un proceso de incorporación similar a las versiones de parches. Las versiones secundarias tienen períodos de prueba más largos, ya que presentan cambios más significativos.
  • GKE puede retrasar las actualizaciones automáticas cuando una versión nueva afecta a un grupo de clústeres. Por ejemplo, GKE pausa las actualizaciones automáticas para los clústeres que detecta que se exponen a una API o función obsoleta que se quitará en la próxima versión secundaria.
  • GKE podría retrasar el lanzamiento de versiones nuevas durante los momentos de mayor actividad (por ejemplo, los feriados principales) para garantizar la continuidad del negocio.

Configura cuándo ocurren las actualizaciones automáticas

De forma predeterminada, las actualizaciones automáticas pueden ocurrir en cualquier momento. Las actualizaciones automáticas ocasionan muy pocas interrupciones, en especial en los clústeres de Autopilot. Sin embargo, algunas cargas de trabajo podrían requerir una supervisión más detallada. Puedes configurar las exclusiones y los períodos de mantenimiento para que administren cuándo pueden ocurrir las actualizaciones automáticas y cuándo no.

Si configuras exclusiones y períodos de mantenimiento, la actualización no se produce hasta que la hora actual se encuentre dentro de un período de mantenimiento. Si un período de mantenimiento termina antes de que se complete la actualización, GKE intenta pausar la actualización. GKE reanuda la actualización durante el siguiente período de mantenimiento disponible.

Actualiza un clúster de Autopilot de forma manual

Puedes actualizar de forma manual la versión de GKE de tu plano de control del clúster de Autopilot. GKE actualiza de forma automática tus nodos para que coincidan con la versión del plano de control lo antes posible, sujeto a la disponibilidad de mantenimiento. Para obtener instrucciones, consulta Actualiza el plano de control de forma manual. No puedes administrar de forma manual la versión del nodo para los clústeres de Autopilot.

Puedes actualizar la versión del plano de control a una versión menor o de parche compatible en el mismo canal de versiones o a una versión de parche de la misma versión menor que el clúster en un canal de versiones diferente.

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

  • Puedes actualizar a cualquier versión en el canal regular.
  • Puedes actualizar a cualquier versión de parche de 1.22 en el canal rápido.

Para obtener más información sobre la actualización fuera de tu canal, consulta Ejecuta versiones de parches desde un canal más reciente.

Actualizaciones de aumento

Los clústeres de Autopilot usan actualizaciones de aumento para actualizar varios nodos al mismo tiempo. Las actualizaciones de aumento permiten que GKE reduzca la cantidad de interrupciones que generan las actualizaciones de versión en tus cargas de trabajo en ejecución, ya que mantienen una capacidad de procesamiento suficiente para tus cargas de trabajo en ejecución. Autopilot administra la cantidad de nodos de aumento que se agregan al clúster durante la actualización. Esta cantidad varía según el tamaño total del clúster. GKE también administra la cantidad total de nodos de destino que pueden dejar de estar disponibles de forma simultánea durante la actualización.

La cantidad de nodos de aumento nuevos y los nodos de destino no disponibles varía a fin de garantizar que tu clúster siempre tenga suficiente capacidad de procesamiento para todas las cargas de trabajo en ejecución. Es posible que experimentes interrupciones menores 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 aumento, consulta Actualizaciones de nodos automáticas.

Requisitos de cuota para actualizaciones de aumento

A diferencia de la recreación de nodos, las actualizaciones de aumento requieren recursos adicionales de Compute Engine. La asignación de recursos depende de tu cuota de Compute Engine disponible. Según la configuración que uses, esta cuota puede limitar la cantidad de actualizaciones paralelas o incluso hacer que la actualización falle. Como práctica recomendada para evitar problemas de escalamiento y para obtener actualizaciones más predecibles, asegúrate de que la cuota de tu instancia de Compute Engine no supere el 90%.

Si deseas obtener más información sobre la cuota, consulta Garantiza recursos para las actualizaciones de nodos.

Recibe notificaciones de actualización

GKE publica notificaciones de actualización en Pub/Sub, lo que te brinda un canal para recibir información de GKE sobre tus clústeres.

Para obtener más información, consulta Recibe notificaciones del clúster.

Actualizaciones de componentes

GKE ejecuta cargas de trabajo del sistema en nodos trabajadores a fin de admitir capacidades específicas para los clústeres. Por ejemplo, la carga de trabajo del sistema gke-metadata-server admite la federación de identidades para cargas de trabajo para GKE. GKE es responsable del estado de estas cargas de trabajo. Para obtener más información sobre estos componentes, consulta la documentación de las capacidades 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 última versión de un componente, consulta la documentación asociada o las notas de la versión a fin de obtener instrucciones para actualizar el plano de control o los nodos a la versión adecuada.

¿Qué sigue?