Ventanas de mantenimiento y exclusiones

En esta página se describen las ventanas de mantenimiento y las exclusiones de mantenimiento, que son políticas que permiten controlar cuándo se puede llevar a cabo el mantenimiento de los clústeres, como las actualizaciones automáticas, en los clústeres de Google Kubernetes Engine (GKE). Por ejemplo, un comercio puede limitar el mantenimiento para que solo se realice por las tardes entre semana y puede evitar que se lleve a cabo de forma automática durante un evento de ventas importante del sector.

.

Acerca de las políticas de mantenimiento de GKE

Las políticas de mantenimiento de GKE, que incluyen ventanas y exclusiones de mantenimiento, te permiten controlar cuándo se puede llevar a cabo el mantenimiento automático de tus clústeres, incluidas las actualizaciones de clústeres y otros cambios en la configuración de los nodos o en la topología de red del clúster.

Una ventana de mantenimiento es un periodo repetitivo durante el cual se permite el mantenimiento automático de GKE.

Una exclusión de mantenimiento es un periodo de tiempo durante el cual no está permitido ejecutar tareas de mantenimiento automático de GKE.

GKE hace cambios automáticos que respetan las políticas de mantenimiento de tu clúster cuando hay una ventana de mantenimiento abierta y no hay ninguna exclusión de mantenimiento activa. En cada clúster, puedes configurar una ventana de mantenimiento periódica y varias exclusiones de mantenimiento.

Otros tipos de mantenimiento no dependen de las políticas de mantenimiento de GKE, como las operaciones de reparación del plano de control y el mantenimiento de los servicios de los que depende GKE, como Compute Engine. Para obtener más información, consulta el artículo Mantenimiento automático que no respeta las políticas de mantenimiento.

Qué cambios respetan y cuáles no las políticas de mantenimiento de GKE

Antes de configurar las políticas de mantenimiento de GKE (ventanas de mantenimiento y exclusiones), consulta las siguientes secciones para saber cómo respetan y no respetan GKE y los servicios relacionados estas políticas.

Mantenimiento automático que respeta las políticas de mantenimiento de GKE

Con las políticas de mantenimiento de GKE, puedes controlar el momento de los siguientes tipos de eventos, que provocan interrupciones temporales en tu clúster:

Otros tipos de mantenimiento automático no dependen de las políticas de mantenimiento. Para obtener más información, consulta Mantenimiento automático que no respeta las políticas de mantenimiento.

Mantenimiento automático que no respeta las políticas de mantenimiento de GKE

Las ventanas de mantenimiento y las exclusiones de GKE no bloquean todos los tipos de mantenimiento automático. Antes de configurar las políticas de mantenimiento de tu clúster de GKE, asegúrate de que sabes qué tipos de cambios no respetan las ventanas ni las exclusiones de mantenimiento.

Otro Google Cloud mantenimiento

Las ventanas y exclusiones de mantenimiento de GKE no impiden el mantenimiento automático de los servicios subyacentes, principalmente Compute Engine, ni de los servicios que instalan aplicaciones en el clúster, como Cloud Deploy. Google Cloud

Por ejemplo, los nodos de GKE son máquinas virtuales de Compute Engine que GKE gestiona en tu clúster. Las VMs de Compute Engine a veces experimentan eventos de host, que pueden incluir eventos de mantenimiento o errores de host. El comportamiento de las VMs durante estos eventos se determina mediante la política de mantenimiento del host de la VM, que, de forma predeterminada en la mayoría de las VMs, significa migración en directo. Esto suele significar que los nodos tienen poco o ningún tiempo de inactividad y, en la mayoría de las cargas de trabajo, las políticas predeterminadas son suficientes. En algunas familias de máquinas virtuales, puedes monitorizar y planificar un evento de mantenimiento del host y activar un evento de mantenimiento del host para que coincida con tus políticas de mantenimiento de GKE.

Algunas VMs, incluidas las que tienen GPUs y TPUs, no pueden realizar migraciones en directo. Si usas estos aceleradores, consulta cómo gestionar las interrupciones debidas al mantenimiento de los nodos en el caso de las GPUs o las TPUs.

Te recomendamos que consultes la información sobre los eventos del host y las políticas de mantenimiento del host, así como que confirmes que tus cargas de trabajo están preparadas para las interrupciones, sobre todo si se ejecutan en nodos que no pueden realizar una migración en directo.

Reparaciones y cambios de tamaño automatizados

