Acerca de las actualizaciones de clústeres con secuenciación de lanzamientos

Puedes gestionar el orden de las actualizaciones automáticas de clústeres en clústeres de Google Kubernetes Engine (GKE) de varios entornos mediante la secuenciación de lanzamientos. Por ejemplo, puedes validar una nueva versión en clústeres de preproducción antes de actualizar los clústeres de producción. Para usar esta función, debes familiarizarte con las actualizaciones de clústeres, los canales de lanzamiento y la gestión de flotas.

Para empezar, consulta Secuenciar el lanzamiento de actualizaciones de clústeres.

Terminología

En este documento se usa el término grupo para hacer referencia tanto a las flotas como a los ámbitos de equipo, ya que puedes crear una secuencia de lanzamiento organizada con cualquiera de los dos métodos de agrupación.

Validar las actualizaciones en distintos entornos

Para actualizar automáticamente los clústeres con secuenciación de lanzamientos, usa flotas o ámbitos de equipo, donde hayas agrupado los clústeres con el mismo canal de lanzamiento y la misma versión secundaria en fases de implementación. Elige la secuencia de flotas o de ámbitos de equipo y define el tiempo de prueba de carga que quieres que transcurra entre cada grupo de clústeres. Después, cuando GKE seleccione una nueva versión para las actualizaciones automáticas en el canal de lanzamiento, tus grupos de clústeres se actualizarán en la secuencia que hayas definido y podrás validar que las cargas de trabajo se ejecutan correctamente con una nueva versión antes de que empiecen las actualizaciones en tus clústeres de producción.

Secuencia de lanzamiento basada en flotas

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

Secuencia de lanzamiento basada en flotas. Puedes organizar los clústeres en flotas o subdividirlos en flotas con ámbitos.

Con una secuencia basada en flotas, cuando GKE pone a disposición un nuevo destino de actualización en el canal de lanzamiento en el que están registrados todos los clústeres de esta secuencia, GKE actualiza estas flotas de clústeres en esta secuencia. Los clústeres de la flota upstream validan la nueva versión para los clústeres de la flota downstream, hasta un máximo de cinco flotas. En una secuencia de lanzamiento, "upstream" hace referencia al grupo anterior y "downstream" al siguiente.

Durante el tiempo de espera configurado entre las flotas (después de que se completen las actualizaciones en la flota upstream y antes de que empiecen en la flota downstream), puedes confirmar que tus cargas de trabajo se ejecutan correctamente en los clústeres actualizados.

Secuencia de lanzamiento basada en equipos

Si has subdividido aún más los clústeres de una flota por equipo o aplicación, puedes crear una secuencia de lanzamiento entre los ámbitos de los equipos. Los permisos de equipo asocian subconjuntos de clústeres de la flota con equipos de aplicaciones específicos y se pueden usar para habilitar una serie de funciones basadas en equipos, como el control de acceso, la observabilidad con permisos de equipo y la secuenciación de lanzamientos.

Secuencias de lanzamiento basadas en el ámbito. Puedes organizar los clústeres en flotas o subdividirlos en flotas con ámbitos.

Con los ámbitos de equipo, puedes crear varias secuencias de lanzamiento en una flota, cada una con sus propios canales de lanzamiento, objetivos de actualización y tiempos de prueba independientes. Una secuencia de lanzamiento basada en equipos funciona de forma idéntica a una secuencia de lanzamiento basada en flotas, excepto que las actualizaciones se cualifican entre los clústeres de un equipo específico de cada flota, en lugar de entre flotas. Esto resulta especialmente útil para los operadores de aplicaciones que quieran gestionar las actualizaciones en los clústeres de su equipo.

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

Cuando GKE actualiza un clúster, primero se actualiza el plano de control y, después, los nodos. En una secuencia de lanzamiento, los clústeres se siguen actualizando con este proceso, pero también puedes controlar el orden en el que se actualizan los grupos (flotas o ámbitos) de clústeres y especificar un tiempo de espera para elegir durante cuánto tiempo se detiene GKE antes de que las actualizaciones pasen de un grupo al siguiente.

