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 lanzamientos. Por ejemplo, puedes calificar una versión nueva en clústeres de preproducción antes de actualizar los clústeres de producción. GKE también proporciona una versión de la secuencia de lanzamientos que usa etapas personalizadas (versión preliminar) para brindarte un control más detallado sobre las actualizaciones de clústeres.

En este documento, se supone que conoces los siguientes temas:

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

Descripció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 todos los entornos, por ejemplo, primero actualizar los clústeres en el entorno de desarrollo, luego en el entorno de pruebas y, por último, en el de producción. Esta estrategia progresiva proporciona un tiempo de preparación 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 la implementación se basa en el concepto de flotas, que son agrupaciones lógicas de clústeres de GKE que se asignan a un entorno (por ejemplo, pruebas). Para usar esta función, debes definir una secuencia compuesta por flotas y establecer el tiempo de prueba entre cada grupo. Cuando GKE selecciona una versión nueva, 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 implemente 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 la secuenciación de lanzamientos sin habilitar todas las configuraciones y funciones a nivel de la flota. La membresía ligera es una buena opción si deseas usar la secuenciación de lanzamientos sin algunas de las otras implicaciones de la administración completa de la flota, como la igualdad del espacio de nombres a nivel de la flota. Para obtener más información, consulta Membresías básicas.

Elige una estrategia de secuenciación del lanzamiento

GKE ofrece dos versiones de la secuencia de lanzamiento. Ambas versiones se basan en los mismos principios fundamentales de actualizaciones progresivas basadas en flotas, pero ofrecen diferentes niveles de flexibilidad. En esta sección, se te ayudará a decidir qué versión es la mejor para tu caso de uso.

  • Secuencia de lanzamiento basada en flotas (DG): Esta versión es la estrategia recomendada para la mayoría de los casos de uso de producción. La secuenciación de lanzamiento basada en flotas proporciona un método estable y compatible para lanzar actualizaciones de forma progresiva en todos los entornos (como los de prueba, los de etapa de pruebas y los de producción), y usa una secuencia lineal de flotas.

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

Secuencia de lanzamiento basada en la flota

Para actualizar de forma automática los clústeres con secuencia de lanzamiento, usa flotas en las que agrupaste los clústeres con el mismo canal de versiones y la misma versión secundaria en etapas de implementación. Define la secuencia de flotas y el tiempo de prueba que 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.

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 en la que agrupas clústeres en flotas.
Figura: Una secuencia de lanzamiento basada en la flota

Con una secuencia basada en la flota, cuando GKE pone a disposición un nuevo objetivo de actualización en el canal de versiones en el que están inscritos todos los clústeres de esta secuencia, GKE actualiza estas flotas de clústeres en esta secuencia, y los clústeres de la flota ascendente califican la nueva versión para los clústeres de la flota descendente, hasta un máximo de cinco 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, puedes confirmar que tus cargas de trabajo se ejecuten como se espera en los clústeres actualizados.

Secuencia de lanzamiento con etapas personalizadas

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

  • Define una secuencia con etapas detalladas que pueden segmentar subconjuntos específicos de clústeres dentro de una flota con etiquetas, lo que la convierte en una buena opción para estrategias como los lanzamientos por fases.
  • Obtén más control y observabilidad a través de los nuevos objetos de API RolloutSequence y Rollout.

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

En el siguiente diagrama, se ilustra cómo GKE actualiza automáticamente los clústeres en una secuencia de lanzamiento que usa etapas personalizadas. La etapa segmenta los clústeres con un label-selector llamado canary en la flota de prod:

Secuencia de lanzamiento con etapas personalizadas en GKE.
Figura: Una secuencia de lanzamiento con etapas personalizadas

Cuando un nuevo objetivo de actualización está disponible en el canal de versiones en el que están inscritos todos los clústeres de esta secuencia, GKE actualiza primero los clústeres de la flota de pruebas y, luego, los clústeres de la flota de etapa de pruebas. Luego, en la flota de producción, GKE prioriza los clústeres que coinciden con label-selector. Como prod-cluster-1 está etiquetado con canary: true, GKE actualizará este clúster a continuación. GKE actualiza todos los clústeres restantes en la flota de producción (en la etapa principal) al final del proceso, ya que esta etapa no tiene ningún selector de etiquetas.

