Acerca de las actualizaciones de clústeres con secuencia de lanzamiento

Puedes administrar el orden de las actualizaciones automáticas de clústeres en los clústeres de Google Kubernetes Engine (GKE) en varios entornos con la secuenciación de lanzamiento. Por ejemplo, puedes calificar una versión nueva en clústeres de preproducción antes de actualizar los clústeres de producción. Para usar esta característica, debes estar familiarizado conactualizaciones del clúster,Canales de versiones yadministración de flotas.

Para comenzar, consulta Establece una secuencia para el lanzamiento de las actualizaciones de los clústeres.

Terminología

En este documento, se usa el término grupo para hacer referencia a flotas o permisos de equipo, ya que puedes crear una secuencia de lanzamiento organizada con cualquier método de agrupación.

Califica actualizaciones en todos los entornos

Para actualizar de forma automática los clústeres con secuencia de lanzamiento, usa flotas o permisos de equipo en los que agrupaste los clústeres con el mismo canal de versiones y versión secundaria en etapas de implementación. Elige la secuencia de flotas o la secuencia de permisos de equipo y establece cuánto tiempo de prueba deseas entre cada grupo de clústeres. Luego, cuando GKE selecciona una versión nueva para las actualizaciones automáticas en el canal de versiones, los grupos de clústeres se actualizan en la secuencia que definiste y puedes validar que las cargas de trabajo se ejecuten como se espera con una versión nueva antes de que las actualizaciones comiencen con los clústeres de producción.

Secuencia de lanzamiento basada en flotas

En el siguiente diagrama se ilustra cómo GKE actualiza los clústeres de forma automática en una secuencia de lanzamiento organizada con flotas:

Secuencia de lanzamiento basada en flotas. Puedes organizar clústeres en flotas o subdividirlos en flotas con permisos.

Con una secuencia basada en flotas, cuando GKE pone a disposición un nuevo objetivo de actualización en el canal de versiones en el que se inscriben todos los clústeres de esta secuencia, GKE actualiza estas flotas de clústeres en esta secuencia, con los clústeres de la flota upstream que califican la versión nueva para clústeres en la flota downstream, hasta tres flotas. Upstream, en una secuencia de lanzamiento, hace referencia al grupo anterior y descendente hace referencia al siguiente grupo.

Durante el tiempo de prueba configurado entre las flotas, después de que se completen las actualizaciones en la flota upstream uy antes de que comiencen en la flota descendente, puedes confirmar que tus cargas de trabajo se ejecuten como se espera en los clústeres actualizados.

Secuencia de lanzamiento basada en equipos

Si subdividiste los clústeres en una flota por equipo o aplicación, puedes crear una secuencia de lanzamiento entre permisos de equipo. Los permisos de equipo son una construcción a nivel de flota empresarial para asociar subconjuntos de clústeres de flota con equipos de aplicaciones específicos y se pueden usar para habilitar una variedad de funciones basadas en equipos, incluidos el control de acceso y los observabilidad con alcance y secuenciación de lanzamiento.

Secuencias de lanzamiento basadas en permisos. Puedes organizar clústeres en flotas o subdividirlos en flotas con permisos.

Con los permisos de equipo, puedes crear varias secuencias de lanzamiento en una flota, cada una con sus propios canales de versiones, objetivos de actualización y tiempos de prueba independientes. Una secuencia de lanzamiento basada en equipos funciona de manera idéntica a una secuencia de lanzamiento basada en flotas, excepto que las actualizaciones se califican entre los clústeres de un equipo específico en cada flota, en lugar de hacerlo de flota a flota. Esto es particularmente útil para los operadores de aplicaciones que desean administrar actualizaciones dentro de los clústeres de su propio equipo.

La secuencia de lanzamiento basada en equipos se encuentra en vista previa, mientras que la secuencia de lanzamiento basada en flotas tiene disponibilidad general (DG).

Cómo GKE actualiza los clústeres en una secuencia de lanzamiento

