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.

Otro Google Cloud mantenimiento

Los períodos de mantenimiento y las exclusiones de GKE no evitan el mantenimiento automático de los servicios Google Cloud subyacentes, 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.

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 pares clave-valor de Spanner para almacenar el estado de los recursos de la API de Kubernetes. Las operaciones de mantenimiento en esta base de datos ignoran cualquier exclusión y período de mantenimiento activos. Sin embargo, la base de datos de estado del clúster basada en Spanner se replica y permanece disponible durante los eventos de mantenimiento.

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.

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

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

Períodos de mantenimiento

Los períodos de mantenimiento te permiten controlar cuándo puede ocurrir el mantenimiento automático aplicable, incluidas las actualizaciones automáticas de los planos de control y los nodos, para 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.

Para casos de uso avanzados, también puedes usar presupuestos de interrupción del clúster para personalizar el intervalo de tiempo mínimo entre tipos específicos de actualizaciones del clúster, incluidas las actualizaciones de parches o secundarias.

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 la 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 tu zona horaria local.
  • Si usas la gcloud CLI 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 se lleve a cabo el mantenimiento automático aplicable 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.

Tipos de exclusiones de mantenimiento

Puedes establecer una exclusión de mantenimiento para todo el clúster o, si necesitas mayor granularidad, puedes establecer una exclusión de mantenimiento solo para un grupo de nodos individual. Revisa las siguientes secciones para comprender cómo funcionan los diferentes tipos de exclusiones de mantenimiento.

Exclusiones de mantenimiento del clúster

A nivel del clúster, puedes especificar cuándo evitar el mantenimiento automático en tu clúster y el alcance de las actualizaciones automáticas que pueden ocurrir. Consulta los siguientes permisos de exclusión de mantenimiento del clúster y ejemplos de situaciones pertinentes:

  • 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 la versión secundaria de un clúster para, por ejemplo, evitar cambios en la API o validar 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 cualquier expulsión y reprogramación de las cargas de trabajo debido a las actualizaciones de nodos.

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

Alcance Plano de control Nodos Longitud máxima de la exclusión
Actualización secundaria automática Actualización automática de parches Actualización secundaria automática Actualización automática de parches
Sin actualizaciones (predeterminado) No permitido No permitido No permitido No permitido No puede superar los 90 días.
Sin actualizaciones secundarias No permitido Permitido No permitido Permitido

Puedes configurar la exclusión de mantenimiento de una de las siguientes maneras:

  • Hora de finalización fija: Establece la hora de finalización hasta el final de la asistencia para la versión secundaria del clúster y el canal de versiones correspondiente. En el caso de los clústeres inscritos en los canales rápidos, regulares o estables, esta es la fecha del fin de la asistencia estándar y, en el caso del canal extendido, la fecha del fin de la asistencia extendida.
  • Realiza un seguimiento del final de la asistencia: Configura la hora de finalización para realizar un seguimiento del final de la asistencia de la versión secundaria de tu clúster. Si no actualizas manualmente el clúster a la siguiente versión secundaria antes del final de la compatibilidad, GKE realizará las actualizaciones automáticas necesarias al final de la compatibilidad y, luego, reactivará la exclusión de mantenimiento con la hora de finalización que haga un seguimiento del final de la compatibilidad de la nueva versión secundaria. Para obtener más información, consulta Cómo una exclusión de mantenimiento hace un seguimiento del final de la asistencia.
Sin actualizaciones secundarias ni de nodos No permitido Permitido No permitido No permitido

Cuando GKE actualiza un clúster, se reinician las VMs del plano de control y los nodos. 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).

Exclusiones de mantenimiento del grupo de nodos

Si deseas evitar las actualizaciones automáticas de nodos del clúster para algunos, pero no todos, los grupos de nodos de tu clúster estándar, puedes usar una exclusión de mantenimiento del grupo de nodos. Por ejemplo, si tienes algunos grupos de nodos en tu clúster en los que deseas que GKE actualice los nodos automáticamente, pero otros grupos de nodos en los que deseas administrar las actualizaciones de los grupos de nodos, puedes establecer exclusiones de grupos de nodos solo para los grupos de nodos que requieren más control manual.

Cuando habilitas este tipo de exclusión de mantenimiento, GKE solo actualiza automáticamente tu clúster según sea necesario cuando la versión secundaria del grupo de nodos llega al final de la asistencia. Para obtener más información, consulta Actualizaciones automáticas al final de la compatibilidad.

En la siguiente tabla, se explica cómo esta exclusión de mantenimiento evita las actualizaciones automáticas del grupo de nodos:

