Acerca de la secuenciación de lanzamientos con fases personalizadas

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. GKE también ofrece una versión disponible para el público general de la secuenciación de lanzamientos que usa un modelo más lineal sin fases personalizadas.

En este documento se da por hecho que conoces los siguientes conceptos:

Para configurar una secuencia de lanzamiento, consulta Secuenciar el lanzamiento de actualizaciones de clústeres.

Información general

La secuenciación de lanzamientos de GKE te permite definir una secuencia específica y ordenada para las actualizaciones de clústeres en diferentes entornos, como actualizar primero los clústeres del entorno de desarrollo, después los del entorno de pruebas y, por último, los del entorno de producción. Esta estrategia progresiva proporciona un tiempo de espera integrado, lo que te permite descubrir y mitigar posibles problemas antes de que la actualización llegue a tus sistemas más críticos.

La secuenciación de lanzamientos se basa en el concepto de flotas, que son agrupaciones lógicas de clústeres de GKE asignados a un entorno (por ejemplo, de pruebas). Para usar esta función, define una secuencia de flotas y establece el tiempo de prueba entre cada grupo. Cuando GKE selecciona una nueva versión, tus clústeres se actualizan en el orden definido, lo que te permite validar las cargas de trabajo antes de que la versión se despliegue por completo en tu entorno de producción.

Las flotas admiten membresías ligeras, que te permiten agrupar clústeres de forma lógica para secuenciar los lanzamientos sin habilitar todas las configuraciones y funciones a nivel de flota. La pertenencia ligera es una buena opción si quieres usar la secuenciación de lanzamientos sin algunas de las otras implicaciones de la gestión completa de la flota, como la igualdad del espacio de nombres a nivel de flota. Para obtener más información, consulta Suscripciones ligeras.

Elegir una estrategia de secuenciación de lanzamiento

GKE ofrece dos versiones de la secuenciación de lanzamientos. Ambas versiones se basan en los mismos principios de actualización progresiva basada en flotas, pero ofrecen diferentes niveles de flexibilidad. En esta sección se explica cómo decidir qué versión es la más adecuada para tu caso práctico.

  • Secuencia de lanzamiento basada en flotas (disponibilidad general): esta versión es la estrategia disponible de forma general y recomendada para la mayoría de los casos prácticos de producción. La secuenciación de lanzamientos basada en flotas proporciona un método estable y compatible para lanzar actualizaciones de forma progresiva en diferentes entornos (como pruebas, staging y producción) y usa una secuencia lineal de flotas.

  • Secuencia de lanzamiento con fases personalizadas (vista previa): esta versión es una evolución del modelo basado en flotas, que ofrece un control más granular y más flexibilidad. Con las fases personalizadas, puedes definir fases específicas en una flota mediante etiquetas, lo que las convierte en una buena opción para estrategias de lanzamiento más complejas, como desplegar una nueva versión en un pequeño subconjunto de clústeres de producción antes de un lanzamiento más amplio. Elige esta opción si necesitas más flexibilidad o quieres ver una vista previa de las funciones de secuenciación de lanzamientos más recientes.

El resto de este documento solo se refiere a la secuenciación de lanzamientos con fases personalizadas.

Secuenciación de lanzamientos con fases personalizadas

Cuando usas la secuenciación de implementaciones con fases personalizadas, defines el orden de las actualizaciones de la flota y estableces los tiempos de prueba. Además, también puedes hacer lo siguiente:

  • Define una secuencia con fases detalladas que puedan orientarse a subconjuntos específicos de clústeres de una flota mediante etiquetas, lo que la convierte en una buena opción para estrategias como los lanzamientos graduales.
  • Consigue más control y observabilidad con los nuevos objetos de API RolloutSequence y Rollout.

Este método ofrece la mayor flexibilidad y control detallado sobre las actualizaciones de tu clúster. Para orientar los anuncios a subconjuntos específicos de clústeres de una flota, se usa un label-selector para orientar los anuncios solo a los clústeres que tengan etiquetas de Kubernetes específicas.

En el siguiente diagrama se muestra cómo actualiza automáticamente GKE los clústeres en una secuencia de lanzamiento que usa fases personalizadas. La fase se dirige a clústeres con un label-selector llamado canary en la flota prod:

Secuencia de lanzamiento con fases personalizadas en GKE.
Imagen: Secuencia de lanzamiento con etapas personalizadas