Cuando GKE actualiza un clúster, primero se actualiza el plano de control y, luego, los nodos se actualizan. En una secuencia de lanzamiento, los clústeres se actualizan con este proceso, pero también puedes controlar el orden en que se actualizan los grupos (flotas o permisos) de los clústeres, y debes especificar un tiempo de prueba para elegir por cuánto tiempo GKE se detiene antes de que las actualizaciones continúen de un grupo al siguiente.

Las actualizaciones de clúster en una secuencia de lanzamiento continúan con los siguientes pasos:

  1. GKE establece un objetivo de actualización automática nuevo para los clústeres en una versión secundaria en un canal de versiones específico, con la nota de la versión que menciona algo similar al siguiente mensaje: “Los planos de control y los nodos con la actualización automática habilitada en el canal regular se actualizarán de la versión 1.21 a la versión 1.22.15‐gke.1000 con esta versión".
  2. GKE comienza a actualizar los planos de control del clúster a la versión nueva en el primer grupo de clústeres. Después de que GKE actualiza el plano de control de un clúster, GKE comienza a actualizar los nodos del clúster. GKE respeta la disponibilidad de mantenimiento cuando se actualizan clústeres en una secuencia de lanzamiento.
  3. GKE realiza los siguientes pasos para las actualizaciones del plano de control:
    1. GKE comienza el período de prueba para las actualizaciones del plano de control después de que finalizan todas las actualizaciones del plano de control del clúster en el primer grupo o 30 días desde que comenzaron las actualizaciones del plano de control.
    2. Una vez que se completa el período de prueba para las actualizaciones del plano de control del clúster en el primer grupo, GKE comienza a las actualizaciones del plano de control en el segundo grupo.
  4. En paralelo a las actualizaciones del plano de control, GKE sigue los siguientes pasos para las actualizaciones de nodos:
    1. GKE comienza el período de prueba para las actualizaciones de nodos después de que finalizan todas las actualizaciones de nodos del clúster en el primer grupo o después de que hayan transcurrido 30 días desde que comenzaron las actualizaciones de nodos.
    2. GKE inicia las actualizaciones de nodos en el segundo grupo para los clústeres en los que el plano de control ya se actualizó después de que se completó el período de prueba de las actualizaciones de nodos en el primer grupo.
  5. GKE repite estos pasos del segundo grupo al tercer grupo hasta que los clústeres de todos los grupos de la secuencia de lanzamiento se hayan actualizado al nuevo objetivo de actualización.

A medida que se actualizan los clústeres en cada grupo, verifica durante el tiempo de prueba que tus cargas de trabajo se ejecuten como se espera con los clústeres que ejecutan la versión nueva de GKE.

Es posible que no se puedan actualizar los clústeres debido a exclusiones o períodos de mantenimiento, el uso de APIs obsoletas o a otras razones. Para obtener más información, consulta Cómo funciona la secuenciación de lanzamiento con otras funciones de actualización.

Cómo controlar las actualizaciones en una secuencia de lanzamiento

Con las actualizaciones de clústeres en una secuencia de lanzamiento, los grupos de clústeres se actualizan en el orden que definiste y se prueban en cada grupo durante el tiempo que elijas. Mientras las actualizaciones están en curso, puedes verificar el estado de una secuencia de lanzamiento y administrar la secuencia de lanzamiento según sea necesario. También puedes controlar el proceso de las siguientes maneras:

Para obtener más información, consulta Cómo funciona la secuenciación de lanzamiento con otras funciones de actualización.

Ejemplo: El banco comunitario lanza de forma gradual los cambios de las pruebas a la producción

Por ejemplo, el administrador de la plataforma en un banco de la comunidad administra tres entornos de implementación principales, cada uno de los cuales está organizado en una flota: pruebas, almacenamiento en etapa intermedia y producción. Según sea necesario para la secuenciación de lanzamiento, el administrador inscribió cada clúster en las tres flotas en el mismo canal de versiones: en estas flotas, el canal regular con todos los clústeres que ejecutan la misma versión secundaria.

