Acerca de la secuenciación de lanzamiento con etapas personalizadas

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 con disponibilidad general de la secuencia de lanzamiento que usa un modelo más lineal sin etapas personalizadas.

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 de disponibilidad general y 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 con 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 lanzamientos más recientes.

El resto de este documento se relaciona solo con la secuenciación de lanzamientos con etapas personalizadas.

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.

Conceptos clave

  • Tiempo de estabilización: Este período es un tiempo de espera configurable que se produce después de que se actualizan todos los clústeres en una etapa. Este tiempo de espera te permite validar la nueva versión en un entorno y detectar posibles problemas antes de que la actualización continúe con el siguiente entorno. Puedes configurar un tiempo de permanencia de hasta 30 días para cada etapa de tu secuencia. Un tiempo de prueba más prolongado en una etapa previa a la producción te brinda más tiempo para la validación.
  • RolloutSequence: Este es el recurso principal que usas para definir tu secuencia de actualización. RolloutSequence contiene una serie ordenada de etapas, que verifica que los clústeres en etapas anteriores se hayan actualizado por completo y hayan completado su período de prueba antes de que la actualización avance a la siguiente etapa.
  • Rollout: Este objeto te permite observar el progreso de una sola actualización de versión a lo largo de tu secuencia. Puedes usar Rollout para ver el estado del lanzamiento, hacer un seguimiento del progreso y ver si algún clúster no es apto para la actualización y por qué.
  • Proyecto host dedicado: Te recomendamos que uses un proyecto Google Clouddedicado para alojar tus objetosRolloutSequence. Colocar la secuencia en un proyecto dedicado proporciona un punto de control central y neutral para tus secuencias de lanzamiento, lo que constituye una práctica recomendada similar para administrar las canalizaciones de CI/CD.
Práctica recomendada:

Crea y administra tus recursos de RolloutSequence en un proyecto host dedicado.

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

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:

  • Puedes modificar el tiempo de prueba predeterminado de un grupo dentro de 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 prueba. Este cambio en el tiempo de remojo actualiza el tiempo de remojo predeterminado para todos los lanzamientos actuales y futuros (a cualquier versión) que se creen después de la modificación.
  • 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

El administrador de la plataforma de un banco comunitario administra tres entornos de implementación principales: pruebas, almacenamiento en etapa intermedia y producción. Los clústeres de producción se distribuyen en varias regiones, con diferentes niveles de criticidad. Para administrar las actualizaciones de manera eficaz, el administrador agrupa los clústeres de cada entorno en flotas. Según se requiere para la secuenciación de lanzamiento, cada clúster de las tres flotas está inscrito en el mismo canal de versiones (en este caso, el canal regular) y todos los clústeres ejecutan la misma versión secundaria.

El objetivo principal del administrador es garantizar que las versiones nuevas de GKE se verifiquen exhaustivamente antes de llegar al entorno de producción crítico del banco. También quieren actualizar los clústeres de forma progresiva en una región con menos tráfico primero, luego pasar a una región con más tráfico y, finalmente, a su región más crítica. Para lograrlo, usan la secuenciación de lanzamiento con etapas personalizadas para definir una estrategia de actualización progresiva que incluye 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 un lanzamiento completo.

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

  • Los clústeres en us-west1 (tráfico más bajo) se etiquetan con prod-region: us-west1.
  • Los clústeres en europe-west1 (mayor tráfico) se etiquetan con prod-region: europe-west1.
  • Los clústeres en us-east1 (el tráfico más crítico) no están etiquetados. La etapa final de una flota dentro de una secuencia debe actuar como un "catch-all" para todos los clústeres restantes. Por lo tanto, el administrador no necesita agregar etiquetas a estos clústeres restantes.