Cuando haya disponible una nueva versión de destino en el canal de lanzamiento en el que estén registrados todos los clústeres de esta secuencia, GKE actualizará primero los clústeres de la flota de pruebas y, después, los de la flota de preproducción. A continuación, en la flota de producción, GKE prioriza los clústeres que coincidan con label-selector. Como prod-cluster-1 tiene la etiqueta canary: true, GKE actualizará este clúster a continuación. GKE actualiza todos los clústeres restantes de la flota de producción (en la fase principal) al final del proceso, ya que esta fase no tiene ningún selector de etiquetas.

Durante el tiempo de permanencia configurado entre las fases, puedes confirmar que tus cargas de trabajo se ejecutan según lo previsto en los clústeres actualizados. En el ejemplo anterior se muestra una fase personalizada en la flota de producción, pero puedes añadir varias fases a cualquier flota o usar solo una flota con varias fases.

Conceptos clave

  • Tiempo de reposo: este periodo es un tiempo de espera configurable que se produce después de actualizar todos los clústeres de una fase. Este tiempo de compilación te permite validar la nueva versión en un entorno y detectar posibles problemas antes de que la actualización se lleve a cabo en el siguiente entorno. Puedes configurar un tiempo de espera de hasta 30 días para cada fase de tu secuencia. Si dejas que se empape durante más tiempo en la fase de preproducción, tendrás más tiempo para validar el contenido.
  • RolloutSequence: es el recurso principal que usas para definir tu secuencia de actualización. RolloutSequence contiene una serie ordenada de fases, que verifica que los clústeres de las fases anteriores se hayan actualizado por completo y hayan completado su periodo de prueba antes de que la actualización pase a la siguiente fase.
  • Rollout: este objeto te permite observar el progreso de una sola actualización de versión a través de tu secuencia. Puedes usar Rollout para ver el estado del lanzamiento, hacer un seguimiento del progreso y comprobar si algún clúster no cumple los requisitos para la actualización y por qué.
  • Proyecto host específico: te recomendamos que uses un proyecto específico para alojar tus objetos RolloutSequence. Google Cloud Si colocas la secuencia en un proyecto específico, tendrás un punto de control central y neutral para tus secuencias de lanzamiento, lo que es una práctica recomendada similar a la de gestionar flujos de trabajo de CI/CD.
Práctica recomendada:

Crea y gestiona tus RolloutSequence recursos en un proyecto host específico.

  • Fases: una fase es un paso de la secuencia de lanzamiento. Cada fase contiene un grupo de clústeres que se actualizan juntos.
  • Flotas: las flotas son la forma principal de agrupar clústeres. Una fase de una secuencia de lanzamiento solo puede hacer referencia a una flota.
  • Selectores de etiquetas: una secuencia de lanzamiento se compone de una o varias fases. Cada fase contiene clústeres de una flota y puedes usar selectores de etiquetas en los clústeres para dividir una flota en varias fases. Este enfoque permite aplicar estrategias como los lanzamientos por fases, en los que primero se actualiza un pequeño subconjunto de clústeres de producción.

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) de clústeres. También puedes especificar un tiempo de espera que define cuánto tiempo GKE hace una pausa 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, con una nota de lanzamiento 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.29 a la versión 1.30.14-gke.1150000 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 sigue estos pasos para actualizar el plano de control:

    1. Una vez que se hayan completado todas las actualizaciones del plano de control del clúster del primer grupo, GKE iniciará el periodo de prueba de las actualizaciones del plano de control. 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.

    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 los planos de control del segundo grupo a la nueva versión. Sin embargo, ten en cuenta lo siguiente:

      • En algunos casos, GKE puede actualizar los planos de control del clúster del primer grupo varias veces antes de actualizar los planos de control del clúster del segundo grupo. Cuando se da esta situación, GKE elige la versión más reciente que también tenga los siguientes atributos:
        • La versión se determina por el primer grupo.
        • La versión es, como máximo, una versión secundaria posterior a la versión del plano de control de los clústeres del segundo grupo.
      • GKE no actualiza el plano de control de los clústeres del segundo grupo que tengan una versión posterior a la versión de destino de la actualización automática cualificada por el primer grupo.

  4. Paralelamente a las actualizaciones del plano de control, GKE sigue estos pasos para actualizar los nodos:

    1. Una vez que se hayan completado las actualizaciones de nodos de todos los clústeres del primer grupo, GKE iniciará el periodo de estabilización de las actualizaciones de nodos. 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.
    2. Una vez que se haya completado el periodo de prueba de las actualizaciones de los nodos del primer grupo, GKE empezará a actualizar los nodos del segundo grupo a la nueva versión. Sin embargo, ten en cuenta lo siguiente:
      • En algunos casos, GKE puede actualizar los nodos del clúster del primer grupo varias veces antes de actualizar los nodos del clúster del segundo grupo. Cuando se da esta situación, GKE elige la versión más reciente que también tenga los siguientes atributos:
        • La versión se determina por el primer grupo.
        • La versión no es posterior a la versión del plano de control del clúster del segundo grupo.
      • GKE no actualiza los nodos de los clústeres del segundo grupo que tengan una versión posterior a la de destino de la actualización automática cualificada por el primer grupo.

  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.

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

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.

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 mantienen en cada grupo durante el tiempo que hayas elegido. Mientras se realizan las actualizaciones, puedes consultar el estado y gestionar la secuencia de lanzamiento según sea necesario. También puedes controlar el proceso de las siguientes formas:

  • Puede modificar el tiempo de permanencia predeterminado de un grupo en una secuencia de lanzamiento, lo que resulta útil si las pruebas revelan que una versión específica requiere más o menos tiempo de permanencia. Este cambio en el tiempo de permanencia actualiza el tiempo de permanencia predeterminado de todas las implementaciones actuales y futuras (en cualquier versión) que se creen después de la modificación.
  • Para actualizar clústeres concretos, puede seguir usando las siguientes herramientas:
    • Controla manualmente las actualizaciones realizando acciones como cancelar, reanudar, revertir o completar las actualizaciones de grupos de nodos.
    • Usa las ventanas de mantenimiento y las exclusiones para decidir cuándo se puede actualizar un clúster y cuándo no.
    • Configura estrategias de actualización de nodos para equilibrar la velocidad y la tolerancia al riesgo, en función de las cargas de trabajo que se ejecuten en esos nodos.

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