El administrador usa la secuenciación de lanzamiento para definir el orden en el que GKE actualiza los clústeres en estos entornos. Si pides el lanzamiento, el administrador tiene la oportunidad de verificar que sus cargas de trabajo se ejecuten como se espera con clústeres en una versión nueva de GKE antes de que el entorno de producción se actualice a la nueva versión. Esta secuencia se ilustra en el diagrama de secuencia de lanzamiento basada en flotas.

El administrador usa el tiempo de prueba entre estas flotas que se actualizan para verificar que sus cargas de trabajo se ejecuten como se espera con los clústeres en la versión nueva de GKE. Para la flota de pruebas, el administrador establece el tiempo de prueba en 14 días a fin de que tenga dos semanas completas para probar cómo se ejecutan las cargas de trabajo. Para el almacenamiento en etapa intermedia, establece el tiempo de prueba en 7 días, ya que no se necesita tanto tiempo adicional después de que las cargas de trabajo ya se hayan ejecutado en las pruebas.

El administrador también puede anular el tiempo de prueba predeterminado para las actualizaciones a versiones específicas, lo que podría hacer en una de las siguientes situaciones:

  • El administrador termina de calificar la versión antes de que se complete el tiempo de prueba y desea que las actualizaciones continúen con la siguiente flota, por lo que establece el tiempo de prueba en cero.
  • El administrador necesita más tiempo para calificar la versión nueva antes de que las actualizaciones continúen con la siguiente flota, ya que notó un problema con algunas de sus cargas de trabajo, por lo que establece el tiempo de prueba en el máximo de 30 días.

El administrador usa exclusiones y períodos de mantenimiento para garantizar que GKE actualice los clústeres cuando sea menos perjudicial para el banco. GKE respeta la disponibilidad de mantenimiento de los clústeres actualizados en una secuencia de lanzamiento.

  • El administrador configuró períodos de mantenimiento para sus clústeres a fin de garantizar que GKE solo actualice los clústeres después del horario de atención.
  • El administrador también usa exclusiones de mantenimiento para evitar que los clústeres se actualicen de forma temporal si detecta problemas con las cargas de trabajo del clúster.

El administrador usa una combinación de actualizaciones de aumento y actualizaciones azul-verde para sus nodos, lo que equilibra la velocidad y la tolerancia al riesgo según las cargas de trabajo que se ejecutan en esos nodos.

El administrador cambia a secuencias de lanzamiento basadas en equipos

Si el administrador decide que necesita agrupar más clústeres dentro de una flota por aplicación y darles a los administradores de su equipo de aplicaciones un mayor control sobre las actualizaciones de sus clústeres, pueden usar permisos de equipo. Con los permisos del equipo, los administradores del equipo de aplicaciones pueden crear secuencias de lanzamiento independientes con los grupos de clústeres asignados a sus equipos, que pueden ejecutarse en canales de versiones diferentes o con tiempos de prueba distintos.

Por ejemplo, si el equipo de la base de datos desea que sus clústeres usen el canal estable y tiempos de prueba más largos, mientras que los clústeres del equipo del sitio web de frontend usan el canal rápido y tiempos de prueba más cortos, puede usar los permisos de su equipo para crear un lanzamiento separado secuencias. Este tipo de secuencia se ilustra mediante el diagrama de secuencias de lanzamiento basadas en equipos. Para hacer esto en tu entorno, sigue las instrucciones para cambiar entre secuencias de lanzamiento basadas en flotas y basadas en equipos.

Ten en cuenta que el uso de esta función requiere clústeres de usuario único: en otras palabras, cada clúster individual está asociado solo con un equipo. Los clústeres compartidos (que son compatibles con la administración general de equipos de flotas) no son compatibles con la secuenciación de lanzamiento. Puedes obtener más información sobre la administración de clústeres para equipos en Administración de equipos de la flota.

Elegibilidad para el lanzamiento

