Exclusiones y períodos de mantenimiento

En esta página, se describen los períodos de mantenimiento y las exclusiones de mantenimiento, que son políticas que proporcionan control acerca de cuándo puede o no puede ocurrir cierto mantenimiento del clúster, como las actualizaciones automáticas, en tus clústeres de Google Kubernetes Engine (GKE). Por ejemplo, un negocio de venta minorista podría configurar el mantenimiento para que se realice solo durante las noches de los días laborables y evitar que el mantenimiento automático se lleve a cabo durante un evento de ventas importante de la industria.

Acerca de las políticas de mantenimiento de GKE

Las políticas de mantenimiento de GKE, que incluyen períodos de mantenimiento y exclusiones, te permiten controlar cuándo pueden ocurrir ciertos mantenimientos automáticos en tus clústeres, incluidas las actualizaciones de clústeres y otros cambios en la configuración del nodo o la topología de red del clúster.

Un período de mantenimiento es un período recurrente durante el cual se permite el mantenimiento automático de GKE.

Una exclusión de mantenimiento es un período no recurrente durante el cual se prohíbe el mantenimiento automático de GKE.

GKE realiza cambios automáticos que respetan las políticas de mantenimiento de tu clúster cuando hay un período de mantenimiento abierto y no hay una exclusión de mantenimiento activa. Para cada clúster, puedes configurar un período de mantenimiento recurrente y varias exclusiones de mantenimiento.

Otros tipos de mantenimiento no dependen de las políticas de mantenimiento de GKE, incluidas 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 Mantenimiento automático que no respeta las políticas de mantenimiento.

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

Antes de configurar las políticas de mantenimiento de GKE (períodos de mantenimiento y exclusiones), revisa las siguientes secciones para comprender cómo GKE y los servicios relacionados las respetan y no.

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

Con las políticas de mantenimiento de GKE, puedes controlar el tiempo de los siguientes tipos de eventos, que causan una interrupción temporal en el 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

Los períodos 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 comprender qué tipos de cambios no respetan los períodos de mantenimiento y las exclusiones.

Otras tareas de mantenimiento de Google Cloud

Los períodos de mantenimiento y las exclusiones de GKE no evitan el mantenimiento automático de los servicios subyacentes de Google Cloud, principalmente Compute Engine, o los servicios que instalan aplicaciones en el clúster, como Cloud Deploy.

Por ejemplo, los nodos de GKE son VMs de Compute Engine que GKE administra para tu clúster. A veces, las VMs de Compute Engine experimentan eventos de host, que pueden incluir eventos de mantenimiento o errores de host. El comportamiento de las VMs durante estos eventos lo determina la política de mantenimiento del host de la VM que, de forma predeterminada, para la mayoría de las VMs significa migrar en vivo. Por lo general, esto significa con poco o ningún tiempo de inactividad para los nodos y, para la mayoría de las cargas de trabajo, las políticas predeterminadas son suficientes. Para algunas familias de máquinas de VM, puedes supervisar y planificar un evento de mantenimiento del host y activar un evento de mantenimiento del host para programarlo con las políticas de mantenimiento de GKE.

Algunas VMs, incluidas las que tienen GPU y TPU, no pueden realizar la migración en vivo. Si usas estos aceleradores, aprende a manejar las interrupciones debido al mantenimiento de los nodos para GPU o TPU.

Te recomendamos que revises información acerca de eventos del host, políticas de mantenimiento del host, y confirma que tus cargas de trabajo estén preparadas para la interrupción, en especial si se ejecutan en nodos que no pueden realizar una migración en vivo.

Reparaciones automáticas y cambios de tamaño

GKE realiza reparaciones automatizadas en los planos de control. Esto incluye procesos como el escalamiento vertical del plano de control a un tamaño adecuado o el reinicio del plano de control para solucionar problemas. La mayoría de las reparaciones ignoran los períodos de mantenimiento y las exclusiones porque no realizarlas puede dar como resultado clústeres no funcionales.

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

Los nodos también tienen una funcionalidad de reparación automática, que puedes inhabilitar para los clústeres de Standard.

Parches de vulnerabilidades de seguridad críticas