GKE realiza reparaciones automatizadas en los planos de control. Esto incluye procesos como aumentar la escala del plano de control a un tamaño adecuado o reiniciar el plano de control para resolver problemas. En la mayoría de las reparaciones se ignoran las ventanas de mantenimiento y las exclusiones, ya que, si no se realizan, los clústeres pueden dejar de funcionar.

No puedes inhabilitar las reparaciones del plano de control. Sin embargo, la mayoría de los tipos de clústeres, incluidos los clústeres Autopilot y los clústeres regionales estándar, tienen varias réplicas de los planos de control, lo que permite que el servidor de la API de Kubernetes tenga una alta disponibilidad incluso durante los eventos de mantenimiento. Los clústeres zonales estándar, que solo tienen un plano de control, no se pueden modificar durante los cambios de configuración del plano de control ni durante el mantenimiento del clúster. Esto incluye la implementación de cargas de trabajo.

Los nodos también tienen una función de reparación automática, que puedes inhabilitar en los clústeres estándar.

Aplicación de parches para vulnerabilidades de seguridad críticas

Las ventanas de mantenimiento y las exclusiones pueden provocar que los parches de seguridad se retrasen. Sin embargo, GKE se reserva el derecho de anular las políticas de mantenimiento en caso de vulnerabilidades de seguridad críticas.

Mantenimiento de la base de datos de estado del clúster basada en Spanner

Algunos clústeres de GKE usan una base de datos de clave-valor de Spanner para almacenar el estado de los recursos de la API de Kubernetes. Las operaciones de mantenimiento de esta base de datos ignoran las ventanas de mantenimiento y las exclusiones activas. Sin embargo, la base de datos de estado del clúster basada en Spanner se replica y sigue estando disponible durante los eventos de mantenimiento.

Cambios manuales que respetan las políticas de mantenimiento de GKE

Para aplicar la nueva configuración, es necesario volver a crear los nodos o la configuración de red. Esto incluye algunos de los siguientes cambios:

Estos cambios respetan las políticas de mantenimiento de GKE, lo que significa que GKE espera a que haya una ventana de mantenimiento abierta y a que no haya ninguna exclusión de mantenimiento activa que impida el mantenimiento de los nodos. Para aplicar los cambios a los nodos manualmente, usa la CLI de Google Cloud para llamar al comando gcloud container clusters upgrade y pasar la marca --cluster-version con la misma versión de GKE que ya esté ejecutando el grupo de nodos.

Cambios manuales que no respetan las políticas de mantenimiento de GKE

Algunos cambios manuales recrean los nodos inmediatamente mediante una estrategia de actualización de nodos sin respetar las políticas de mantenimiento. Para obtener más información, consulta Cambios manuales que recrean los nodos mediante una estrategia de actualización de nodos sin respetar las políticas de mantenimiento.

Ventanas de mantenimiento

Las ventanas de mantenimiento te permiten controlar cuándo se pueden llevar a cabo las actualizaciones automáticas de los planos de control y los nodos para mitigar las posibles interrupciones transitorias de tus cargas de trabajo. Las ventanas de mantenimiento son útiles en los siguientes casos, entre otros:

  • Horas de menor actividad: quieres minimizar las probabilidades de que haya tiempo de inactividad programando actualizaciones automáticas durante las horas de menor actividad, cuando el tráfico es menor.
  • En horario de atención: quieres asegurarte de que las actualizaciones se realicen durante el horario de trabajo para que alguien pueda monitorizarlas y gestionar cualquier problema imprevisto.
  • Actualizaciones de varios clústeres: quieres implementar actualizaciones en varios clústeres de diferentes regiones de uno en uno a intervalos especificados.

Además de las actualizaciones automáticas, es posible que Google tenga que realizar otras tareas de mantenimiento de vez en cuando y respeta la ventana de mantenimiento de un clúster si es posible.

Si las tareas se ejecutan más allá de la ventana de mantenimiento, GKE intenta pausarlas y reanudarlas durante la siguiente ventana de mantenimiento.

GKE se reserva el derecho de implementar actualizaciones de emergencia no planificadas fuera de las ventanas de mantenimiento. Además, las actualizaciones obligatorias de software obsoleto o antiguo pueden producirse automáticamente fuera de las ventanas de mantenimiento.

Para saber cómo configurar una ventana de mantenimiento en un clúster nuevo o ya creado, consulta Configurar una ventana de mantenimiento.

Zonas horarias de las ventanas de mantenimiento

Al configurar y ver las ventanas de mantenimiento, las horas se muestran de forma diferente en función de la herramienta que estés usando:

Al configurar ventanas de mantenimiento