Para que los clústeres se actualicen de forma automática con la secuenciación de implementación, todos los clústeres de todos los grupos (flotas o permisos) en una secuencia de lanzamiento deben recibir el mismo objetivo de actualización. Los clústeres deben estar inscritos en el mismo canal de versiones, y recomendamos que los clústeres ejecuten la misma versión secundaria ya que los objetivos de actualización se configuran por versión secundaria. Sin embargo, para algunas versiones, como la versión del siguiente ejemplo, los clústeres de varias versiones secundarias recibieron el mismo objetivo, lo que significa que podrían actualizarse correctamente en el secuencia de lanzamiento que ejecuta varias versiones secundarias.

Puedes verificar el estado del lanzamiento de la versión en una secuencia para obtener más información sobre el estado y si los problemas de elegibilidad de la versión están evitando que se realicen las actualizaciones. Según las discrepancias de la versión, es posible que debas tomar medidas, como actualizar un clúster de forma manual o quitarlo de un grupo para continuar con las actualizaciones de clústeres. Si un clúster de una secuencia de lanzamiento no tiene un objetivo de actualización apto, GKE no actualizará automáticamente el clúster hasta que la versión secundaria existente del clúster alcance el final del ciclo de vida.

Para solucionar problemas de elegibilidad para el lanzamiento, consulta Soluciona problemas de elegibilidad para el lanzamiento.

Ejemplo de versión de GKE

Por ejemplo, la versión 2022-R25 estableció un objetivo de actualización para varias versiones secundarias en los clústeres inscritos en el canal regular. Un objetivo de actualización puede ser una versión secundaria nueva (de 1.20 a 1.21) o solo una versión de parche nueva (1.21.x-gke.x a 1.21.14-gke.4300). En esta versión, en el canal regular, las siguientes versiones nuevas estaban disponibles para clústeres en versiones secundarias específicas:

  • Los clústeres en 1.20 y 1.21 se actualizaron a 1.21.14-gke.4300.
  • Los clústeres en 1.22 se actualizaron a 1.23.8-gke.1900.
  • Los clústeres en 1.24 se actualizaron a 1.24.5-gke.600.

El grupo más ascendente recibe todos los objetivos de actualización

Para los clústeres del primer grupo de una secuencia, que no tiene un grupo ascendente a fin de calificar versiones nuevas, GKE actualiza los clústeres con objetivos de actualización elegibles, sin importar si esos objetivos de actualización son diferentes unos de otros. Por ejemplo, en el primer grupo de una secuencia, si algunos clústeres ejecutan la versión 1.20, esos clústeres podrían actualizarse a 1.21.14-gke.4300, y los clústeres que ejecutan 1.24 se pueden actualizar a 1.24.5- gke.600 Esto se debe a que, para el primer grupo de una secuencia, GKE considera que todos los objetivos de actualización están calificados para estos clústeres, ya que no hay un grupo ascendente a fin de calificar una versión nueva.

Un grupo upstream debe calificar solo una versión

En cualquier grupo descendente, si GKE puede actualizar los clústeres depende de si el grupo ascendente calificó un objetivo de actualización para el que son elegibles todos los clústeres de este grupo. Por lo general, esto significa que todos los clústeres comienzan en la misma versión secundaria. Sin embargo, a partir de la versión de ejemplo, los clústeres en 1.20 y 1.21 tenían el mismo objetivo de actualización, por lo que los clústeres que ejecutan ambas versiones podrían, en el mismo grupo, calificar la actualización a 1.21.14-gke.4300

Si todos los clústeres de un grupo no tienen el mismo objetivo de actualización, este grupo no podrá calificar un objetivo de actualización para el siguiente grupo. En esta situación, GKE no puede actualizar de forma automática los clústeres en grupos descendentes. Por ejemplo, si en el primer grupo, algunos clústeres se actualizaron a 1.21.14-gke.4300 y otros a 1.23.8-gke.1900, los clústeres del segundo grupo no se pueden actualizar de forma automática ya que el grupo no recibió una versión calificada. Para avanzar con las actualizaciones en esta situación, consulta Corrige la elegibilidad en un grupo.