Las actualizaciones de clústeres en una secuencia de lanzamiento se realizan siguiendo estos pasos:

  1. GKE establece un nuevo destino de actualización automática para los clústeres de una versión secundaria en un canal de lanzamiento específico. En las notas de la versión se 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 este lanzamiento".
  2. GKE empieza a actualizar los planos de control de los clústeres a la nueva versión en el primer grupo de clústeres. Después de que GKE actualice el plano de control de un clúster, GKE empieza a actualizar los nodos del clúster. GKE respeta la disponibilidad del mantenimiento al actualizar clústeres en una secuencia de lanzamiento.

  3. GKE realiza los siguientes pasos para actualizar el plano de control:

    1. GKE inicia el periodo de estabilización de las actualizaciones del plano de control una vez que se hayan completado todas las actualizaciones del plano de control de los clústeres del primer grupo. GKE también inicia el periodo de estabilización si han transcurrido más de 30 días desde que empezaron las actualizaciones del plano de control. Para obtener más información, consulta Las actualizaciones que no se completen en un plazo de 30 días se aplicarán de forma obligatoria para desbloquear la secuencia.

    2. Una vez que haya finalizado el periodo de estabilización de las actualizaciones del plano de control del clúster del primer grupo, GKE empezará a actualizar el plano de control del segundo grupo a la nueva versión. Sin embargo, debes tener en cuenta las siguientes advertencias:

  4. Paralelamente a las actualizaciones del plano de control, GKE lleva a cabo los siguientes pasos para actualizar los nodos:

    1. GKE inicia el periodo de estabilización de las actualizaciones de nodos después de que se hayan completado todas las actualizaciones de nodos del clúster en el primer grupo. GKE también inicia el periodo de estabilización si han transcurrido más de 30 días desde que empezaron las actualizaciones de los nodos. Para obtener más información, consulta Las actualizaciones que no se completen en un plazo de 30 días se aplicarán de forma obligatoria para desbloquear la secuencia.
    2. Una vez que haya finalizado el periodo de estabilización de las actualizaciones de nodos del primer grupo, GKE empezará a actualizar los nodos del segundo grupo a la nueva versión. Sin embargo, debes tener en cuenta las siguientes advertencias:

  5. GKE repite estos pasos del segundo grupo al tercero hasta que los clústeres de todos los grupos de la secuencia de lanzamiento se hayan actualizado a la nueva versión de destino.

A medida que se actualicen los clústeres de cada grupo, comprueba durante el tiempo de permanencia que tus cargas de trabajo se ejecutan correctamente con los clústeres que tienen la nueva versión de GKE.

También es posible que no se puedan actualizar los clústeres debido a ventanas de mantenimiento o exclusiones, al uso de APIs obsoletas o a otros motivos. Para obtener más información, consulta Cómo funciona la secuenciación de lanzamientos 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 hayas definido y se someten a pruebas en cada grupo durante el tiempo que hayas elegido. Mientras se realizan las actualizaciones, puedes consultar el estado de una secuencia de lanzamiento y gestionar la secuencia de lanzamiento según sea necesario. También puedes controlar el proceso de las siguientes formas:

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

Ejemplo: Un banco comunitario implementa gradualmente los cambios de pruebas a producción

Por ejemplo, el administrador de la plataforma de un banco comunitario gestiona tres entornos de implementación principales, cada uno de ellos un grupo de clústeres organizados en una flota: pruebas, staging y producción. Como se requiere para la secuenciación de lanzamientos, el administrador ha registrado cada clúster de las tres flotas en el mismo canal de lanzamiento (en estas flotas, el canal Regular), y todos los clústeres ejecutan la misma versión secundaria.

El administrador usa la secuenciación de lanzamientos para definir el orden en el que GKE actualiza los clústeres de estos entornos. Al ordenar el lanzamiento, el administrador tiene la oportunidad de verificar que sus cargas de trabajo se ejecutan según lo previsto con clústeres en una nueva versión 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 basado en la flota.