Las horas siempre se almacenan en UTC. Sin embargo, al configurar la ventana de mantenimiento, puedes usar la hora UTC o tu zona horaria local.

Cuando configuras ventanas de mantenimiento con la marca más genérica --maintenance-window, no puedes especificar una zona horaria. La zona horaria UTC se usa cuando se utiliza la CLI de gcloud o la API, y la Google Cloud consola muestra las horas con la zona horaria local.

Si usa marcas más específicas, como --maintenance-window-start, puede especificar la zona horaria como parte del valor. Si omites la zona horaria, se usará la zona horaria local.

Al ver las ventanas de mantenimiento

Cuando consultes información sobre tu clúster, las marcas de tiempo de las ventanas de mantenimiento se pueden mostrar en UTC o en tu zona horaria local, en función de cómo consultes la información:

  • Cuando se usa la Google Cloud consola para ver información sobre el clúster, las horas siempre se muestran en la zona horaria local.
  • Cuando se usa la CLI gcloud para ver información sobre el clúster, las horas siempre se muestran en UTC.

En ambos casos, la RRULE siempre está en UTC. Esto significa que, si especifica, por ejemplo, los días de la semana, esos días están en UTC.

Exclusiones de la ventana de mantenimiento

Con las exclusiones de mantenimiento, puedes evitar que se realicen tareas de mantenimiento automático durante un periodo específico. Por ejemplo, muchas empresas del sector de comercio minorista tienen directrices que prohíben los cambios en la infraestructura durante las vacaciones de fin de año. Por ejemplo, si una empresa usa una API que se va a retirar, puede usar exclusiones de mantenimiento para pausar las actualizaciones menores y tener tiempo para migrar las aplicaciones.

En el caso de los eventos de gran impacto conocidos, te recomendamos que hagas coincidir las restricciones de los cambios internos con una exclusión por mantenimiento que empiece una semana antes del evento y dure todo el tiempo que dure el evento.

Las exclusiones no tienen periodicidad. En su lugar, cree cada instancia de una exclusión periódica por separado.

Cuando se solapan las exclusiones y las ventanas de mantenimiento, las exclusiones tienen prioridad.

Para saber cómo configurar exclusiones de mantenimiento en un clúster nuevo o ya creado, consulta Configurar una exclusión de mantenimiento.

Ámbito del mantenimiento que se va a excluir

No solo puedes especificar cuándo quieres evitar el mantenimiento automático de tu clúster, sino que también puedes restringir el ámbito de las actualizaciones automáticas que puedan producirse. Los ámbitos de exclusión de mantenimiento son útiles en los siguientes tipos de situaciones, entre otros:

  • Sin actualizaciones:evita cualquier mantenimiento. Quieres evitar temporalmente cualquier cambio en tu clúster durante un periodo de tiempo específico. Este es el ámbito predeterminado.
  • No se realicen actualizaciones secundarias: mantén la versión secundaria actual de Kubernetes: quieres mantener temporalmente la versión secundaria de un clúster para evitar cambios en la API o validar la siguiente versión secundaria.
  • Sin actualizaciones de versiones secundarias ni de nodos: evita interrupciones en los nodos. Si quieres evitar temporalmente que se expulsen y reprogramen tus cargas de trabajo debido a las actualizaciones de nodos.

En la siguiente tabla se indica cómo restringe cada uno de estos ámbitos las actualizaciones menores o de parche de los planos de control o los nodos de los clústeres.

Cuando GKE actualiza un clúster, se reinician las VMs del plano de control y del nodo. En el caso de los planos de control, Autopilot y los clústeres estándar regionales mantienen la disponibilidad del servidor de la API de Kubernetes. En los clústeres zonales, que tienen un solo nodo de plano de control, los reinicios de las VMs hacen que el plano de control no esté disponible temporalmente. En el caso de los nodos, los reinicios de las VMs activan la reprogramación de los pods, lo que puede interrumpir temporalmente las cargas de trabajo. Puedes definir tu tolerancia a las interrupciones de las cargas de trabajo mediante un presupuesto de interrupción de pods (PDB).

Ámbito Plano de control Nodos
Actualización secundaria automática Actualización automática de parches Actualización secundaria automática Actualización automática de parches
Sin cambios a clase superior (opción predeterminada) No permitido No permitido No permitido No permitido
No hay actualizaciones secundarias No permitido Permitido No permitido Permitido
No hay actualizaciones de versiones secundarias ni de nodos No permitido Permitido No permitido No permitido

Para ver las definiciones de las versiones secundarias y de los parches, consulta el artículo Esquema de versiones.

