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. GKE también ofrece una versión de secuenciación de lanzamientos que usa fases personalizadas (vista previa) para que tengas un control más granular sobre las actualizaciones de los clústeres.

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 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 lanzamientos con fases personalizadas (vista previa): esta versión es una evolución del modelo basado en flotas, que ofrece un control y una flexibilidad más detallados. 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 implementar 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 las últimas funciones de secuenciación de lanzamientos.

Secuencia de lanzamiento basada en flotas

Para actualizar automáticamente los clústeres con una secuencia de lanzamiento, usa flotas en las que hayas agrupado tus clústeres con el mismo canal de lanzamiento y la misma versión secundaria en fases de implementación. Define la secuencia de flotas y el tiempo de permanencia que quieras 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.

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 en la que se agrupan los clústeres en flotas.
Imagen: Secuencia de lanzamiento basada en la flota

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 cinco flotas). En una secuencia de lanzamiento, "upstream" hace referencia al grupo anterior y "downstream" al siguiente.

Durante el tiempo de permanencia configurado entre las flotas, puedes confirmar que tus cargas de trabajo se ejecutan correctamente en los clústeres actualizados.

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.

Para obtener más información sobre la secuenciación de lanzamientos con fases personalizadas, consulta el artículo Acerca de la secuenciación de lanzamientos con fases personalizadas.

El resto de este documento solo se aplica a la secuenciación de lanzamientos basada en flotas.

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:

  • 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

Por ejemplo, el administrador de la plataforma de un banco comunitario gestiona tres entornos de implementación principales: pruebas, staging y producción. Cada entorno tiene un grupo de clústeres organizados en una flota. Tal como se requiere para la secuenciación de la implementación, el administrador ha registrado cada clúster de las tres flotas en el mismo canal de lanzamiento (en estas flotas, el canal Regular), con todos los clústeres ejecutando 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 rodaje entre las flotas para verificar que sus cargas de trabajo se ejecutan correctamente en 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 lo tanto, establece el tiempo de permanencia en el máximo de 30 días.

El administrador usa ventanas de mantenimiento y exclusiones para permitir 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, y equilibra la velocidad y la tolerancia al riesgo en función de las cargas de trabajo que se ejecuten en esos nodos.

Requisitos para el lanzamiento basado en flotas

Para que los clústeres se actualicen automáticamente con la secuenciación de lanzamientos, todos los clústeres de todas las flotas 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 2025-R45 estableció un destino de actualización para varias versiones secundarias en clústeres registrados en el canal Regular. El destino de una actualización puede ser una versión secundaria nueva (de 1.30 a 1.31) o una versión de parche nueva (de 1.31.x-gke.x a 1.31.13-gke.1023000). 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 la versión 1.30 se han actualizado a la 1.31.13-gke.1023000.
  • Los clústeres de la versión 1.31 se han actualizado a la versión 1.32.9-gke.1108000.
  • Los clústeres de la versión 1.32 se han actualizado a la versión 1.33.5-gke.1162000.

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.30, se podrían actualizar a la versión 1.31.13-gke.1023000, y los clústeres que ejecutaban la versión 1.32 se podrían actualizar a la versión 1.33.5-gke.1162000. 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

Para que los clústeres de un grupo de nivel inferior puedan empezar a actualizarse, el grupo de nivel superior debe haber determinado correctamente un único objetivo de actualización común para el que sean aptos todos los clústeres del grupo de nivel inferior. Si el grupo de origen tiene clústeres que se han actualizado correctamente a dos versiones diferentes (como puede ocurrir cuando el grupo de origen es el primero de una secuencia), el grupo de origen califica la versión inferior de las dos como el objetivo de actualización común para el grupo de destino. Por ejemplo, si el grupo upstream tiene algunos clústeres que se han actualizado a la versión 1.31.13-gke.1023000 y otros clústeres que se han actualizado a la versión 1.33.5-gke.1162000, el grupo upstream podrá usar la versión 1.31.13-gke.1023000 como versión de actualización común para el grupo downstream.

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. Este comportamiento 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 aprobado la actualización a la versión 1.32 y el grupo downstream tiene clústeres con las versiones 1.31 y 1.33, GKE actualizará los clústeres con la versión 1.31 a la 1.32 e ignorará los clústeres con la versión 1.33.

Un grupo anterior 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.31.13-gke.1023000, pero los clústeres del segundo grupo ejecutaban una versión más reciente, como la 1.32.9-gke.1108000, los clústeres del segundo grupo no se actualizarían automáticamente. El primer grupo se ha calificado para la versión 1.31.13-gke.1023000, pero los clústeres del segundo grupo (actualmente en la versión 1.32) solo pueden actualizarse a la versión 1.33.5-gke.1162000, 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 origen se ha actualizado varias veces, lo que ha permitido identificar varios posibles destinos de actualización, mientras que tu grupo de destino 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 basada en la flota 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 basada en flotas 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, esta circunstancia 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 basada en flotas 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 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 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. 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. También puede empeorar si las ventanas de mantenimiento no son lo suficientemente grandes para que se complete la actualización de un nodo.

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.31.12-gke.1265000, el primer grupo de la secuencia puede estar implementando simultáneamente la versión 1.31.13-gke.1008000.

Consideraciones al elegir la secuencia de lanzamiento basada en flotas

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.
  • 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.
  • 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 de la secuenciación de lanzamientos basada en flotas

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 recomendamos 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.
  • 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 una secuencia de lanzamiento entre clústeres de la misma organización. No puedes crear secuencias con clústeres de varias organizaciones.

Problemas conocidos con la secuenciación de lanzamientos basada en flotas

  • 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 este comportamiento se produzca 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 las 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.

Siguientes pasos