Actualizaciones de clústeres estándar


En esta página, se explica cómo funcionan las actualizaciones automáticas y manuales en los clústeres estándar 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.

A fin de obtener información sobre cómo funcionan las actualizaciones del clúster para Autopilot, consulta Actualizaciones de clústeres de Autopilot.

Cómo funcionan las actualizaciones de clúster y grupo de nodos

En esta sección, se explica qué sucede en tu clúster durante las actualizaciones automáticas o manuales. En el caso de las actualizaciones automáticas, Google inicia la actualización automática. Google supervisa las actualizaciones automáticas y manuales en todos los clústeres de GKE y solo interviene si se encuentran problemas.

Si inscribes tu clúster en un canal de versiones, los nodos siempre ejecutan la misma versión de GKE que el clúster, excepto durante un período breve (por lo general, unos días, según la versión actual) entre la finalización de la actualización del plano de control del clúster y el inicio de la actualización del grupo de nodos. Consulta las notas de la versión para obtener más información.

Actualizaciones de clústeres

En esta sección, se explica qué sucederá cuando Google actualice tu clúster de forma automática o inicies una actualización manual.

  • Los clústeres zonales tienen un solo plano de control. Durante la actualización, tus cargas de trabajo continúan ejecutándose, pero no puedes implementar cargas de trabajo nuevas, modificar cargas de trabajo existentes ni realizar otros cambios en la configuración del clúster hasta que se complete la actualización.

  • 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. Durante la actualización, el clúster sigue teniendo alta disponibilidad, y las réplicas del plano de control no están disponibles solo mientras se están actualizando.

Si configuras una exclusión o un período de mantenimiento, se respetará cuando sea posible.

Actualizaciones de grupo de nodos

El clúster y los grupos de nodos no siempre ejecutan la misma versión de GKE. En esta sección, se analiza qué sucede cuando Google actualiza tu grupo de nodos de forma automática o cuando inicias una actualización manual del grupo de nodos.

Los grupos de nodos se actualizan de a uno. De forma predeterminada, los nodos de un grupo de nodos se actualizan de a uno, en orden aleatorio. Puedes cambiar la cantidad de nodos que se actualizan a la vez.

Durante la actualización de un grupo de nodos, no puedes realizar cambios en la configuración del clúster, a menos que canceles la actualización.

Este proceso puede tardar varias horas según la cantidad de nodos y sus configuraciones de carga de trabajo. Las configuraciones que pueden disminuir la velocidad de las actualizaciones de nodos incluyen las siguientes:

GKE respeta los períodos de mantenimiento o las exclusiones durante las actualizaciones automáticas cuando es posible. Las actualizaciones manuales omiten las exclusiones y los períodos de mantenimiento configurados.

Cuando GKE actualiza un nodo, sucede lo siguiente:

  1. Si las actualizaciones de aumento están habilitadas, GKE crea un nodo de aumento nuevo con la versión actualizada y espera a que se registre con el plano de control.
  2. GKE selecciona un nodo existente (el nodo de destino) para actualizarlo. Acordona y comienza a desviar el tráfico del nodo de destino. En este punto, GKE no puede programar nuevos pods en el nodo de destino.
    • PodDisruptionBudget se respeta hasta por una hora. Si el nodo de destino no se desvía por completo después de una hora, GKE borra los Pods restantes y el proceso de actualización continúa.
    • GracefulTerminationPeriod se limita a una hora.
  3. El plano de control reprograma los Pods administrados por controladores en otros nodos. Los pods que no se pueden reprogramar permanecen en la fase Pendiente hasta que se pueden programar.
  4. Si se creó un nodo de aumento, se borra el nodo de destino. Si no se creó un nodo de aumento, GKE actualiza el nodo de destino una vez que se desvía y espera a que se registre con el plano de control.

Actualizaciones automáticas

Cuando creas un clúster estándar, de forma predeterminada, la actualización automática se habilita en el clúster y en sus grupos de nodos.

Google es responsable de proteger el plano de control de tu clúster y actualizar tus clústeres cuando se selecciona una nueva versión de GKE para una actualización automática. La seguridad de la infraestructura es de alta prioridad para GKE, y esos planos de control se actualizan periódicamente y no se pueden inhabilitar. Sin embargo, puedes aplicar exclusiones y períodos de mantenimiento para suspender de forma temporal las actualizaciones de los planos de control y los nodos.

Con el Modelo de responsabilidad compartida, eres responsable de proteger tus nodos, contenedores y Pods. La actualización automática de nodo se habilita de forma predeterminada. Aunque no se recomienda, puedes inhabilitar la actualización automática de los nodos. Inhabilitar las actualizaciones automáticas de nodos no bloquea la actualización del plano de control de tu clúster. Si lo haces, eres responsable de garantizar que los nodos del clúster ejecuten una versión compatible con la versión del clúster y que la versión cumpla con lasPolítica de compatibilidad de versiones y del sesgo de versiones de Kubernetes.

