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, GKE inicia la actualización automática. GKE supervisa las actualizaciones automáticas y manuales en todos los clústeres de GKE y solo interviene si se encuentran problemas.

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.

Si inscribes tu clúster en un canal de versiones, los nodos 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, o si el plano de control se actualizó de forma manual. 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 GKE actualice tu clúster de forma automática o inicies una actualización manual.

  • Los clústeres Zonal 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

En esta sección, se analiza qué sucede cuando GKE actualiza tu grupo de nodos de forma automática o cuando inicias una actualización manual del grupo de nodos.

GKE actualiza automáticamente un grupo de nodos a la vez en un clúster. Como alternativa, puedes actualizar de forma manual uno o más grupos de nodos en paralelo. De forma predeterminada, los nodos dentro de un grupo de nodos se actualizan de a uno en un orden arbitrario. En un grupo de nodos distribuido en varias zonas, las actualizaciones se realizan zona por zona. Dentro de una zona, los nodos se actualizarán en un orden indefinido.

Con las actualizaciones del grupo de nodos de GKE, puedes elegir entre dos estrategias de actualización integradas y configurables en las que puedes ajustar el proceso de actualización según las necesidades de tu entorno de clúster. Para obtener más información sobre las estrategias de actualización de aumento y azul-verde, consulta Estrategias de actualización.

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.

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

Cómo se actualizan los nodos

Durante una actualización del grupo de nodos, la forma en que se actualizan los nodos depende de la estrategia de actualización del grupo de nodos y de cómo la configuras. Sin embargo, los pasos básicos siguen siendo coherentes. Para actualizar un nodo, GKE quita los Pods del nodo a fin de que se pueda actualizar.

Cuando se actualiza un nodo, sucede lo siguiente con los Pods:

  1. El nodo está acordonado para que Kubernetes no programe nuevos Pods en él.
  2. Luego, el nodo se vacía, lo que significa que se quitan los Pods. Para las actualizaciones de aumento, GKE respeta la configuración de PodDisruptionBudget y GracefulTerminationPeriod del Pod durante un máximo de una hora. Con las actualizaciones azul-verde, esto se puede extender si configuras un tiempo de prueba más largo.
  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 puedan reprogramar.

El proceso de actualización del grupos de nodos puede tomar algunas horas según la estrategia de actualización, la cantidad de nodos y las configuraciones de su carga de trabajo.

Consideraciones que afectan la duración de la actualización de nodos

Las opciones de configuración que pueden hacer que la actualización de un nodo tarde más en completarse son las siguientes:

Estrategias de actualización de nodos

GKE ofrece estrategias integradas configurables que determinan cómo se actualiza el grupo de nodos. Para obtener más información acerca de los tipos de cambios que usan una estrategia de actualización de nodos, consulta Cuando GKE usa actualizaciones de aumento y Cuando GKE usa actualizaciones azul-verde.

Actualizaciones de aumento

De forma predeterminada, la estrategia de actualización de aumento se usa para las actualizaciones del grupo de nodos. Las actualizaciones de aumento usan un método progresivo para actualizar los nodos. Esta estrategia es la mejor para las aplicaciones que pueden manejar cambios incrementales y no disruptivos. Con esta estrategia, los nodos se actualizan en una ventana progresiva. Con esta configuración, puedes cambiar cuántos nodos se pueden actualizar a la vez y qué nivel de interrupción pueden causar las actualizaciones, de modo que puedas encontrar el equilibrio óptimo entre velocidad e interrupción de acuerdo con las necesidades de tu entorno.

Actualizaciones azul-verde

El enfoque alternativo son las actualizaciones azul-verde, en las que se mantienen dos conjuntos de entornos (los entornos original y nuevo) a la vez, lo que facilita la reversión tanto como sea posible. El método azul-verde requiere más recursos y es mejor para aplicaciones más sensibles a los cambios. Con esta estrategia, las cargas de trabajo se migran de forma gradual del entorno original “azul” al entorno “verde” nuevo y se les otorga tiempo de prueba para validarlas con la configuración nueva. Si es necesario, las cargas de trabajo se pueden revertir rápidamente al entorno “azul” existente.