Un administrador de plataforma de un banco comunitario gestiona tres entornos de implementación principales: pruebas, preproducción y producción. Los clústeres de producción se distribuyen en varias regiones con diferentes niveles de criticidad. Para gestionar las actualizaciones de forma eficaz, el administrador agrupa los clústeres de cada entorno en flotas. Como es necesario para la secuenciación del lanzamiento, cada clúster de las tres flotas está registrado en el mismo canal de lanzamiento (en este caso, el canal Regular) y todos los clústeres ejecutan la misma versión secundaria.

El objetivo principal del administrador es asegurarse de que las nuevas versiones de GKE se examinen a fondo antes de llegar al entorno de producción crítico del banco. También quieren actualizar progresivamente los clústeres de una región con menos tráfico, luego pasar a una región con más tráfico y, por último, a su región más importante. Para ello, usan la secuenciación de lanzamientos con fases personalizadas para definir una estrategia de actualización progresiva que incluya el etiquetado de los clústeres de producción según su región. Este enfoque les permite validar una nueva versión en un pequeño subconjunto del tráfico de producción antes de implementarla por completo.

Para implementar este plan, el administrador aplica las siguientes etiquetas a los clústeres de la flota de producción:

  • Los clústeres de us-west1 (menos tráfico) se etiquetan con prod-region: us-west1.
  • Los clústeres de europe-west1 (más tráfico) se etiquetan con prod-region: europe-west1.
  • Los clústeres de us-east1 (tráfico más crítico) no están etiquetados. La fase final de una flota dentro de una secuencia debe actuar como un contenedor para todos los clústeres restantes. Por lo tanto, el administrador no tiene que añadir etiquetas a los clústeres restantes.

A continuación, en un proyecto host específico que se usa para gestionar las configuraciones de CI/CD, definen un objeto RolloutSequence. Esta nueva secuencia tiene cinco fases distintas:

  1. Pruebas: esta fase incluye todos los clústeres de la flota testing. El administrador establece un tiempo de remojo de tres días para permitir una validación exhaustiva.
  2. Fase de pruebas: esta fase incluye todos los clústeres de la flota staging, con un tiempo de prueba de tres días.
  3. Producción en la región us-west1: esta fase se dirige a la flota de producción, pero usa un label-selector para incluir solo los clústeres con la etiqueta prod-region: us-west1. En esta fase, el administrador puede monitorizar si hay algún problema en un pequeño subconjunto de clústeres de producción durante tres días.
  4. Producción en la región europe-west1: esta fase incluye los clústeres de la flota production que tienen la etiqueta prod-region: europe-west1. El administrador establece un tiempo de permanencia de cuatro días para que la validación sea más exhaustiva.
  5. Producción en la región us-east1: esta fase final incluye los clústeres restantes de la flota production, es decir, todos los clústeres de us-east1.

