Exclusiones y períodos de mantenimiento

En esta página, se describen los períodos de mantenimiento y las exclusiones de mantenimiento, que proporcionan control acerca de cuándo puede o no puede ocurrir el 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.

Descripción general

Las exclusiones y los períodos de mantenimiento te brindan un control detallado acerca de cuándo puede ocurrir el mantenimiento automático en tus clústeres.

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

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

Puedes configurar las exclusiones de mantenimiento y los períodos de mantenimiento por separado y de forma independiente. Puedes configurar varias exclusiones de mantenimiento.

Ejemplos de mantenimiento automático

Google realiza tareas de mantenimiento en tus clústeres según sea necesario o cuando realizas un cambio de configuración que vuelve a crear nodos o redes en el clúster, como se muestra a continuación:

Los clústeres zonales 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 otros tipos de cambios mencionados pueden causar interrupciones temporales mientras se migran las cargas de trabajo a los nodos actualizados.

Advertencias

Las exclusiones y los períodos de mantenimiento pueden causar retrasos en los parches de seguridad. GKE se reserva el derecho de anular las políticas de mantenimiento por vulnerabilidades de seguridad críticas. Antes de habilitar las exclusiones y los períodos de mantenimiento, asegúrate de comprender las siguientes advertencias.

Otras tareas de mantenimiento de Google Cloud

Los clústeres y las cargas de trabajo de GKE también pueden verse afectados por el mantenimiento automático de otros servicios dependientes, como Compute Engine. Las exclusiones y los períodos de mantenimiento de GKE no evitan el mantenimiento automático de otros servicios de Google o los servicios que instalan aplicaciones en el clúster, como Cloud Deploy.

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 se pueden inhabilitar la reparación de los planos de control.

Los nodos también tienen una funcionalidad de reparación automática, pero se pueden inhabilitar.

Períodos de mantenimiento y recreación de nodos

Cuando habilitas o modificas opciones o características, como las que afectan a las Herramientas de redes entre los nodos y los planos de control, los nodos se vuelven a crear para aplicar la configuración nueva. A continuación, se mencionan algunos ejemplos de características que provocan que los nodos se vuelvan a crear:

Si usas exclusiones o períodos de mantenimiento y habilitas o modificas una opción o característica que requiere que se vuelvan a crear los nodos, como la rotación de credenciales del clúster, se aplica la configuración nueva a los nodos solo cuando se permite el mantenimiento de los nodos. Si no quieres esperar, puedes aplicar los cambios a los nodos de forma manual. Para ello, llama al comando gcloud container clusters upgrade y pasa la marca --cluster-version con la misma versión de GKE que el grupo de nodos ya ejecuta. Debes usar Google Cloud CLI para esta solución alternativa.

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.

Restricciones

Los períodos de mantenimiento tienen las siguientes restricciones:

Un período de mantenimiento por clúster

Solo puedes configurar un único período de mantenimiento por clúster. Si configuras un período de mantenimiento nuevo, se reemplaza el anterior.

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

Cuando configuras período de mantenimiento con la marca --maintenance-window más genérica, no puedes especificar una zona horaria. Se usa UTC cuando se usa la CLI de gcloud o la API. 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. Los horarios siempre se almacenan en UTC.

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 el permiso de las actualizaciones automáticas que puedes restringir en una exclusión de mantenimiento. En la tabla, también se indica qué tipo de actualizaciones se producen (menor o parche). Cuando se realizan actualizaciones, las VM para el plano de control o el grupo de nodos se reinicia. Para los planos de control, los reinicios de VM pueden disminuir de forma temporal la disponibilidad del servidor de la API de Kubernetes, en especial en la topología de clúster zonal con un solo plano de control. 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).

Permiso Plano de control Grupos de nodos
Actualización menor Actualización de parches Interrupción de la VM
debido al mantenimiento de
GKE		 Actualización menor Actualización de parches Interrupción de la VM
debido al mantenimiento de
GKE
Sin actualizaciones (predeterminado) No No No No No No
Sin actualizaciones secundarias No Sí Sí No Sí Sí
Sin actualizaciones secundarias ni de nodos No Sí Sí No 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

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 estándar 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”.
  • La duración de una exclusión de mantenimiento tiene restricciones basadas en el permiso de exclusión que se especifica:
    • Sin actualizaciones: no puede superar los 30 días.
    • Sin actualizaciones menores: No puede finalizar más de 180 días después de la fecha de creación de la exclusión.
    • No hay actualizaciones secundarias ni de nodos: No puede finalizar más de 180 días después de la fecha de creación de la exclusión.
  • No puedes configurar una exclusión de mantenimiento para incluir o superar la fecha de final del ciclo de vida de la versión secundaria. Por ejemplo, con un clúster que ejecuta una versión secundaria en la que el programa de lanzamiento de GKE indica que su fecha de final del ciclo de vida es el 5 de junio de 2023, debes establecer la hora de finalización de la exclusión de mantenimiento para el 2023-06-05T00:00:00Z o antes.

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?