El administrador usa el tiempo de permanencia entre la actualización de estas flotas para verificar que sus cargas de trabajo se ejecutan correctamente con los clústeres de la nueva versión de GKE. En el caso de la flota de pruebas, el administrador define el tiempo de permanencia en 14 días para tener dos semanas completas para probar cómo se ejecutan las cargas de trabajo. En el caso del entorno de preproducción, han definido un tiempo de permanencia de 7 días, ya que no necesitan tanto tiempo adicional después de que las cargas de trabajo ya se hayan ejecutado en el entorno de pruebas.

El administrador también puede anular el tiempo de permanencia predeterminado para las actualizaciones a versiones específicas, lo que puede ser útil en una de las siguientes situaciones:

  • El administrador termina de calificar la versión antes de que finalice el tiempo de prueba y quiere que las actualizaciones pasen a la siguiente flota, por lo que establece el tiempo de prueba en cero.
  • El administrador necesita más tiempo para comprobar la nueva versión antes de que las actualizaciones se apliquen a la siguiente flota, ya que ha detectado un problema con algunas de sus cargas de trabajo. Por eso, establece el tiempo de permanencia en el máximo de 30 días.

El administrador usa ventanas de mantenimiento y exclusiones para asegurarse de 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 ha configurado ventanas de mantenimiento para sus clústeres con el fin de asegurarse de que GKE solo actualice los clústeres fuera del horario de apertura.
  • El administrador también usa las exclusiones de mantenimiento para evitar temporalmente que se actualicen los clústeres 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, de forma que se equilibren la velocidad y la tolerancia al riesgo en función de las cargas de trabajo que se ejecuten en esos nodos.

El administrador cambia a secuencias de lanzamiento basadas en equipos

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

Por ejemplo, si el equipo de la base de datos quiere que sus clústeres usen el canal Estable y tiempos de prueba más largos, mientras que el equipo del sitio web frontend quiere que sus clústeres usen el canal Rápido y tiempos de prueba más cortos, pueden usar sus ámbitos de equipo para crear secuencias de lanzamiento independientes. Este tipo de secuencia se ilustra en el diagrama de secuencia de lanzamiento por equipos. Para hacerlo en tu entorno, sigue las instrucciones para cambiar entre secuencias de lanzamiento basadas en flotas y en equipos.

Ten en cuenta que para usar esta función se necesitan clústeres de un solo inquilino. Es decir, cada clúster solo está asociado a un equipo. Los clústeres compartidos (que se admiten en la gestión de flotas de equipos en general) no se admiten en la secuenciación de lanzamientos. Puedes consultar más información sobre cómo gestionar clústeres para equipos en Gestión de equipos de la flota.

Requisitos de lanzamiento

Para que los clústeres se actualicen automáticamente con la secuenciación de lanzamientos, todos los clústeres de todos los grupos (flotas o ámbitos) de una secuencia de lanzamientos deben recibir el mismo destino de actualización. Los clústeres deben estar registrados en el mismo canal de lanzamiento y recomendamos que ejecuten la misma versión secundaria, ya que los destinos de actualización se definen por versión secundaria. Sin embargo, en algunas versiones, como la del siguiente ejemplo, los clústeres de varias versiones secundarias recibieron el mismo destino, lo que significa que los clústeres se podían actualizar correctamente en la secuencia de lanzamiento que ejecutaba varias versiones secundarias.

Puedes consultar el estado del lanzamiento de la versión en una secuencia para obtener más información sobre el estado y si hay problemas con los requisitos de la versión que impiden que se realicen las actualizaciones. En función de las discrepancias entre versiones, es posible que tengas que realizar acciones como actualizar manualmente un clúster o quitarlo de un grupo para que se puedan actualizar los clústeres. Si un clúster de una secuencia de lanzamiento no tiene un destino de actualización apto, GKE no actualizará automáticamente el clúster hasta que la versión secundaria del clúster llegue al final del periodo de asistencia.