Tipo de exclusión de mantenimiento Nodos Longitud máxima de la exclusión
Actualización secundaria automática Actualización automática de parches
Grupo de nodos No permitido No permitido La hora de finalización hace un seguimiento del final de la asistencia para la versión secundaria de tu clúster. Si no actualizas manualmente el clúster a la siguiente versión secundaria antes del final de la compatibilidad, GKE realizará las actualizaciones automáticas necesarias al final de la compatibilidad y, luego, reactivará la exclusión de mantenimiento con la hora de finalización que haga un seguimiento del final de la compatibilidad de la nueva versión secundaria. Para obtener más información, consulta Cómo una exclusión de mantenimiento hace un seguimiento del final de la asistencia.

Vencimiento y activación de la exclusión

Una exclusión de mantenimiento del clúster se activa de inmediato o en la fecha y hora que especifiques cuando configures la exclusión.

Una exclusión de mantenimiento vence o se inactiva en el siguiente momento:

  • Hora de finalización fija: Cuando pasa la hora de finalización fija que especificaste para la exclusión

  • Realiza un seguimiento del final de la compatibilidad: La exclusión de mantenimiento se inactiva temporalmente al comienzo de la fecha del final de la compatibilidad si tu clúster aún no se actualizó a la siguiente versión secundaria y usas una exclusión de mantenimiento de alguna de las siguientes maneras:

    • Configura una exclusión de mantenimiento del clúster para la hora de finalización y haz un seguimiento de la fecha de finalización de la compatibilidad de la versión secundaria de tu clúster.
    • Establece una exclusión de mantenimiento del grupo de nodos.

    GKE reactiva la exclusión de mantenimiento después de que ocurre una de las siguientes situaciones:

Cuando una exclusión de mantenimiento vence (es decir, la hora actual supera la hora de finalización especificada para la exclusión) o se inactiva temporalmente, esa exclusión ya no impide las actualizaciones de GKE. Otras exclusiones que aún son válidas no permitirán las actualizaciones de GKE.

Cuando no existan exclusiones ni otros factores que impidan las actualizaciones de los clústeres, GKE actualizará tu clúster de forma gradual a los destinos de actualización automática aptos.

Si tu clúster no recibió varias actualizaciones de versiones secundarias debido a la exclusión, GKE programará aproximadamente una actualización de versión secundaria por mes, en la que se actualizarán el plano de control y los nodos del clúster, para garantizar que tu clúster ejecute una versión compatible. Siempre puedes ejecutar actualizaciones manuales para que tu clúster llegue a una versión secundaria específica antes.

Cómo una exclusión de mantenimiento hace un seguimiento del final de la asistencia

Puedes configurar exclusiones de mantenimiento del clúster con el permiso “Sin actualizaciones secundarias” o “Sin actualizaciones secundarias ni de nodos” para hacer un seguimiento del final de la compatibilidad con la versión secundaria de tu clúster, en lugar de establecer manualmente una fecha como hora de finalización. Las exclusiones de mantenimiento del grupo de nodos también hacen un seguimiento del final de la asistencia.

Si configuras uno de estos tipos de exclusiones de mantenimiento para hacer un seguimiento de la fecha de finalización del soporte, en las siguientes situaciones, GKE actualizará la hora de finalización de la exclusión de mantenimiento para reflejar la nueva fecha de finalización del soporte:

  • Tú o GKE actualizan el clúster a una nueva versión secundaria.
  • Cambias la inscripción de tu clúster al canal extendido o desde él.
  • GKE actualiza la fecha de finalización de la asistencia de la versión secundaria de tu clúster.

Con estos tipos de exclusiones de mantenimiento, si no actualizaste manualmente tu clúster a la siguiente versión secundaria, GKE realiza las actualizaciones automáticas necesarias al final de la asistencia y, luego, reactiva la exclusión de mantenimiento con la hora de finalización que hace un seguimiento del final de la asistencia de la nueva versión secundaria.

Para obtener más información sobre el final de la asistencia, consulta el ciclo de vida de la versión secundaria de GKE. Para ver la fecha del final de la compatibilidad de la versión secundaria de tu clúster, consulta Cómo saber cuándo la versión secundaria de tu clúster alcanza el final de la compatibilidad.

Prevención temporal y de emergencia de las actualizaciones automáticas al final del período de asistencia

Como medida temporal, que se debe usar solo en emergencias en las que no haya otras opciones disponibles, puedes retrasar las actualizaciones automáticas al final del período de asistencia hasta 90 días después de la fecha de finalización de la asistencia configurando una exclusión de mantenimiento con el alcance predeterminado de "Sin actualizaciones". No recomendamos esta práctica debido a los riesgos asociados con la ejecución de una versión no compatible. Una vez que vence la exclusión de mantenimiento, GKE actualiza el clúster.