Durante el tiempo de prueba configurado entre las etapas, puedes confirmar que tus cargas de trabajo se ejecuten como se espera en los clústeres actualizados. En el ejemplo anterior, se muestra una etapa personalizada en la flota de producción, pero puedes agregar varias etapas a cualquier flota o usar solo una flota con varias etapas.

Para obtener más información sobre la secuencia de lanzamiento con etapas personalizadas, consulta Acerca de la secuencia de lanzamiento con etapas personalizadas.

El resto de este documento se relaciona solo con la secuenciación del lanzamiento basada en flotas.

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) de clústeres. También debes especificar un tiempo de prueba que defina 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 nuevo objetivo de actualización automática para los clústeres en una versión secundaria en un canal de versiones específico, con una nota de la versión 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 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. Después de que finalizan todas las actualizaciones del plano de control del clúster en el primer grupo, GKE comienza el período de prueba para las actualizaciones del plano de control. GKE también comienza el período de prueba si transcurrieron más de 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 del primer grupo, GKE comienza a actualizar los planos de control del segundo grupo a la versión nueva. Sin embargo, ten en cuenta las siguientes consideraciones:

      • En algunos casos, GKE podría 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 produce esta situación, GKE elige la versión más reciente que también tiene los siguientes atributos:
        • La versión está calificada 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 tienen una versión posterior a la versión objetivo de actualización automática que calificó el primer grupo.

  4. En paralelo a las actualizaciones del plano de control, GKE sigue los siguientes pasos para las actualizaciones de nodos:

    1. Una vez que finalizan todas las actualizaciones de nodos de los clústeres en el primer grupo, GKE comienza el período de prueba para las actualizaciones de nodos. GKE también comienza el período de prueba si transcurrieron más de 30 días desde que comenzaron las actualizaciones de nodos.
    2. Una vez que se completa el período de prueba para las actualizaciones de nodos del primer grupo, GKE comienza a actualizar los nodos del segundo grupo a la nueva versión. Sin embargo, ten en cuenta las siguientes consideraciones:
      • 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 produce esta situación, GKE elige la versión más reciente que también tiene los siguientes atributos:
        • La versión está calificada 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 tienen una versión posterior a la versión de destino de actualización automática calificada por 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.

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

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.

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 y administrar la secuencia de lanzamiento según sea necesario. También puedes controlar el proceso de las siguientes maneras:

  • Para actualizaciones de clústeres individuales, puedes seguir usando las siguientes herramientas:
    • Controlar las actualizaciones de forma manual realizando acciones como cancelar, reanudar, revertir o completar las actualizaciones del grupo de nodos
    • Usa períodos de mantenimiento y 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, según las cargas de trabajo que se ejecutan en esos nodos.

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 comunitario administra tres entornos de implementación principales: pruebas, almacenamiento en etapa intermedia y producción. Cada entorno tiene un grupo de clústeres organizados en una flota. 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 las flotas para verificar que sus cargas de trabajo se ejecuten como se espera en la versión nueva de GKE. Para la flota de pruebas, el administrador establece el tiempo de prueba en 14 días para tener 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 absorción predeterminado para las actualizaciones a versiones específicas, lo que podría ser útil en una de las siguientes situaciones:

  • El administrador termina de calificar la versión antes de que se complete el tiempo de prueba y quiere 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 las exclusiones y los períodos de mantenimiento para permitir que GKE actualice los clústeres cuando sea menos perjudicial para el banco. GKE respeta la disponibilidad de mantenimiento para los clústeres actualizados en una secuencia de lanzamiento.

  • El administrador configuró períodos de mantenimiento para sus clústeres, de modo que GKE solo los actualiza 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.

Elegibilidad para el lanzamiento basada en la flota

Para que los clústeres se actualicen de forma automática con la secuenciación de implementación, todos los clústeres de todas las flotas 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 destino de actualización apto, GKE no actualizará automáticamente el clúster hasta que la versión secundaria existente del clúster llegue al final de la compatibilidad.

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 2025-R45 estableció un objetivo de actualización para varias versiones secundarias en clústeres inscritos en el canal regular. Un objetivo de actualización puede ser una versión secundaria nueva (1.30 a 1.31) o solo una versión de parche nueva (1.31.x-gke.x a 1.31.13-gke.1023000). 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.30 se actualizaron a 1.31.13-gke.1023000.
  • Los clústeres en 1.31 se actualizaron a 1.32.9-gke.1108000.
  • Los clústeres en 1.32 se actualizaron a 1.33.5-gke.1162000.

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 ejecutaban la versión 1.30, esos clústeres 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, 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