Para solucionar problemas relacionados con los requisitos de lanzamiento, consulta el artículo Solucionar problemas relacionados con los requisitos de lanzamiento.

Ejemplo de lanzamiento de GKE

Por ejemplo, la versión 2022-R25 definió un objetivo de actualización para varias versiones secundarias en clústeres registrados en el canal Regular. Una versión de destino puede ser una versión secundaria nueva (de 1.20 a 1.21) o una versión de parche nueva (de 1.21.x-gke.x a 1.21.14-gke.4300). En esta versión, en el canal habitual, se han puesto a disposición las siguientes versiones nuevas para clústeres en versiones secundarias específicas:

  • Los clústeres de las versiones 1.20 y 1.21 se han actualizado a la versión 1.21.14-gke.4300.
  • Los clústeres de la versión 1.22 se han actualizado a la 1.23.8-gke.1900.
  • Los clústeres de la versión 1.24 se han actualizado a la 1.24.5-gke.600.

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

En el caso de los clústeres del primer grupo de una secuencia, que no tiene un grupo upstream para calificar las nuevas versiones, GKE actualiza los clústeres con destinos de actualización aptos, independientemente de si esos destinos de actualización son diferentes entre sí. Por ejemplo, en el primer grupo de una secuencia, si algunos clústeres ejecutaban la versión 1.20, se podrían actualizar a la versión 1.21.14-gke.4300, y los clústeres que ejecutaban la versión 1.24 se podrían actualizar a la versión 1.24.5-gke.600. Esto se debe a que, en el primer grupo de una secuencia, GKE considera que todos los destinos de actualización son aptos para estos clústeres, ya que no hay ningún grupo upstream que pueda determinar si una versión es apta.

Un grupo upstream solo debe calificar una versión

En cualquier grupo de nivel inferior, la posibilidad de que GKE actualice los clústeres depende de si el grupo de nivel superior ha determinado un destino de actualización para el que todos los clústeres de este grupo sean aptos. Por lo general, esto significa que todos los clústeres empiezan con la misma versión secundaria. Sin embargo, en la versión de ejemplo, los clústeres de las versiones 1.20 y 1.21 tenían el mismo destino de actualización, por lo que los clústeres que ejecutaban ambas versiones podían, en el mismo grupo, optar a la actualización a la versión 1.21.14-gke.4300.

Los clústeres que ejecutan versiones posteriores a la de destino de la actualización no impiden las actualizaciones

Si un grupo de nivel inferior tiene clústeres que ejecutan una versión posterior a la versión de destino de la actualización cualificada por un grupo de nivel superior, GKE actualiza los clústeres aptos para la versión de destino de la actualización e ignora los clústeres que ya tienen una versión posterior. Esto no impide que la secuencia de lanzamiento avance, siempre que al menos un clúster del grupo de nivel inferior cumpla los requisitos para la versión de destino.

Por ejemplo, si el grupo upstream ha calificado la actualización a la versión 1.23 y el grupo downstream tiene clústeres con las versiones 1.22 y 1.24, GKE actualizará los clústeres con la versión 1.22 a la 1.23 e ignorará los clústeres con la versión 1.24.

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

Si los clústeres de un grupo upstream cumplen los requisitos de una versión diferente a la de los clústeres del siguiente grupo, GKE tampoco podrá actualizar automáticamente los clústeres de ningún grupo downstream.

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 ejecutaban la versión 1.22 (donde la versión de actualización es 1.23.8-gke.1900), los clústeres del segundo grupo no se actualizarían automáticamente. El primer grupo se ha calificado para la versión 1.21.14-gke.4300, pero los clústeres del segundo grupo (que actualmente tienen la versión 1.22) solo pueden actualizarse a la versión 1.23.8-gke.1900, por lo que GKE no puede actualizar automáticamente estos clústeres. Para avanzar en las actualizaciones en esta situación, consulta Corregir la elegibilidad entre grupos.

El grupo upstream ha calificado varios objetivos de actualización para el grupo downstream