Este enfoque ofrece al administrador un control granular sobre sus actualizaciones de producción, lo que mejora significativamente la seguridad y la fiabilidad del proceso de actualización, ya que permite detectar posibles problemas antes de que afecten a todo el entorno de producción.

Durante una actualización rutinaria de parches, las pruebas automatizadas del banco se completan correctamente en el entorno de staging mucho más rápido de lo previsto. El administrador observa que la nueva versión es estable y decide que el tiempo de prueba de tres días después de la actualización de la flota de Staging es innecesariamente largo para este tipo de actualización rutinaria.

Para acelerar este lanzamiento, el administrador modifica la RolloutSequencedefinición y reduce la duración de la fase de prueba de la us-west1flota de producción. Como este cambio en la definición de RolloutSequence actualiza el tiempo de permanencia predeterminado de todas las implementaciones actuales y futuras, el administrador anota que debe volver a establecer el periodo de permanencia original de tres días una vez que se haya completado esta implementación de parche específica. Este enfoque ayuda a asegurarse de que el tiempo de espera estándar, más prudente, se aplique a las futuras actualizaciones de versiones secundarias.

El administrador usa ventanas de mantenimiento y exclusiones para 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, de forma que GKE solo actualiza 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 picos y actualizaciones azul-verde para sus nodos, equilibrando la velocidad y la tolerancia al riesgo en función de las cargas de trabajo que se ejecuten en esos nodos.

Requisitos de lanzamiento

Para que una versión se implemente mediante una secuencia con fases personalizadas, los clústeres deben poder actualizarse a la versión de destino desde su canal de lanzamiento. Cuando hay disponible una nueva versión de GKE, el sistema crea un objeto Rollout si los clústeres de la secuencia cumplen los requisitos de la nueva versión. Aunque recomendamos que todos los clústeres estén registrados en el mismo canal de lanzamiento, si no es así, GKE selecciona una versión del canal más conservador de la secuencia. Por ejemplo, si los clústeres se mezclan entre los canales Estable y Regular, GKE elige la versión del canal Estable.

A continuación, el Rollout pasa por las fases definidas en su RolloutSequence. En una fase determinada, el lanzamiento del plano de control y el lanzamiento del grupo de nodos se pueden ejecutar en paralelo. Una regla clave que rige esta progresión es que, mientras una fase se encuentra en estado SOAKING con una versión concreta, no puede iniciar una nueva Rollout para una versión más reciente. Esta práctica ayuda a asegurarse de que una versión se valida por completo antes de que empiece la siguiente actualización. Para observar el progreso y la idoneidad de cada clúster, monitoriza el objeto Rollout. Si detectas discrepancias entre versiones que hacen que un clúster no cumpla los requisitos, es posible que tengas que tomar medidas, como actualizar el clúster manualmente, para que la secuencia pueda continuar. Si un clúster no cumple los requisitos para ninguna de las implementaciones, GKE no lo actualizará automáticamente hasta que la versión actual deje de tener asistencia.

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

Si una fase de la secuencia contiene clústeres que ejecutan una versión posterior a la versión de destino de un lanzamiento, GKE actualiza los clústeres aptos para la versión de destino e ignora los clústeres que ya tienen una versión posterior. Este comportamiento no impide que la secuencia de lanzamiento avance a la siguiente fase.

Por ejemplo, si la versión de destino de un lanzamiento de una fase es la 1.32 y esa fase tiene clústeres que ejecutan las versiones 1.31 y 1.33, GKE actualiza los clústeres de la versión 1.31 a la 1.32 e ignora los clústeres que ya están en la versión 1.33.

En la fase anterior se han calificado varios objetivos de actualización para la fase posterior

Una fase anterior de una secuencia puede completar los lanzamientos de varias versiones nuevas mientras que una fase posterior está en pausa (por ejemplo, por una exclusión de mantenimiento) o sigue procesando una actualización anterior. En este caso, cuando la fase posterior esté lista para aceptar una nueva actualización, GKE actualizará la fase a la última versión que se haya calificado. 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 de la fase siguiente. 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 de la fase posterior, pero no posterior.

Por ejemplo, este caso es pertinente si has configurado exclusiones de mantenimiento para evitar temporalmente las actualizaciones en tus clústeres de producción. Si tus clústeres de preproducción no tenían las mismas exclusiones de mantenimiento, es posible que estos clústeres se actualicen varias veces, lo que supondría varias versiones nuevas, pero tus fases de producción no se actualizarían.

Remojo forzado después de 30 días

Para asegurarse de que una secuencia de lanzamiento finalice 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 realizándose durante el periodo de prueba.

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