Para obtener más información acerca de cómo funcionan las estrategias de actualización de nodos, consulta Estrategias de actualización de nodos.

Requisitos de los recursos para las estrategias de actualización de nodos

Las actualizaciones de aumento crean VMs adicionales (si maxSurge se establece en un valor mayor que 0) y las actualizaciones azul-verde temporalmente duplican la cantidad de nodos en un grupo de nodos. Esto requiere recursos adicionales, que están sujetos a la cuota de Compute Engine, la disponibilidad de recursos y la reserva. Si tu grupo de nodos no tiene recursos suficientes, las actualizaciones pueden tardar más tiempo o pueden fallar.

Para obtener más información sobre cómo garantizar que tu proyecto tenga recursos suficientes para las actualizaciones de nodos y qué hacer si tu entorno tiene recursos limitados, consulta Garantiza recursos para las actualizaciones de nodos.

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.

GKE 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.

Como parte del modelo de responsabilidad compartida de GKE, 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 la Política de compatibilidad con el 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, GKE 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.

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 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 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.

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 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 los reintentos. Si los nodos del grupo de nodos no se logran actualizar, 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 sobre eventos relevantes para el clúster, como actualizaciones de versiones y boletines de seguridad, en Pub/Sub, lo que te brinda un canal para recibir información de GKE sobre los clústeres.

Para obtener más información, consulta la sección sobre cómo recibir notificaciones de clúster.

Verifica los registros de actualización

GKE registra los eventos de actualización del plano de control y de los grupos de nodos en Cloud Logging de forma predeterminada. El registro de eventos de actualización proporciona visibilidad del proceso de actualización e incluye información valiosa para la solución de problemas, si es necesario.

Registros de actualización del plano de control

Los eventos de actualización del clúster se pueden consultar mediante el siguiente filtro:

resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

Estos registros se documentan como formatos de registro estructurados. Puedes usar los siguientes campos para los detalles de los eventos de actualización:



Campo Descripción
protoPayload.metadata.operationType Hay dos tipos de eventos de actualización del clúster: UPGRADE_MASTER y UPDATE_CLUSTER.
UPGRADE_MASTER cambia la versión del plano de control de Kubernetes.
UPDATE_CLUSTER significa una actualización que no cambia la versión del plano de control de Kubernetes.
Ambos tipos de actualización de clústeres pueden causar la pérdida de disponibilidad del plano de control para los clústeres zonales. Para obtener más información, consulta Cómo funcionan las actualizaciones de clúster y grupo de nodos.
protoPayload.methodName En este campo, se muestra qué API activó la actualización del clúster.
google.container.v1.ClusterManager.UpdateCluster: Actualización manual del plano de control
google.container.internal.ClusterManagerInternal.UpdateClusterInternal: Actualización automática del plano de control
google.container.v1.ClusterManager.PatchCluster: Cambio de configuración del clúster.
protoPayload.metadata.previousMasterVersion Este campo solo se usa para el tipo de operación MASTER_UPGRADE y contiene la versión anterior del plano de control que se usó antes de la actualización.
protoPayload.metadata.currentMasterVersion Este campo solo se usa para el tipo de operación MASTER_UPGRADE y contiene el nuevo número de versión del plano de control que se usa después de la actualización.

Registros de actualización de grupos de nodos

Usa la siguiente consulta para ver los eventos de actualización de grupos de nodos: 

resource.type="gke_nodepool"
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"

Usa el siguiente campo para obtener detalles sobre el evento de actualización:

En el campo protoPayload.methodName, se muestra si la actualización se activó de forma manual o automática de la siguiente manera.

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?