Las exclusiones y los períodos de mantenimiento pueden causar retrasos en los parches de seguridad. Sin embargo, GKE se reserva el derecho de anular las políticas de mantenimiento por vulnerabilidades de seguridad críticas.

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

Algunos cambios en los nodos o la configuración de redes requieren que los nodos se vuelvan a crear para aplicar la configuración nueva, incluidos algunos de los siguientes cambios:

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

Períodos de mantenimiento

Los períodos de mantenimiento te permiten controlar cuándo pueden ocurrir las actualizaciones automáticas de los planos de control y nodos a fin de mitigar posibles interrupciones transitorias en tus cargas de trabajo. Los períodos de mantenimiento son útiles en distintos tipos de situaciones, por ejemplo:

  • Horas de menor demanda: para disminuir las posibilidades de que ocurran tiempos de inactividad, programa actualizaciones automáticas durante las horas de menor demanda, que es cuando el tráfico es reducido.
  • De guardia: asegúrate de que las actualizaciones se realizan durante el horario laboral para que alguien pueda supervisar y administrar cualquier problema inesperado.
  • Actualizaciones de varios clústeres: implementa actualizaciones en varios clústeres en diferentes regiones, una por una y en intervalos específicos.

Además de las actualizaciones automáticas, puede que Google necesite realizar otras tareas de mantenimiento y, si es posible, respetar el período de mantenimiento de un clúster.

Si la ejecución de las tareas excede el período de mantenimiento, GKE intenta pausarlas y, luego, intenta reanudarlas durante el siguiente período de mantenimiento.

GKE se reserva el derecho de lanzar actualizaciones de emergencia sin planificar fuera de los períodos de mantenimiento. Además, las actualizaciones obligatorias de software obsoleto o desactualizado pueden ocurrir de manera automática fuera de los períodos de mantenimiento.

Si deseas obtener información para configurar un período de mantenimiento en un clúster nuevo o existente, consulta Configura un período de mantenimiento.

Zonas horarias para períodos de mantenimiento

Cuando configuras y visualizas los períodos de mantenimiento, los horarios se muestran de manera diferente según la herramienta que uses:

Cuando configuras períodos de mantenimiento

Los horarios siempre se almacenan en UTC. Sin embargo, cuando configuras el período de mantenimiento, debes usar UTC o tu zona horaria local.

Cuando configuras períodos de mantenimiento con la marca --maintenance-window más genérica, no puedes especificar una zona horaria. Se usa UTC cuando se usa gcloud CLI o la API, y la consola de Google Cloud muestra los horarios en la zona horaria local.

Cuando usas marcas más detalladas, como --maintenance-window-start, puedes especificar la zona horaria como parte del valor. Si omites la zona horaria, se usa tu zona horaria local.

Cuando visualizas períodos de mantenimiento

Cuando visualizas información sobre tu clúster, puede que las marcas de tiempo de los períodos de mantenimiento se muestren en UTC o en tu zona horaria local, según la manera en la que veas la información:

  • Si usas la consola de Google Cloud para ver información sobre tu clúster, los horarios siempre se muestran en su zona horaria local.
  • Si usas laCLI de gcloud para ver información sobre tu clúster, los horarios siempre se muestran en UTC.

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

Exclusiones de mantenimiento

Con las exclusiones de mantenimiento, puedes evitar que el mantenimiento automático se lleve a cabo durante un período específico. Por ejemplo, muchas empresas minoristas tienen lineamientos comerciales que prohíben los cambios de infraestructura durante las festividades de fin de año. Otro ejemplo sería el siguiente: una empresa usa una API que está programada para darse de baja, y pueden usar las exclusiones de mantenimiento a fin de pausar las actualizaciones menores a fin de tener tiempo para migrar aplicaciones.

Para eventos de alto impacto conocidos, te recomendamos que hagas coincidir las restricciones de cambios internos con una exclusión de mantenimiento que comience una semana antes del evento y dure todo el evento.

Las exclusiones no son recurrentes. En su lugar, crea cada instancia de una exclusión periódica por separado.

Cuando las exclusiones y los períodos de mantenimiento se superponen, las exclusiones tienen prioridad.

Si deseas obtener más información para configurar las exclusiones de mantenimiento para un clúster nuevo o existente, consulta Configura una exclusión de mantenimiento.