La secuenciación de lanzamientos funciona junto con otras funciones de actualización de GKE:

  • Ventanas de mantenimiento y exclusiones: puedes seguir usando ventanas de mantenimiento y exclusiones para controlar cuándo se pueden realizar las actualizaciones en tus clústeres. GKE inicia una actualización de clúster solo 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, esta circunstancia puede impedir que las actualizaciones del clúster finalicen en una fase. 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, la fase pasará a la fase de prueba de carga independientemente de si se han actualizado todos los clústeres. Los lanzamientos del plano de control y del grupo de nodos se pueden ejecutar en paralelo en una fase determinada.

  • Estrategias de actualización de nodos: la secuencia de lanzamiento no afecta a las estrategias de actualización de nodos configuradas (por ejemplo, las actualizaciones azul-verde). Al igual que las actualizaciones de clústeres que no tienen una secuencia de lanzamiento, 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. Este comportamiento puede producirse 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. La situación también puede empeorar si las ventanas de mantenimiento no son lo suficientemente grandes para que se complete la actualización de un nodo.

  • Canales de lanzamiento: te recomendamos que registres todos los clústeres de una secuencia de lanzamiento en el mismo canal de lanzamiento.

  • Detección del uso de funciones obsoletas: la detección del uso de funciones obsoletas de GKE sigue funcionando como se espera, lo que puede pausar las actualizaciones en los clústeres que usan una API obsoleta.

  • Actualizaciones manuales: actualizar manualmente los clústeres en la primera fase de una secuencia no implica que esa versión cumpla los requisitos ni que se active un lanzamiento para continuar. El proceso de lanzamiento automático se basa en los objetivos de actualización automática oficiales definidos para el canal de lanzamiento. Una actualización manual actualiza los clústeres, pero la secuencia empieza a avanzar para esa versión solo después de que se convierta en el destino de la actualización automática designada.

Recibir varias actualizaciones en una secuencia

Un canal de lanzamiento selecciona un destino de actualización para el clúster. Si hay una nueva versión disponible mientras se están llevando a cabo las actualizaciones a una versión anterior, la primera fase puede empezar a lanzar la nueva versión aunque las fases posteriores sigan recibiendo la actualización anterior. Por ejemplo, si el tercer grupo de una secuencia está implementando la versión 1.31.12-gke.1265000, el primer grupo de la secuencia puede implementar simultáneamente la versión 1.31.13-gke.1008000.

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, esta estrategia puede no ser 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.
  • 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

Se aplican las siguientes limitaciones cuando actualizas los clústeres mediante la secuenciación de lanzamientos con fases personalizadas:

  • No puedes usar la consola de Google Cloud para crear ni ver secuencias de lanzamiento con fases personalizadas.
  • Cuando una secuencia de lanzamiento haga referencia a una flota, debes incluir la flota completa. Esta restricción significa que, si define una fase para orientarla solo a un subconjunto de clústeres de una flota con un label-selector (por ejemplo, para una implementación gradual), también debe definir una fase de "recogida" posterior que incluya todos los clústeres restantes de esa misma flota. Esta fase comodín se dirige a la misma flota, pero no incluye un label-selector, por lo que incluye automáticamente todos los clústeres que no se hayan seleccionado en fases anteriores de la secuencia.
  • Si modificas una secuencia durante una implementación, en concreto los cambios que afecten a los clústeres participantes, GKE cancelará inmediatamente todas las implementaciones. Si solo modificas el tiempo de permanencia de una secuencia, GKE no cancelará el lanzamiento.
  • No puedes acelerar manualmente el lanzamiento activo de una versión específica. Si modificas la duración de la fase de prueba en la definición de la secuencia de lanzamiento, el cambio actualizará el tiempo de prueba predeterminado de todos los lanzamientos actuales y futuros que se creen después de la modificación.
  • GKE actualiza automáticamente los clústeres que han llegado al final de su ciclo de asistencia a una versión compatible, y es posible que esta actualización no siga la secuencia de lanzamiento definida.
  • Una fase puede hacer referencia a una flota como máximo. No puedes tener varias flotas en una sola fase.
  • Una flota solo se puede hacer referencia en una secuencia de lanzamiento. Dos secuencias de lanzamiento no pueden hacer referencia a la misma flota.

Problemas conocidos

En esta sección se describen los problemas conocidos de la secuenciación de lanzamientos con fases personalizadas.

  • Si una fase de tu secuencia de lanzamiento no contiene ningún clúster, se omitirá, pero el tiempo de permanencia definido para esa fase seguirá transcurriendo antes de que el lanzamiento pase a la siguiente fase.

Siguientes pasos