Si quieres supervisar cuándo puede ocurrir una actualización automática (o cuándo no debe ocurrir), puedes configurar las exclusiones y los períodos de mantenimiento.

Los grupos de nodos de un clúster no pueden tener más de dos versiones secundarias anteriores a la versión del plano de control para mantener la compatibilidad con la API del clúster. La versión del grupo de nodos también determina las versiones de los paquetes de software que se instalan en cada nodo. Se recomienda mantener los grupos de nodos actualizados a la versión del clúster.

Si inscribes tu clúster en un canal de versiones, los nodos siempre ejecutan la misma versión de GKE que el clúster mismo, excepto durante un período breve (generalmente unos días, según la versión actual) entre completar la actualización del plano de control del clúster y comenzar a actualizar un grupo de nodos determinado. Consulta las notas de la versión para obtener más información.

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

Las nuevas versiones de GKE se lanzan con regularidad, pero no se selecciona una versión para la actualización automática de inmediato. Cuando una versión de GKE ya acumuló suficiente uso del clúster para demostrar la estabilidad en el tiempo, Google la selecciona como la actualización automática que se asignará a clústeres que ejecutan un subconjunto de versiones anteriores.

Estas asignaciones de actualización automática nuevas se anuncian en las notas de la versión. Hasta que se seleccione una versión disponible para la actualización automática, puedes actualizarla de forma manual. A veces, se selecciona una versión para la actualización automática de clústeres y la actualización automática de nodos en diferentes semanas.

Por lo general, poco tiempo después de que una versión secundaria cuente con disponibilidad general, la versión secundaria disponible más antigua deja de ser compatible. Los clústeres que ejecutan versiones secundarias que dejan de ser compatibles se actualizan de forma automática a la siguiente versión secundaria.

En una versión secundaria (como v1.14.x), los clústeres pueden actualizarse a una versión de parche nueva de forma automática.

Los canales de versiones te permiten supervisar la versión de tu grupo de nodos y clúster en función de la estabilidad de la versión en vez de administrarla directamente.

Configura cuándo ocurren las actualizaciones automáticas

De forma predeterminada, las actualizaciones automáticas pueden ocurrir en cualquier momento para preservar la seguridad de la infraestructura. Las actualizaciones automáticas ocasionan muy poca interrupción, en especial en los clústeres regionales. Sin embargo, algunas cargas de trabajo pueden 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.

Actualizaciones manuales

Puedes solicitar actualizar tu clúster o sus grupos de nodos de forma manual a una versión disponible y compatible en cualquier momento. Las actualizaciones manuales omiten los períodos de mantenimiento configurados y las exclusiones de mantenimiento.

Cuando actualizas un clúster de forma manual, su disponibilidad depende de si el clúster es regional o no:

  • Para los clústeres zonales, el plano de control no está disponible mientras se realiza la actualización. Por lo general, las cargas de trabajo se ejecutan con normalidad, pero no pueden modificarse durante la actualización.

  • Para los clústeres regionales, no hay una réplica del plano de control disponible mientras se realiza la actualización, pero el clúster permanece con alta disponibilidad.

Puedes iniciar una actualización de nodo de forma manual a una versión compatible con el plano de control.

Actualizaciones de aumento

Las actualizaciones de aumento te permiten controlar la cantidad de nodos que GKE puede actualizar a la vez y controlar cuánta interrupción generan las actualizaciones en las cargas de trabajo.

Cambia la configuración de actualizaciones para equilibrar la velocidad y la interrupción

Para cambiar la cantidad de nodos que GKE intenta actualizar a la vez, modifica los parámetros de actualización de aumento en un grupo de nodos. Las actualizaciones de aumento reducen la cantidad de interrupciones en las cargas de trabajo durante el mantenimiento del clúster y, también, te permiten controlar la cantidad de nodos que se actualizan en paralelo. Las actualizaciones de aumento también funcionan con el escalador automático del clúster para evitar que se realicen cambios en los nodos que se están actualizando.

El comportamiento de la actualización de aumento se determina mediante dos parámetros de configuración:

max-surge-upgrade

La cantidad de nodos adicionales que se pueden agregar al grupo de nodos durante la actualización. Si aumentas max-surge-upgrade, también aumenta la cantidad de nodos que se pueden actualizar de forma simultánea. El valor predeterminado es 1. Se puede establecer en 0 o más.

max-unavailable-upgrade

La cantidad de nodos que pueden no estar disponibles de forma simultánea durante una actualización. El valor predeterminado es 0. Si aumentas max-unavailable-upgrade, también aumenta la cantidad de nodos que se pueden actualizar en paralelo.