Si GKE actualiza los clústeres del grupo upstream varias veces antes de actualizar los clústeres del grupo downstream, GKE actualiza los clústeres del grupo downstream a la versión más reciente cualificada por el grupo upstream para la que los clústeres del grupo downstream cumplen los requisitos. En el caso de las actualizaciones del plano de control, esta versión puede ser como máximo una versión secundaria posterior a la versión del plano de control de los clústeres del grupo de nivel inferior. En el caso de las actualizaciones de nodos, esta versión puede ser igual a la versión del plano de control de los clústeres del grupo de nivel inferior, pero no posterior.

Por ejemplo, este caso es pertinente si ha configurado exclusiones de mantenimiento para evitar temporalmente las actualizaciones de su grupo de nivel inferior, que incluye sus clústeres de producción. Sin embargo, tu grupo upstream, que incluye clústeres de preproducción, no ha usado exclusiones de mantenimiento para evitar las actualizaciones. Por lo tanto, tu grupo de nivel superior se ha actualizado varias veces, lo que ha permitido que haya varios objetivos de actualización posibles, mientras que tu grupo de nivel inferior no se ha actualizado.

Las actualizaciones que no se completen en un plazo de 30 días se forzarán para desbloquear la secuencia.

Para asegurarse de que una secuencia de lanzamiento finaliza la actualización de los clústeres, GKE inicia el periodo de estabilización de un grupo si las actualizaciones del plano de control o de los nodos, respectivamente, no se completan en todos los clústeres en el tiempo máximo de actualización (30 días). Las actualizaciones de los clústeres restantes del grupo pueden seguir durante el periodo de estabilización. Para obtener más información, consulta la fila de FORCED_SOAKING en Información de estado de una tabla de secuencia de lanzamiento.

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

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

Cómo funciona la secuenciación de lanzamientos con ventanas de mantenimiento y exclusiones

GKE respeta las ventanas de mantenimiento y las exclusiones de mantenimiento al actualizar clústeres con secuenciación de lanzamientos. GKE solo inicia la actualización de un clúster dentro de la ventana de mantenimiento del clúster. Puedes usar una exclusión de mantenimiento para evitar temporalmente que se actualice un clúster. Si GKE no puede actualizar un clúster debido a una ventana de mantenimiento o a una exclusión, esto puede impedir que las actualizaciones de clústeres se completen en un grupo. Si no se puede completar la actualización de un clúster en un plazo de 30 días debido a ventanas de mantenimiento o exclusiones, el grupo entrará en su fase de prueba de carga independientemente de si se han actualizado todos los clústeres.

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

Cómo funciona la secuenciación de lanzamientos con la detección de uso de funciones obsoletas

GKE pausa las actualizaciones de clústeres cuando detecta el uso de determinadas APIs y funciones obsoletas. Las actualizaciones automáticas también se pausan en los clústeres de un grupo en una secuencia de lanzamiento. Para obtener más información, consulta Cómo funcionan las obsolescencias de Kubernetes con GKE.

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

Las actualizaciones de nodos usarán la 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 secuenciación de lanzamientos, GKE usa actualizaciones de aumento para los nodos de Autopilot. Para obtener más información, consulta Actualizaciones automáticas de nodos.

Si las actualizaciones de los nodos no se pueden completar en un plazo de 30 días, el grupo entrará en la fase de prueba, independientemente de si todos los clústeres han terminado de actualizarse. Esto puede ocurrir si la estrategia de actualización de nodos hace que la actualización de nodos de un clúster estándar tarde más en completarse, sobre todo si se trata de un grupo de nodos grande. También puede empeorar si las ventanas de mantenimiento no son lo suficientemente grandes para que se complete la actualización de un nodo. Para obtener más información, consulta Consideraciones al configurar una ventana de mantenimiento.

Cómo funciona la secuenciación de lanzamientos con los canales de lanzamiento

Para usar la secuenciación de lanzamientos, es necesario usar canales de lanzamiento. Todos los clústeres de todos los grupos de una secuencia de lanzamiento deben estar en el mismo canal de lanzamiento.

Recibir varias actualizaciones en una secuencia