A continuación, en un proyecto host dedicado que se usa para administrar las configuraciones de CI/CD, definen un objeto RolloutSequence. Esta nueva secuencia tiene cinco etapas distintas:

  1. Pruebas: Esta etapa incluye todos los clústeres de la flota testing. El administrador establece un tiempo de espera de tres días para permitir una validación exhaustiva.
  2. Etapa de pruebas: Esta etapa incluye todos los clústeres de la flota de staging, con un tiempo de prueba de tres días.
  3. Producción en la región us-west1: Esta etapa 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. Esta etapa permite que el administrador supervise si hay problemas en un pequeño subconjunto de clústeres de producción con un tiempo de prueba de tres días.
  4. Producción en la región europe-west1: Esta etapa incluye los clústeres de la flota production que tienen la etiqueta prod-region: europe-west1. El administrador establece un tiempo de prueba más largo de cuatro días para una validación más exhaustiva.
  5. Producción en la región us-east1: Esta etapa final incluye los clústeres restantes de la flota de production, es decir, todos los clústeres de us-east1.

Este enfoque le brinda al administrador un control detallado sobre las actualizaciones de producción, lo que mejora significativamente la seguridad y la confiabilidad del proceso de actualización, ya que detecta posibles problemas antes de que puedan afectar todo el entorno de producción.

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

Para acelerar este lanzamiento, el administrador modifica la definición de RolloutSequence y reduce la duración de la etapa de prueba de la flota de producción us-west1. Como este cambio en la definición de RolloutSequence actualiza el tiempo de permanencia predeterminado para todos los lanzamientos actuales y futuros, el administrador toma nota para revertir el tiempo de permanencia al período original de tres días después de que se complete el lanzamiento de este parche específico. Este enfoque ayuda a garantizar que el tiempo de prueba estándar y más cauteloso esté vigente para las futuras actualizaciones de versiones secundarias.

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

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

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

Elegibilidad para el lanzamiento

Para que una versión se lance a través de una secuencia con etapas personalizadas, los clústeres deben ser aptos para un destino de actualización desde su canal de versiones. Cuando hay una nueva versión de GKE disponible, el sistema crea un objeto Rollout si los clústeres de la secuencia son aptos para la nueva versión. Aunque recomendamos que todos los clústeres se inscriban en el mismo canal de versiones, 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.

Luego, el Rollout avanza por las etapas definidas en tu RolloutSequence. Dentro de una etapa determinada, la implementación del plano de control y la implementación del grupo de nodos pueden ejecutarse en paralelo. Una regla clave que rige esta progresión es que, mientras una etapa se encuentra en un estado SOAKING con una versión en particular, no es apta para comenzar un nuevo Rollout para una versión más reciente. Esta práctica ayuda a garantizar que una versión se valide por completo antes de que comience la siguiente actualización. Puedes observar el progreso y la elegibilidad de cada clúster supervisando el objeto Rollout. Si encuentras discrepancias de versión que hacen que un clúster no sea apto, es posible que debas tomar medidas, como actualizar el clúster de forma manual, para permitir que continúe la secuencia. Si un clúster no es apto para ningún lanzamiento, GKE no actualizará automáticamente el clúster hasta que la versión actual llegue al final de la asistencia.

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

Si una etapa 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 y omite los clústeres que ya están en una versión posterior. Este comportamiento no impide que la secuencia de lanzamiento avance a la siguiente etapa.

Por ejemplo, si la versión de destino de un lanzamiento para una etapa es 1.32 y esa etapa 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 y, luego, ignora los clústeres que ya están en la versión 1.33.

La etapa anterior calificó varios objetivos de actualización para la etapa posterior.

Una etapa anterior en una secuencia podría completar lanzamientos para varias versiones nuevas, mientras que una etapa posterior está en pausa (por ejemplo, por una exclusión de mantenimiento) o aún está procesando una actualización anterior. En este caso, cuando la etapa posterior está lista para aceptar una nueva actualización, GKE actualiza la etapa a la versión más reciente que se calificó. 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 en la etapa posterior. 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 la etapa posterior, pero no posterior a ella.

Por ejemplo, este caso es pertinente si configuraste exclusiones de mantenimiento para impedir 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 calificaría varias versiones nuevas, pero tus etapas de producción no se actualizarían.

En espera forzosa después de 30 días

Para ayudar a garantizar que una secuencia de lanzamiento finalice la actualización de los clústeres, GKE inicia el período de prueba para 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.

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