Para que los clústeres de cualquier grupo downstream comiencen a actualizarse, el grupo upstream debe haber calificado correctamente un objetivo de actualización único y común para el que todos los clústeres del grupo downstream sean aptos. Si el grupo upstream tiene clústeres que se actualizaron correctamente a dos versiones diferentes (como puede suceder cuando el grupo upstream es el primer grupo de una secuencia), el grupo upstream califica la versión inferior de las dos como el objetivo de actualización común para el grupo downstream. Por ejemplo, si el grupo upstream tiene algunos clústeres que se actualizaron a la versión 1.31.13-gke.1023000 y otros clústeres que se actualizaron a la versión 1.33.5-gke.1162000, el grupo califica la versión 1.31.13-gke.1023000 como el objetivo de actualización común para el grupo downstream.

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

Si un grupo downstream tiene clústeres que ejecutan una versión posterior a la versión objetivo de actualización calificada por un grupo upstream, GKE actualiza los clústeres aptos para la versión objetivo de actualización y omite los clústeres que ya están en una versión posterior. Este comportamiento no impide que avance la secuencia de lanzamiento, siempre y cuando al menos un clúster del grupo downstream sea apto para el objetivo de actualización.

Por ejemplo, si el grupo upstream calificó la actualización a la versión 1.32 y el grupo downstream tiene clústeres que ejecutan las versiones 1.31 y 1.33, GKE actualiza los clústeres que ejecutan la versión 1.31 a la versión 1.32 y, luego, ignora los clústeres que ejecutan la versión 1.33.

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.31.13-gke.1023000, pero los clústeres del segundo grupo ejecutaron una versión más reciente, como la 1.32.9-gke.1108000, los clústeres del segundo grupo no se actualizarán de forma automática. El primer grupo calificó 1.31.13-gke.1023000, pero los clústeres del segundo grupo (actualmente en 1.32) solo son aptos para el objetivo de actualización 1.33.5-gke.1162000, por lo que GKE no puede actualizar estos clústeres de forma automática. Para avanzar con las actualizaciones en esta situación, consulta Cómo solucionar la elegibilidad entre grupos.

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

Si GKE actualizó 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 calificada por el grupo upstream para la que los clústeres del grupo downstream son aptos. 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 en el grupo downstream, pero no posterior.

Por ejemplo, esta situación es pertinente si configuraste exclusiones de mantenimiento para impedir temporalmente las actualizaciones de tu grupo de nivel inferior, que incluye tus clústeres de producción. Sin embargo, tu grupo upstream, que incluye clústeres de preproducción, tampoco usó exclusiones de mantenimiento para evitar las actualizaciones. Por lo tanto, tu grupo upstream se actualizó varias veces, lo que calificó varios objetivos de actualización potenciales, mientras que tu grupo downstream no se actualizó.

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

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

Cómo funciona la secuenciación de lanzamiento basada en flotas 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 basada en flotas 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, esta circunstancia 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 basada en flotas 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 entrará en su fase de prueba, sin importar si todos los clústeres terminaron de actualizarse. Este comportamiento puede ocurrir 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.

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.31.12-gke.1265000, el primer grupo en la secuencia puede lanzar 1.31.13-gke.1008000 de forma simultánea.

Consideraciones para elegir la secuencia de lanzamiento basada en la flota

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 estrategia 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 cinco etapas de implementación, ya que solo puedes crear una secuencia de lanzamiento con hasta cinco grupos de clústeres. No puedes vincular grupos en varias secuencias de lanzamiento para crear una secuencia con más de cinco grupos. Las secuencias basadas en flotas pueden incluir hasta cinco 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.

Limitaciones de la secuencia de lanzamiento basada en la flota

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

  • Asegúrate de que todos los clústeres de una secuencia de lanzamiento estén inscritos en el mismo canal de versiones. También recomendamos que todos los clústeres ejecuten la misma versión secundaria para calificar un objetivo de actualización. Para obtener más información, consulta Elegibilidad para el lanzamiento.
  • 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 una secuencia de lanzamiento entre clústeres de la misma organización. No puedes crear secuencias con clústeres en varias organizaciones.

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

  • 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 upstream, todas las actualizaciones de clúster pendientes ingresan al estado COMPLETE y se propagan al grupo downstream.

¿Qué sigue?