La cantidad de nodos actualizados de forma simultánea es la suma de max-surge-upgrade y max-unavailable-upgrade. La cantidad máxima de nodos actualizados de forma simultánea es 20.

Por ejemplo, se crea un grupo de 5 nodos con max-surge-upgrade establecido en 2 y max-unavailable-upgrade establecido en 1. Durante una actualización del grupo de nodos, GKE crea dos nodos actualizados. GKE desactiva como máximo tres (la suma de max-surge-upgrade y max-unavailable-upgrade) nodos existentes después de que los nodos actualizados estén listos. GKE hará que solo haya un nodo no disponible (max-unavailable-upgrade) a la vez. Durante el proceso de la actualización, el grupo de nodos incluirá entre cuatro y siete nodos.

Puedes configurar parámetros de actualización de aumento para grupos de nodos que usan actualizaciones automáticas y actualizaciones manuales. Si deseas obtener más información y probar la actualización de aumento, completa el instructivo “Usa actualizaciones de aumento para disminuir las interrupciones de las actualizaciones de nodos de GKE”.

Determina la configuración de aumento óptima

En la siguiente tabla, se describen tres configuraciones de actualización diferentes para ayudarte a comprender las diferentes configuraciones:

Descripción Configuración
Equilibrado (predeterminado), más lento, pero con interrupciones mínimas maxSurge=1 maxUnavailable=0
Rápido, sin recursos de aumento, interrupciones máximas maxSurge=0 maxUnavailable=20
Rápido, con la mayoría de los recursos de aumento y menos interrupciones maxSurge=20 maxUnavailable=0

Equilibrado (predeterminado)

La forma más sencilla de aprovechar la actualización de aumento es configurar maxSurge=1 maxUnavailable=0.. Esto significa que solo se puede agregar 1 nodo de aumento al grupo de nodos durante una actualización, por lo que solo se actualizará 1 nodo a la vez. Esta configuración es superior a la configuración de actualización existente (maxSurge=0 maxUnavailable=1) porque acelera el reinicio del pod durante las actualizaciones mientras avanza de forma conservadora.

Rápido sin recursos de aumento

Si tu carga de trabajo no es sensible a la interrupción, como la mayoría de los trabajos por lotes, puedes enfatizar la velocidad mediante maxSurge=0 maxUnavailable=20. Esta configuración no genera nodos de aumento adicionales y permite que se actualicen 20 nodos al mismo tiempo.

Rápido con menos interrupciones

Si tu carga de trabajo es sensible a las interrupciones, ya configuraste PodDisruptionBudgets (PDB) y no usas externalTrafficPolicy: Local, que no funciona con desvíos de nodos paralelos, puedes aumentar la velocidad de la actualización mediante maxSurge=20 maxUnavailable=0. Esta configuración actualiza 20 nodos en paralelo, mientras que el PDB limita la cantidad de pods que se pueden desviar a la vez. Aunque las configuraciones de los PDB pueden variar, si creas un PDB con maxUnavailable: 1 para una o más de las cargas de trabajo que se ejecutan en el grupo de nodos, solo se puede expulsar un pod de esas cargas de trabajo a la vez, lo que limita el paralelismo de toda la actualización.

Relación con la cuota

Si bien la recreación de nodos no requiere recursos adicionales de Compute Engine, los nodos de actualizaciones de aumento sí los necesitan. La asignación de recursos está sujeta a la Cuota de Compute Engine. Según la configuración que uses, esta cuota puede limitar la cantidad de actualizaciones paralelas o incluso hacer que la actualización falle.

Si deseas obtener más información sobre las cuotas, consulta Actualizaciones y cuotas de los nodos.

Cómo GKE responde a las fallas de actualización automática

Las actualizaciones automáticas de grupos de nodos pueden fallar debido a problemas con las instancias de Compute Engine subyacentes o problemas con Kubernetes. Por ejemplo, las actualizaciones automáticas fallan en las siguientes situaciones:

  • El parámetro maxSurge configurado supera la cuota de recursos de Compute Engine.
  • Los nodos de aumento nuevos no se registraron con el plano de control del clúster.
  • Los nodos tardaron demasiado en desviarse o tardaron demasiado en borrarse.

Cuando se producen problemas con las actualizaciones de nodos individuales, GKE vuelve a intentar la actualización varias veces, con un intervalo cada vez mayor entre reintentos. Si los nodos del grupo de nodos no se actualizan, GKE no revierte los nodos actualizados. En su lugar, GKE vuelve a intentar la actualización automática del grupo de nodos hasta que todos los nodos se actualicen de forma correcta.

Si las actualizaciones de los nodos fallan porque las solicitudes de nodos de aumento superan la cuota de Compute Engine, GKE reduce la cantidad de nodos de aumento simultáneos para intentar cumplir con la cuota y continuar con la actualización.

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 la sección sobre cómo recibir notificaciones de actualización del clúster.

¿Qué sigue?