La secuenciación de lanzamiento funciona en conjunto con otras funciones de actualización de GKE:

  • Períodos de mantenimiento y exclusiones: Aún puedes usar períodos de mantenimiento y exclusiones para controlar cuándo pueden ocurrir las actualizaciones en tus clústeres y cuándo no. 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 una etapa. 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, la etapa ingresará a su fase de prueba, sin importar si todos los clústeres terminaron de actualizarse. Las implementaciones del plano de control y del grupo de nodos se pueden ejecutar en paralelo dentro de una etapa determinada.

  • Estrategias de actualización de nodos: La secuenciación de lanzamiento no afecta las estrategias de actualización de nodos configuradas (por ejemplo, las actualizaciones azul-verde). Al igual que con las actualizaciones de clústeres que no tienen 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. La situación también puede verse agravada por los períodos de mantenimiento que no son lo suficientemente extensos como para que una actualización de nodos se complete.

  • Canales de versiones: Te recomendamos que inscribas todos los clústeres de una secuencia de lanzamiento en el mismo canal de versiones.

  • Detección del uso de la baja: La detección del uso de la baja de GKE sigue funcionando según lo previsto, y es posible que pause las actualizaciones en los clústeres que usan una API obsoleta.

  • Actualizaciones manuales: Actualizar clústeres de forma manual en la primera etapa de una secuencia no califica esa versión ni activa un lanzamiento para continuar. El proceso de lanzamiento automatizado se basa en los destinos de actualización automática oficiales establecidos para el canal de versiones. Una actualización manual actualiza los clústeres, pero la secuencia comienza a avanzar para esa versión solo después de que se convierte en el destino designado de la actualización automática.

Recibe varias actualizaciones en una secuencia

Un canal de versiones selecciona un destino de actualización para el clúster. Si una versión nueva está disponible mientras las actualizaciones a un objetivo anterior aún están en curso, la primera etapa puede comenzar el lanzamiento de una versión nueva incluso cuando las etapas posteriores aún reciban la actualización anterior. Por ejemplo, si el tercer grupo de una secuencia lanza la versión 1.31.12-gke.1265000, el primer grupo de la secuencia puede lanzar la versión 1.31.13-gke.1008000 de forma simultánea.

Consideraciones para elegir la secuencia de lanzamiento

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

Sin embargo, es posible que esta 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.
  • 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

Se aplican las siguientes limitaciones cuando actualizas tus clústeres con la secuencia de lanzamiento con etapas personalizadas:

  • No puedes usar la consola de Google Cloud para crear o ver secuencias de lanzamiento con etapas personalizadas.
  • Cuando una secuencia de lanzamiento hace referencia a una flota, debes incluir la flota completa. Esta restricción significa que, si defines una etapa para segmentar solo un subconjunto de clústeres de una flota con un label-selector (por ejemplo, para una implementación por fases), también debes definir una etapa posterior de "captación general" que incluya todos los clústeres restantes de esa misma flota. Esta etapa general se segmenta para la misma flota, pero no incluye un label-selector, por lo que incluye automáticamente todos los clústeres que no se seleccionaron en etapas anteriores de la secuencia.
  • Si modificas una secuencia durante un lanzamiento, en especial los cambios que afectan a los clústeres participantes, GKE cancela de inmediato todos los lanzamientos existentes. Si solo modificas el tiempo de estabilización de una secuencia, GKE no cancelará el lanzamiento.
  • No puedes acelerar manualmente el lanzamiento activo de una versión específica. Cuando modificas la duración de la fase de estabilización en la definición de la secuencia de lanzamiento, el cambio actualiza el tiempo de estabilización predeterminado para todos los lanzamientos actuales y futuros que se creen después de la modificación.
  • GKE actualiza automáticamente los clústeres que alcanzaron el final de la asistencia a una versión compatible, y es posible que esta actualización no siga la secuencia de lanzamiento definida.
  • Una etapa puede hacer referencia a un máximo de una flota. No puedes tener varias flotas en una sola etapa.
  • Solo se puede hacer referencia a una flota 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 relacionados con la secuenciación de la implementación con etapas personalizadas.

  • Si una etapa de la secuencia de lanzamiento no contiene clústeres, se omite, pero el tiempo de permanencia definido para esa etapa sigue transcurriendo antes de que el lanzamiento avance a la siguiente etapa.

¿Qué sigue?