Varias exclusiones

Puedes definir varias exclusiones en un clúster. Estas exclusiones pueden tener ámbitos diferentes y periodos que se solapen. El caso práctico de la temporada festiva de fin de año es un ejemplo de exclusiones superpuestas, en el que se utilizan los ámbitos "Sin actualizaciones" y "Sin actualizaciones menores".

Si se solapan exclusiones, y alguna de ellas está activa (es decir, la hora actual está dentro del periodo de la exclusión) e impide una actualización, esta se pospondrá.

En el caso práctico de la temporada festiva de fin de año, un clúster tiene las siguientes exclusiones especificadas:

  • No hay actualizaciones menores: del 30 de septiembre al 15 de enero
  • Sin cambios a clase superior: del 19 de noviembre al 4 de diciembre
  • Sin cambios a clase superior: del 15 de diciembre al 5 de enero

Como resultado de estas exclusiones superpuestas, las siguientes actualizaciones se bloquearán en el clúster:

  • Actualización de parche del grupo de nodos el 25 de noviembre (rechazada por la exclusión "Sin actualizaciones")
  • Actualización menor del plano de control el 20 de diciembre (rechazada por las exclusiones "No minor upgrades" y "No upgrades")
  • Actualización de parche del plano de control el 25 de diciembre (rechazada por la exclusión "Sin actualizaciones")
  • Actualización secundaria del grupo de nodos el 1 de enero (rechazada por las exclusiones "No minor upgrades" [Sin actualizaciones secundarias] y "No upgrades" [Sin actualizaciones])

Se permitiría el siguiente mantenimiento en el clúster:

  • Actualización de parche del plano de control el 10 de noviembre (permitida por la exclusión "Sin actualizaciones secundarias")
  • Interrupción de la VM debido al mantenimiento de GKE el 10 de diciembre (permitida por la exclusión "Sin actualizaciones menores")

Caducidad de la exclusión

Cuando caduca una exclusión (es decir, cuando la hora actual supera la hora de finalización especificada para la exclusión), esa exclusión ya no impedirá las actualizaciones de GKE. Otras exclusiones que sigan siendo válidas (es decir, que no hayan caducado) seguirán impidiendo que se realicen actualizaciones de GKE.

Cuando no quedan exclusiones ni otros factores que impidan las actualizaciones del clúster, GKE actualiza gradualmente el clúster a los destinos de actualización automática aptos.

Si tu clúster se ha perdido varias actualizaciones de versiones secundarias debido a la exclusión, GKE programa aproximadamente una actualización de versión secundaria al mes, actualizando tanto el plano de control del clúster como los nodos, para asegurarse de que el clúster ejecute una versión compatible. Siempre puedes realizar actualizaciones manuales para que tu clúster alcance una versión secundaria específica antes.

Limitaciones al configurar exclusiones de mantenimiento

Las exclusiones de la ventana de mantenimiento tienen las siguientes limitaciones:

  • Solo puedes restringir el ámbito de las actualizaciones automáticas en una exclusión de mantenimiento para los clústeres registrados en un canal de lanzamiento. En el caso de los clústeres que no estén registrados en un canal de lanzamiento, solo puedes crear una exclusión de mantenimiento con el ámbito predeterminado "Sin actualizaciones".
  • Puedes añadir un máximo de tres exclusiones de mantenimiento que excluyan todas las actualizaciones (es decir, un ámbito de "sin actualizaciones"). Estas exclusiones deben configurarse para permitir al menos 48 horas de disponibilidad de mantenimiento en un periodo de 32 días.
  • Puedes tener un máximo de 20 exclusiones de mantenimiento por clúster.
  • Si no especifica un ámbito en su exclusión, el ámbito predeterminado será "no upgrades".
  • Puedes definir exclusiones de mantenimiento de diferentes duraciones, según el ámbito. Consulta la fila Duración de la exclusión por mantenimiento de la sección Configurar una exclusión por mantenimiento para obtener más información.
  • No puedes configurar una exclusión de mantenimiento que incluya o supere la fecha de finalización del soporte de la versión secundaria correspondiente al canal de lanzamiento del clúster. Consulta los siguientes ejemplos:
    • Un clúster ejecuta una versión secundaria en el canal Estable, donde el calendario de lanzamientos de GKE indica que la fecha de finalización del periodo de asistencia estándar es el 5 de junio del 2025. Debes definir la hora de finalización de la exclusión de mantenimiento como 2025-06-05T00:00:00Z o una fecha anterior.
    • Un clúster ejecuta una versión secundaria del canal ampliado en la que el calendario de lanzamientos de GKE indica que la fecha de finalización del periodo de asistencia ampliado es el 5 de abril del 2026. Debe definir la hora de finalización de la exclusión por mantenimiento como 2026-04-0500:00:00Z o anterior. Si quieres cambiar el canal de lanzamiento del clúster a otro canal, debes cambiar la hora de finalización de la exclusión de mantenimiento si supera la finalización del servicio de asistencia estándar. Para obtener más información, consulta Cambiar el clúster del canal Extended.