Operar un clúster que usa una versión de GKE no compatible conlleva un riesgo significativo de seguridad, confiabilidad y compatibilidad, ya que GKE no proporciona parches de seguridad ni correcciones de errores para las versiones que ya no tienen asistencia. GKE no puede comprometerse a proporcionar parches o actualizaciones para las versiones que se encuentran al final del período de asistencia.

Para obtener más información, consulta Actualizaciones automáticas al final de la compatibilidad.

Limitaciones en la configuración de exclusiones de mantenimiento

Las exclusiones de mantenimiento del clúster 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 del clúster para cada clúster.
  • Si no especificas un permiso en tu exclusión, el permiso predeterminado será “Sin actualizaciones”.

  • No puedes configurar una exclusión de mantenimiento para incluir o superar la fecha de finalización de la compatibilidad de la versión secundaria correspondiente a la inscripción del canal de versiones del clúster, excepto como una medida temporal de emergencia con el permiso “Sin actualizaciones”. Para establecer una hora de finalización fija cerca del fin de la asistencia, 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 en 2025-06-05T00:00:00Z o antes.
    • Un clúster ejecuta una versión secundaria en el canal extendido en el 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 canal, 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 Cambia tu clúster desde el canal extendido.

    De manera opcional, la exclusión puede hacer un seguimiento de la fecha de finalización de la asistencia y se inactiva temporalmente al inicio de la fecha de finalización de la asistencia hasta que el clúster se actualice a la siguiente versión secundaria.

Las exclusiones de mantenimiento del grupo de nodos tienen las siguientes limitaciones:

  • El clúster debe estar inscrito en un canal de versiones.
  • Solo puedes establecer una exclusión de mantenimiento del grupo de nodos por grupo de nodos.
  • No puedes establecer una exclusión de mantenimiento del grupo de nodos para que comience en una fecha y hora futuras. La exclusión de mantenimiento comienza de inmediato cuando la habilitas.
  • No puedes usar exclusiones de mantenimiento de grupos de nodos con clústeres de Autopilot, ya que GKE administra los nodos de los clústeres de Autopilot.
  • La exclusión de mantenimiento del grupo de nodos solo evita las actualizaciones de nodos (actualizaciones de versión) y no evita otros tipos de actualizaciones de nodos.

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

Las exclusiones de mantenimiento impiden que los planos de control y los nodos existentes se actualicen automáticamente, según el alcance de la exclusión de mantenimiento. Sin embargo, las exclusiones de mantenimiento no impiden los siguientes cambios:

  • Actualizar manualmente el plano de control o los nodos del clúster
  • Crear un grupo de nodos de Standard nuevo con una versión posterior a la de los grupos de nodos de Standard existentes en los que una exclusión de mantenimiento impide las actualizaciones automáticas
  • El aprovisionamiento automático de nodos crea los siguientes recursos con una versión posterior a la de los nodos existentes en los que una exclusión de mantenimiento impide las actualizaciones automáticas:
    • Nuevos grupos de nodos de Standard
    • Nodos nuevos en un clúster de Autopilot

Supongamos que creaste una exclusión de mantenimiento para tu clúster con un alcance en el que GKE actualiza automáticamente el plano de control, pero no los nodos, a versiones de parche posteriores. En esta situación, GKE podría crear grupos de nodos nuevos o nodos creados a través del aprovisionamiento automático que ejecuten la versión de parche posterior del plano de control.

Los nodos del clúster solo pueden ejecutar versiones de GKE iguales o anteriores a la del plano de control. Las exclusiones de mantenimiento impiden las actualizaciones automáticas de los nodos existentes. Si el plano de control tiene una versión más reciente que los nodos existentes, los nodos creados recientemente o actualizados de forma manual podrían ejecutar una versión más reciente de GKE que los nodos que tienen restringidas las actualizaciones automáticas por exclusiones de mantenimiento.

Exclusiones múltiples

Puedes establecer varias exclusiones para un clúster, incluidas las exclusiones de grupos de nodos. Estas exclusiones pueden tener diferentes alcances y períodos superpuestos. El caso práctico de temporada de festividades 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 de uso de temporada de festividades 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”)

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.

Ejemplo: La empresa ejecuta una combinación de cargas de trabajo de uso general y tolerantes a fallas

En este ejemplo, una empresa usa un clúster para ejecutar una combinación de cargas de trabajo que pueden tolerar las actualizaciones automáticas de los nodos y otras que no. El administrador del clúster desea que GKE controle las actualizaciones de nodos para algunos grupos de nodos, pero no para otros. El administrador del clúster usa una exclusión de mantenimiento del grupo de nodos para cualquier grupo de nodos que solo se pueda actualizar de forma manual.

¿Qué sigue?