Un grupo upstream debe calificar una versión que coincida con los clústeres del siguiente grupo

Si los clústeres de un grupo ascendente calificaron una versión diferente a la versión por la que los clústeres del siguiente grupo fueron elegibles, GKE tampoco puede actualizar de forma automática los clústeres en ningún grupo descendente.

Por ejemplo, si todos los clústeres del primer grupo se actualizaron a la versión 1.21.14-gke.4300, pero los clústeres del segundo grupo ejecutaron la versión 1.22 (en la que el objetivo de actualización es 1.23.8-gke.1900), los clústeres del segundo grupo no se actualizarán de forma automática. El primer grupo calificaba 1.21.14-gke.4300, pero los clústeres del segundo grupo (actualmente en 1.22) solo son elegibles para el objetivo de actualización 1.23.8-gke.1900, por lo que GKE no puede actualizar estos clústeres de forma automática. Para avanzar en las actualizaciones de esta situación, consulta Corrige la elegibilidad entre grupos.

Cómo funciona la secuenciación de lanzamiento con otras funciones de actualización

La secuencia de lanzamiento es una función de una colección de funciones que te permiten controlar el aspecto de actualización del ciclo de vida del clúster. En esta sección, se explica cómo funciona con algunas de las otras funciones disponibles relacionadas con las actualizaciones de clústeres.

Cómo funciona la secuenciación de lanzamiento con exclusiones y períodos de mantenimiento

GKE respeta los períodos de mantenimiento y las exclusiones de mantenimiento cuando se actualizan clústeres con secuencia de lanzamiento. GKE solo inicia una actualización de clúster dentro del período de mantenimiento de un clúster. Puedes usar una exclusión de mantenimiento para evitar que un clúster se actualice de forma temporal. Si GKE no puede actualizar un clúster debido a una exclusión o período de mantenimiento, esto puede evitar que las actualizaciones de clúster finalicen en un grupo. Si una actualización del clúster no se puede completar en un plazo de 30 días debido a períodos de mantenimiento o exclusiones, el grupo ingresará a su fase de prueba, sin importar si todos los clústeres terminaron de actualizarse.

Puedes usar las exclusiones de mantenimiento como una medida temporal para evitar que una secuencia complete un lanzamiento en un grupo y pase al siguiente grupo. Para obtener más información, consulta Retrasa la finalización del lanzamiento de la versión del grupo.

Cómo funciona la secuenciación de lanzamiento con la detección del uso de elementos obsoletos

GKE pausa las actualizaciones del clúster cuando detecta el uso de ciertas APIs y funciones obsoletas. Las actualizaciones automáticas también se detienen en los clústeres que están dentro del grupo en una secuencia de lanzamiento. Para obtener más información, consulta Cómo funcionan las bajas de Kubernetes con GKE.

Cómo funciona la secuenciación de lanzamiento con estrategias de actualización de nodos

Las actualizaciones de nodos usarán su estrategia de actualización de nodos configurada cuando se actualicen en una secuencia de lanzamiento. Al igual que con las actualizaciones de clústeres sin secuencia de lanzamiento, GKE usa actualizaciones de aumento para los nodos de Autopilot. Para obtener más información, consulta Actualizaciones automáticas de los nodos.

Si las actualizaciones de nodos no se pueden completar en 30 días, el grupo ingresará a su fase de prueba, sin importar si todos los clústeres terminaron de actualizarse. Esto puede suceder si la estrategia de actualización de nodos hace que la actualización de nodos de un clúster Standard tarde más en completarse, en especial si es un grupo de nodos grande. También puede verse agravado por los períodos de mantenimiento que no son lo suficientemente extensos como para que una actualización de nodos se complete. Para obtener más información, consulta Consideraciones para configurar un período de mantenimiento.

Cómo funciona la secuenciación de lanzamiento con canales de versiones