Las exclusiones de la ventana de mantenimiento no afectan a las actualizaciones manuales ni a las versiones de los nodos nuevos

Las exclusiones de mantenimiento impiden que los planos de control y los nodos se actualicen automáticamente, en función del ámbito de la exclusión de mantenimiento. Sin embargo, las exclusiones de mantenimiento no impiden que se realicen los siguientes cambios:

  • Actualizar manualmente el plano de control o los nodos del clúster.
  • Crear un grupo de nodos Estándar con una versión posterior a los grupos de nodos Estándar donde una exclusión de mantenimiento impide las actualizaciones automáticas.
  • Si el aprovisionamiento automático de nodos crea los siguientes recursos con una versión posterior a la de los nodos donde una exclusión de mantenimiento impide las actualizaciones automáticas:
    • Nuevos grupos de nodos estándar.
    • Nuevos nodos en un clúster de Autopilot.

Supongamos que has creado una exclusión de mantenimiento para tu clúster con un ámbito en el que GKE actualiza automáticamente el plano de control, pero no los nodos, a versiones posteriores. En este caso, GKE puede crear grupos de nodos o nodos nuevos que se creen mediante el aprovisionamiento automático y que ejecuten la versión de parche más reciente del plano de control.

Los nodos de clúster solo pueden ejecutar la misma versión de GKE o una anterior a la del plano de control. Las exclusiones de mantenimiento impiden que se actualicen automáticamente los nodos. Si el plano de control tiene una versión más reciente que los nodos, los nodos recién creados o actualizados manualmente podrían ejecutar una versión de GKE más reciente que los nodos que no pueden actualizarse automáticamente debido a las exclusiones de mantenimiento.

Ejemplos de uso

A continuación, se muestran algunos ejemplos de casos prácticos para restringir el alcance de las actualizaciones que se pueden producir.

Ejemplo: un comercio se prepara para la temporada festiva de final de año

En este ejemplo, la empresa minorista no quiere que haya interrupciones durante los periodos de ventas de mayor volumen, que son los cuatro días que abarcan desde el Black Friday hasta el Cyber Monday, así como el mes de diciembre hasta el inicio del nuevo año. Para prepararse para la temporada de compras, el administrador del clúster configura las siguientes exclusiones:

  • Sin actualizaciones menores: permite solo las actualizaciones de parches en el plano de control y los nodos entre el 30 de septiembre y el 15 de enero.
  • Sin actualizaciones: congela todas las actualizaciones entre el 19 de noviembre y el 4 de diciembre.
  • Sin cambios a clase superior: se congelan todos los cambios a clase superior entre el 15 de diciembre y el 5 de enero.

Si no se aplica ninguna otra ventana de exclusión cuando caduque la exclusión de mantenimiento, el clúster se actualizará a una nueva versión secundaria de GKE si se ha publicado alguna entre el 30 de septiembre y el 6 de enero.

Ejemplo: una empresa usa una API beta en Kubernetes que se va a retirar

En este ejemplo, una empresa usa la API CustomResourceDefinition apiextensions.k8s.io/v1beta1, que se eliminará en la versión 1.22. Mientras la empresa usa versiones anteriores a la 1.22, el administrador del clúster configura la siguiente exclusión:

  • Sin actualizaciones menores: congela las actualizaciones menores durante tres meses mientras migras las aplicaciones de los clientes de apiextensions.k8s.io/v1beta1 a apiextensions.k8s.io/v1.

Ejemplo: la base de datos antigua de una empresa no es resistente a las actualizaciones de grupos de nodos

En este ejemplo, una empresa ejecuta una base de datos que no responde bien a las expulsiones de pods y a la reprogramación que se produce durante una actualización de un grupo de nodos. El administrador del clúster configura la siguiente exclusión:

  • Sin actualizaciones de versiones secundarias ni de nodos: congela las actualizaciones de nodos durante tres meses. Cuando la empresa esté lista para aceptar el tiempo de inactividad de la base de datos, activará una actualización manual de los nodos.

Siguientes pasos