Permiso del mantenimiento que se excluirá

No solo puedes especificar cuándo evitar el mantenimiento automático de tu clúster, sino que también puedes restringir el permiso de las actualizaciones automáticas que pueden ocurrir. Los permisos de exclusión de mantenimiento son útiles en distintos tipos de situaciones, por ejemplo:

  • No se aplican actualizaciones y se evita cualquier mantenimiento: deseas evitar cualquier cambio en tu clúster de forma temporal durante un período específico. Este es el permiso predeterminado.
  • No se aplican actualizaciones menores y se mantiene la versión secundaria actual de Kubernetes: deseas mantener de forma temporal la versión secundaria de un clúster para evitar cambios de API o validar los siguientes elementos. la próxima versión secundaria.
  • No se aplican actualizaciones menores o de nodos y se evita la interrupción del grupo de nodos: deseas evitar de forma temporal cualquier expulsión y reprogramación de las cargas de trabajo debido a las actualizaciones de nodos.

En la siguiente tabla, se muestra cómo cada uno de estos permisos restringe las actualizaciones menores o de parches para los nodos o planos de control del clúster.

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, los clústeres de Autopilot y Standard 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 la VM hacen que el plano de control no esté disponible temporalmente. Para los nodos, los reinicios de VM activan la reprogramación de Pods, lo que puede interrumpir de forma temporal las cargas de trabajo existentes. Puedes establecer la tolerancia a la interrupción de la carga de trabajo mediante un presupuesto de interrupción de Pods (PDB).

Alcance Plano de control Nodos
Actualización menor Actualización de parches Actualización menor Actualización de parches
Sin actualizaciones (predeterminado) No No No No
Sin actualizaciones secundarias No Sí No Sí
Sin actualizaciones secundarias ni de nodos No Sí No No

Si deseas ver las definiciones de las versiones secundarias y de parche, consulta el Esquema del control de versiones.

Exclusiones múltiples

Puedes configurar varias exclusiones en un clúster. Estas exclusiones pueden tener alcances diferentes y pueden tener intervalos de tiempo superpuestos. El caso práctico de temporada de fin de año es un ejemplo de exclusiones superpuestas, en las que se usan los permisos “Sin actualizaciones” y “Sin actualizaciones secundarias”. .

Cuando las exclusiones se superponen, si alguna exclusión activa (es decir, la hora actual se encuentra dentro del período de exclusión) bloquea una actualización, esta se pospondrá.

Si usas el caso práctico de temporada de fin de año, un clúster tendrá las siguientes exclusiones especificadas:

  • Sin actualizaciones menores: del 30 de septiembre al 15 de enero
  • Sin actualizaciones: del 19 de noviembre al 4 de diciembre
  • Sin actualizaciones: del 15 de diciembre al 5 de enero

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

  • Parche de actualización para grupo de nodos el 25 de noviembre (rechazado por la exclusión “Sin actualizaciones”)
  • Actualización menor al plano de control el 20 de diciembre (rechazada por la exclusión “Sin actualizaciones secundarias” y “Sin actualizaciones”)
  • Parche de actualización para el plano de control el 25 de diciembre (rechazado por la exclusión “Sin actualizaciones”)
  • Actualización menor al grupo de nodos el 1 de enero (rechazada por la exclusión "Sin actualizaciones secundarias" y "Sin actualizaciones")

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

  • Parche de actualización al plano de control el 10 de noviembre (permitido por la exclusión “Sin actualizaciones menores”)
  • Interrupción de la VM debido al mantenimiento de GKE el 10 de diciembre (permitido por la exclusión “Sin actualizaciones menores”)

Vencimiento de la exclusión

Cuando una exclusión expira (es decir, la hora actual supera la hora de finalización especificada para la exclusión), esa exclusión ya no evitará las actualizaciones de GKE. Otras exclusiones que aún son válidas (sin vencer) no permitirán las actualizaciones de GKE.

Cuando no existan exclusiones que impidan las actualizaciones de los clústeres, tu clúster se actualizará de forma gradual a la versión predeterminada actual en el canal de versiones del clúster (o a la configuración predeterminada estática para los clústeres sin canales de versiones).