Se requieren canales de versiones para usar la secuencia de lanzamiento. Todos los clústeres de todos los grupos de una secuencia de lanzamiento deben estar en el mismo canal de versiones.

Recibe varias actualizaciones en una secuencia

Si una versión nueva se convierte en un objetivo de actualización en el canal de versiones mientras las actualizaciones del clúster a un objetivo de actualización anterior aún continúan en la secuencia de lanzamiento, un grupo ascendente puede comenzar el lanzamiento de una versión nueva mientras un el grupo descendente aún recibe la actualización anterior. Por ejemplo, si el tercer grupo de una secuencia lanza 1.24.2-gke.100, el primer grupo en la secuencia puede lanzar 1.24.3-gke.500 de forma simultánea.

Consideraciones para elegir la secuencia de lanzamiento

Considera usar la secuenciación de lanzamiento si deseas administrar las actualizaciones de clústeres mediante la calificación de las versiones nuevas en un entorno antes de implementarlas en otro.

Sin embargo, es posible que esta no sea la opción correcta para tu entorno si se cumple alguna de las siguientes afirmaciones:

  • Tienes clústeres que no están en el mismo canal de versiones ni versión secundaria en el mismo entorno de producción.
  • Debes automatizar las actualizaciones que no se pueden asignar a solo tres etapas de implementación, ya que solo puedes crear una secuencia de lanzamiento con hasta tres grupos de clústeres. No puedes vincular grupos en varias secuencias de lanzamiento para crear una secuencia de lanzamiento con más de tres grupos.
  • No puedes usar la administración de flotas.
  • Con frecuencia, realizas actualizaciones manuales que hacen que los clústeres de un grupo tengan diferentes versiones de objetivo de actualización automática.

Para crear secuencias de lanzamiento basadas en equipos, también debes poder habilitar GKE Enterprise en tus proyectos host de flota.

Limitaciones

Para actualizar correctamente tus clústeres con secuenciación de lanzamiento, debes cumplir con las siguientes limitaciones:

  • Si usas la secuencia de lanzamiento basada en equipos, inscribe un clúster en un solo permiso de equipo. Si un clúster está inscrito en varios permisos de equipo, GKE no puede actualizar automáticamente el clúster en una secuencia de lanzamiento basada en equipos.
  • No se admite la creación de una secuencia de lanzamiento basada en equipos con varios permisos de equipo dentro de la misma flota.
  • Crea una secuencia de lanzamiento lineal sin ciclos (un grupo tiene un grupo descendente como su grupo ascendente) o ramas (un grupo tiene más de un grupo descendente).
  • Crea secuencias de lanzamiento entre los permisos de un equipo o secuencias de lanzamiento entre flotas. No puedes crear secuencias mixtas con flotas y permisos de equipo en la misma secuencia.
  • Asegúrate de que tus clústeres de una secuencia de lanzamiento estén inscritos en el mismo canal de versiones y que ejecuten la misma versión secundaria.

Problemas conocidos

  • Si un grupo contiene clústeres de diferentes ubicaciones, es posible que una actualización de clústeres solo esté disponible para algunos de los clústeres de forma temporal debido al lanzamiento gradual de la versión nueva. Es más probable que esto suceda con el primer grupo de clústeres y debería resolverse en una semana.
  • Si hay un grupo vacío en una secuencia de lanzamiento, la forma en que esto afecta la calificación de la versión depende de las siguientes condiciones:
    • Si el grupo vacío no tiene un grupo upstream, las actualizaciones del clúster no continúan con el grupo downstream, ya que el grupo vacío no puede calificar versiones.
    • Si el grupo vacío tiene un grupo ascendente, todas las actualizaciones de clúster pendientes ingresan al estado COMPLETE y se propagan al grupo descendente.
  • Debido a la forma en que GKE realiza un seguimiento de las actualizaciones menores y de parches, es posible que veas dos actualizaciones del mismo tipo y la misma versión, pero con estados diferentes cuando verifiques el estado del permiso.

¿Qué sigue?