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), y se incluyen enlaces a más información sobre las tareas y los 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 Autopilot, consulta Actualizaciones de clústeres de Autopilot.

Cómo funcionan las actualizaciones de clústeres y grupos de nodos

En esta sección se explica qué ocurre en el clúster durante las actualizaciones automáticas o manuales. En el caso de las actualizaciones automáticas, GKE las inicia. GKE monitoriza las actualizaciones automáticas y manuales en todos los clústeres de GKE e interviene si se detectan problemas.

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.

Si registras tu clúster en un canal de lanzamiento, los nodos ejecutarán la misma versión de GKE que el clúster, excepto durante un breve periodo (normalmente, unos días, en función de 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 ha actualizado manualmente. Consulta las notas de la versión para obtener más información.

Actualizaciones del clúster

En esta sección se explica qué ocurre cuando GKE actualiza automáticamente tu clúster o cuando inicias una actualización manual.

  • Los Zonal solo tienen un plano de control. Durante la actualización, tus cargas de trabajo seguirán ejecutándose, pero no podrás implementar cargas de trabajo nuevas, modificar las cargas de trabajo que ya tengas ni hacer 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 un orden indefinido. Durante la actualización, el clúster sigue teniendo una alta disponibilidad y cada réplica del plano de control solo no está disponible mientras se actualiza.

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

Actualizaciones de grupos de nodos

En esta sección se explica qué ocurre cuando GKE actualiza automáticamente tu grupo de nodos 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. También puedes actualizar manualmente uno o varios grupos de nodos en paralelo. De forma predeterminada, los nodos de un grupo de nodos se actualizan de uno en 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 de grupos de nodos de GKE, puedes elegir entre dos estrategias de actualización configurables y predefinidas, donde puedes ajustar el proceso de actualización en función de las necesidades del entorno de tu clúster. Para obtener más información sobre las estrategias de actualización de sobreaprovisionamiento y azul-verde, consulta Estrategias de actualización.

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

GKE respeta las ventanas y exclusiones de mantenimiento durante las actualizaciones automáticas cuando es posible. Las actualizaciones manuales omiten las ventanas de mantenimiento y las exclusiones que hayas configurado.

Cómo se actualizan los nodos

Durante la actualización de un 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 configures. Sin embargo, los pasos básicos siguen siendo los mismos. Para actualizar un nodo, GKE elimina los pods del nodo para que se pueda actualizar.

Cuando se actualiza un nodo, ocurre lo siguiente con los pods:

  1. El nodo se acordonará para que Kubernetes no programe nuevos pods en él.
  2. A continuación, se vacía el nodo, lo que significa que se eliminan los pods. En las actualizaciones de picos, GKE respeta los ajustes de PodDisruptionBudget y GracefulTerminationPeriod de los pods durante un máximo de una hora. Con las actualizaciones azul-verde, este tiempo se puede ampliar si configuras un tiempo de permanencia más largo.
  3. El plano de control vuelve a programar los pods gestionados 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 grupo de nodos puede tardar hasta unas horas, en función de la estrategia de actualización, el número de nodos y las configuraciones de sus cargas de trabajo.

Factores que influyen en la duración de la actualización de nodos

Entre las configuraciones que pueden hacer que una actualización de nodo tarde más en completarse, se incluyen las siguientes:

Estrategias de actualización de nodos

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

Sobreaprovisionamiento para actualizaciones

De forma predeterminada, se usa la estrategia de actualización de picos para las actualizaciones de grupos de nodos. Las actualizaciones de picos de uso utilizan un método progresivo para actualizar los nodos. Esta estrategia es la más adecuada para las aplicaciones que pueden gestionar cambios incrementales sin interrupciones. Con esta estrategia, los nodos se actualizan en una ventana de tiempo. Con estos ajustes, puedes cambiar el número de nodos que se pueden actualizar a la vez y el nivel de interrupción que pueden causar las actualizaciones. De esta forma, puedes encontrar el equilibrio óptimo entre velocidad e interrupción para las necesidades de tu entorno.

Actualizaciones azul-verde

La alternativa son las actualizaciones azul-verde, en las que se mantienen dos conjuntos de entornos (el original y el nuevo) al mismo tiempo, lo que hace que la reversión sea lo más sencilla posible. La implementación azul-verde requiere más recursos y es más adecuada para aplicaciones que son más sensibles a los cambios. Con esta estrategia, las cargas de trabajo se migran gradualmente del entorno "azul" original al nuevo entorno "verde" y se les da un tiempo de prueba para validarlas con la nueva configuración. Si es necesario, las cargas de trabajo se pueden restaurar rápidamente en el entorno "azul" actual.

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

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

Las actualizaciones con compensación crean nodos adicionales si maxSurge tiene un valor superior a 0, y las actualizaciones azul-verde duplican temporalmente el número de nodos de un grupo de nodos. Esto requiere recursos adicionales, que están sujetos a la cuota de Compute Engine, la disponibilidad de recursos y la capacidad de reservas. Si tu grupo de nodos no tiene suficientes recursos, las actualizaciones pueden tardar más o fallar.

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

Actualizar automáticamente

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

GKE se encarga de proteger el plano de control de tu clúster y actualiza tus clústeres cuando se selecciona una nueva versión de GKE para la actualización automática. La seguridad de la infraestructura es una prioridad para GKE, por lo que los planos de control se actualizan periódicamente y no se pueden inhabilitar. Sin embargo, puedes aplicar ventanas de mantenimiento y exclusiones para suspender temporalmente las actualizaciones de los planos de control y los nodos.

Como parte del modelo de responsabilidad compartida de GKE, debes proteger tus nodos, contenedores y pods. La actualización automática de nodos está habilitada de forma predeterminada. Aunque no se recomienda, puedes inhabilitar la actualización automática de nodos. Si inhabilitas las actualizaciones automáticas de nodos, no se bloqueará la actualización del plano de control de tu clúster. Si inhabilitas la actualización automática de nodos, eres responsable de asegurarte de que los nodos del clúster ejecuten una versión compatible con la versión del clúster y de que la versión cumpla la política de diferencia de versiones de GKE.

Para tener más control sobre cuándo se puede producir (o no se debe producir) una actualización automática, puedes configurar ventanas y exclusiones de mantenimiento.

Los grupos de nodos de un clúster no pueden tener una versión secundaria inferior a la versión del plano de control en más de dos versiones 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 instalados en cada nodo. Te recomendamos que mantengas los grupos de nodos actualizados a la versión del clúster.

Si registras tu clúster en un canal de lanzamiento, los nodos siempre ejecutarán la misma versión de GKE que el clúster, excepto durante un breve periodo (normalmente, unos días, en función de 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 de un grupo de nodos concreto. 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 periódicamente, pero no se selecciona una versión para la actualización automática de inmediato. Cuando una versión de GKE ha acumulado suficiente uso de clústeres para demostrar su estabilidad a lo largo del tiempo, GKE la selecciona como destino de actualización automática para los clústeres que ejecutan un subconjunto de versiones anteriores. 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.

Los nuevos objetivos de actualización automática 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 manualmente. En ocasiones, se selecciona una versión para la actualización automática del clúster y de los nodos en semanas diferentes.

Poco después de que una nueva versión secundaria esté disponible de forma general, la versión secundaria más antigua disponible suele dejar de estar admitida. Los clústeres que ejecuten versiones secundarias que dejen de estar admitidas se actualizarán automáticamente a la siguiente versión secundaria.

En una versión secundaria (como la 1.14.x), los clústeres se pueden actualizar automáticamente a una nueva versión de parche.

Los canales de lanzamiento te permiten controlar la versión de tu clúster y de tu grupo de nodos en función de la estabilidad de una versión, en lugar de gestionar la versión directamente.

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 para mantener la seguridad de la infraestructura. Las actualizaciones automáticas son mínimamente disruptivas, sobre todo en los clústeres regionales. Sin embargo, algunas cargas de trabajo pueden requerir un control más preciso. Puedes configurar ventanas y exclusiones de mantenimiento para gestionar cuándo se pueden y cuándo no se deben producir las actualizaciones automáticas.

Actualizar manualmente

Puedes solicitar actualizar manualmente tu clúster o sus grupos de nodos a una versión disponible y compatible en cualquier momento. Las actualizaciones manuales omiten las ventanas de mantenimiento y las exclusiones de mantenimiento configuradas.

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

  • En los clústeres zonales, el plano de control no está disponible mientras se actualiza. En la mayoría de los casos, las cargas de trabajo se ejecutan con normalidad, pero no se pueden modificar durante la actualización.

  • En los clústeres regionales, una réplica del plano de control no está disponible a la vez mientras se actualiza, pero el clúster sigue teniendo una alta disponibilidad durante la actualización.

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

Cómo responde GKE a un error 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 con Kubernetes. Por ejemplo, las actualizaciones automáticas fallan en las siguientes situaciones:

  • El ajuste maxSurge que has configurado supera tu cuota de recursos de Compute Engine.
  • Los nuevos nodos de aumento no se han registrado en el plano de control del clúster.
  • Los nodos han tardado demasiado en vaciarse o en eliminarse.

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 actualizan, GKE no revierte los nodos actualizados. En su lugar, GKE vuelve a intentar actualizar automáticamente el grupo de nodos hasta que todos los nodos se hayan actualizado correctamente.

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

Recibir notificaciones de actualización

GKE publica notificaciones sobre eventos relevantes para tu clúster, como actualizaciones de versiones y boletines de seguridad, en Pub/Sub, lo que te proporciona un canal para recibir información de GKE sobre tus clústeres.

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

Consultar los registros de actualización

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

Registros de actualización del plano de control

Los eventos de actualización de clústeres se pueden consultar con el siguiente filtro:

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

Estos registros se registran en formatos de registro estructurado. Puede usar los siguientes campos para obtener los detalles de los eventos de actualización:



Campo Descripción
protoPayload.metadata.operationType Hay dos tipos de eventos de actualización de clúster: UPGRADE_MASTER y UPDATE_CLUSTER.
UPGRADE_MASTER cambia la versión del plano de control de Kubernetes.
UPDATE_CLUSTER significa que la actualización no cambia la versión del plano de control de Kubernetes.
Ambos tipos de actualización de clústeres pueden provocar la pérdida de disponibilidad del plano de control en los clústeres zonales. Para obtener más información, consulta Cómo funcionan las actualizaciones de clústeres y grupos de nodos.
protoPayload.methodName En este campo se muestra qué API ha activado 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 en la 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 usaba 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 del grupo de nodos: 

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

Utilice el siguiente campo para obtener información sobre el evento de actualización:

protoPayload.methodName muestra si la actualización se ha activado manualmente o automáticamente, de la siguiente manera.

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