Si tu clúster tiene varias versiones secundarias anteriores a la versión predeterminada actual después de la caducidad de la exclusión, GKE programará una actualización secundaria por mes (actualizar el plano de control y los nodos del clúster) hasta que tu clúster haya alcanzado la versión predeterminada del canal de versiones. Si deseas mostrar tu clúster a la versión predeterminada antes, puedes ejecutar actualizaciones manuales.

Limitaciones en la configuración de exclusiones de mantenimiento

Las exclusiones de mantenimiento tienen las siguientes limitaciones:

  • Puedes restringir el permiso de las actualizaciones automáticas en una exclusión de mantenimiento solo para los clústeres que estén inscritos en un canal de versiones. Para los clústeres no inscritos en un canal de versiones, solo puedes crear una exclusión de mantenimiento con el permiso predeterminado “Sin actualizaciones”.
  • Puedes agregar un máximo de tres exclusiones de mantenimiento que excluyan todas las actualizaciones (es decir, un permiso de “sin actualizaciones”). Estas exclusiones deben configurarse para permitir al menos 48 horas de disponibilidad de mantenimiento en un período de 32 días.
  • Puedes tener un máximo de 20 exclusiones de mantenimiento para cada clúster.
  • Si no especificas un permiso en tu exclusión, el permiso predeterminado será “Sin actualizaciones”.
  • Puedes establecer exclusiones de mantenimiento en diferentes períodos, según el permiso. Consulta la fila Maintenance exclusion length en la sección Configure a maintenance exclusion para obtener más detalles.
  • No puedes configurar una exclusión de mantenimiento para incluir o superar la fecha de fin de la compatibilidad de la versión secundaria correspondiente a la inscripción del canal de versiones del clúster. Consulta los siguientes ejemplos:
    • Un clúster ejecuta una versión secundaria en el canal estable en la que el programa de lanzamiento de GKE indica que la fecha del final de la asistencia estándar es el 5 de junio de 2025. Debes establecer la hora de finalización de la exclusión de mantenimiento para el 2025-06-05T00:00:00Z o antes.
    • Un clúster ejecuta una versión secundaria en el canal extendido en la que el programa de lanzamientos de GKE indica que la fecha de finalización de la asistencia extendida es el 5 de abril de 2026. Debes establecer la hora de finalización de la exclusión de mantenimiento en 2026-04-0500:00:00Z o antes. Si quieres cambiar el canal de versiones del clúster a otro, debes cambiar la hora de finalización de la exclusión de mantenimiento si supera el final de la asistencia estándar. Para obtener más información, consulta Cómo cambiar tu clúster desde el canal extendido.

Ejemplos de uso

Estos son algunos ejemplos de casos de uso que restringen el permiso de las actualizaciones que pueden ocurrir.

Ejemplo: Vendedor minorista que se prepara para la temporada de compras de fin de año

En este ejemplo, el negocio de venta minorista no quiere interrupciones durante los períodos de mayor volumen de ventas, que son los cuatro días que abarcan desde el Black Friday hasta el Cyber Monday y desde diciembre hasta el inicio del nuevo año. A fin de prepararse para la temporada de compras, el administrador del clúster configura las siguientes exclusiones:

  • No hay 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: Inmoviliza todas las actualizaciones entre el 19 de noviembre y el 4 de diciembre.
  • Sin actualizaciones: Inmoviliza todas las actualizaciones entre el 15 de diciembre y el 5 de enero.

Si no se aplican otros períodos de exclusión cuando vence la exclusión de mantenimiento, el clúster se actualiza a una nueva versión secundaria de GKE si hay una disponible entre el 30 de septiembre y el 6 de enero.

Ejemplo: Empresa que usa una API Beta en Kubernetes que se está quitando

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

  • Sin actualizaciones menores: Bloquea 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 heredada de la 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 y la reprogramación de Pods que ocurren durante una actualización del grupo de nodos. El administrador del clúster configura la siguiente exclusión:

  • No hay actualizaciones menores o de nodo: inmoviliza las actualizaciones de nodos durante tres meses. Cuando la empresa está lista para aceptar el tiempo de inactividad de la base de datos, activan una actualización manual de los nodos.

¿Qué sigue?