Si una nueva versión se convierte en el destino de una actualización en el canal de lanzamiento mientras se siguen llevando a cabo las actualizaciones del clúster a un destino de actualización anterior en la secuencia de lanzamiento, un grupo upstream puede iniciar el lanzamiento de una nueva versión mientras un grupo downstream sigue recibiendo la actualización anterior. Por ejemplo, si el tercer grupo de una secuencia está implementando la versión 1.24.2-gke.100, el primer grupo de la secuencia puede estar implementando simultáneamente la versión 1.24.3-gke.500.

Consideraciones al elegir la secuencia de lanzamiento

Te recomendamos que uses la secuenciación de implementaciones si quieres gestionar las actualizaciones de clústeres calificando las versiones nuevas en un entorno antes de implementarlas en otro.

Sin embargo, puede que no sea la opción adecuada para tu entorno si se cumple alguna de las siguientes condiciones:

  • Tienes clústeres que no están en el mismo canal de lanzamiento o versión secundaria en el mismo entorno de producción.
  • Debes automatizar las actualizaciones que no se puedan asignar a solo cinco fases de implementación, ya que solo puedes crear una secuencia de lanzamiento con un máximo de cinco grupos de clústeres. No puedes vincular grupos de varias secuencias de lanzamiento para crear una secuencia de lanzamiento con más de cinco grupos. Las secuencias basadas en flotas pueden incluir hasta cinco flotas, y las secuencias basadas en equipos pueden incluir hasta tres permisos de equipo.
  • No puedes usar la gestión de flotas.
  • Realizas actualizaciones manuales con frecuencia, lo que provoca que los clústeres de un grupo tengan versiones de destino de actualización automática diferentes.

Limitaciones

Para actualizar correctamente los clústeres con la secuenciación de la implementación, debes cumplir las siguientes limitaciones:

  • Asegúrate de que todos los clústeres de una secuencia de lanzamiento estén registrados en el mismo canal de lanzamiento. También se recomienda que todos los clústeres ejecuten la misma versión secundaria para poder optar a un objetivo de actualización. Para obtener más información, consulta la sección Requisitos para el lanzamiento.
  • Si utilizas la secuenciación de lanzamientos basada en equipos, registra un clúster en un solo ámbito de equipo. Si un clúster está registrado en varios ámbitos de equipo, GKE no puede actualizarlo automáticamente en una secuencia de lanzamiento basada en equipos.
  • No se puede crear una secuencia de lanzamiento basada en equipos con varios ámbitos de equipo en la misma flota.
  • Crea una secuencia de lanzamiento lineal sin ciclos (un grupo tiene un grupo de nivel inferior como grupo de nivel superior) ni ramificaciones (un grupo tiene más de un grupo de nivel inferior).
  • Crea secuencias de lanzamiento entre los ámbitos de un equipo o entre flotas. No puedes crear secuencias mixtas con flotas y ámbitos de equipo en la misma secuencia.
  • Crea una secuencia de lanzamiento entre clústeres de la misma organización. No puedes crear secuencias con clústeres de varias organizaciones.

Problemas conocidos

  • Si un grupo contiene clústeres de diferentes ubicaciones, es posible que una actualización de clúster solo esté disponible temporalmente para algunos de los clústeres debido al lanzamiento gradual de la nueva versión. Es más probable que esto ocurra en 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 a la cualificación de la versión depende de las siguientes condiciones:
    • Si el grupo vacío no tiene ningún grupo upstream, las actualizaciones del clúster no se llevarán a cabo en el grupo downstream, ya que el grupo vacío no puede calificar versiones.
    • Si el grupo vacío tiene un grupo upstream, todas las actualizaciones de clúster pendientes pasan al estado COMPLETE y se propagan al grupo downstream.
  • Debido a la forma en que GKE monitoriza las actualizaciones de parches y las actualizaciones secundarias, es posible que veas dos actualizaciones del mismo tipo y versión, pero con estados diferentes, al comprobar el estado del ámbito.

Siguientes pasos