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 lanzamiento. 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 anterior de esta función, la secuencia de lanzamiento basada en flotas, que tiene una funcionalidad más limitada y no se recomienda para entornos nuevos.

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

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

Descripción general

La secuenciación de lanzamiento de GKE te permite definir una secuencia específica y ordenada para las actualizaciones de clústeres en todos los entornos, como actualizar primero los clústeres en el entorno de desarrollo, luego el entorno de pruebas y, por último, el de producción. Esta estrategia progresiva proporciona un tiempo de prueba 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 que se asignan a un entorno (por ejemplo, pruebas). Para usar esta función, define una secuencia compuesta por flotas y establece 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 lanzamiento sin algunas de las otras implicaciones de la administración completa de la flota, como la igualdad de espacios de nombres a nivel de la flota. Para obtener más información, consulta Membresías livianas.

Elige una estrategia de secuenciación de lanzamiento

GKE ofrece dos versiones de la secuencia de lanzamiento. Ambas versiones se basan en los mismos principios básicos de las actualizaciones progresivas basadas en flotas, pero recomendamos usar la secuenciación de lanzamiento con etapas personalizadas para entornos nuevos:

  • Secuenciación de lanzamiento con etapas personalizadas (recomendada para entornos nuevos): Esta versión es una evolución del modelo basado en flotas, que ofrece un control y una flexibilidad más detallados, pero carece de compatibilidad integral con la consola de Cloud de Confiance . Con las etapas personalizadas, puedes definir etapas específicas dentro de una flota con etiquetas, lo que la 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. Además, tienes más control sobre los lanzamientos, como iniciar un lanzamiento a una versión específica, elegir los tipos de actualizaciones que se lanzarán en una secuencia y pausar o cancelar los lanzamientos. Elige esta opción si estás creando una secuencia de lanzamiento por primera vez.
  • Secuencia de lanzamiento basada en flotas: Esta versión de la función tiene una compatibilidad más completa en la consola de Cloud de Confiance , pero, de lo contrario, tiene una funcionalidad más limitada y no se recomienda si creas una secuencia de lanzamiento por primera vez.

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

Secuenciación de lanzamiento con etapas personalizadas

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

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

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

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

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

Cuando GKE lanza una versión nueva, actualiza primero los clústeres de la flota de pruebas y, luego, los de la flota de etapa de pruebas. Luego, en la flota de producción, GKE prioriza los clústeres que coinciden con el label-selector. Como prod-cluster-1 tiene la etiqueta canary: true, GKE actualiza este clúster a continuación. GKE actualiza todos los clústeres restantes de 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 prueba: Es un período de espera configurable que se produce después de que se actualizan todos los clústeres de una etapa. Este tiempo de prueba te permite validar la versión nueva en un entorno y detectar posibles problemas antes de que la actualización continúe en el siguiente entorno. Puedes configurar un tiempo de prueba de hasta 30 días para cada etapa de la secuencia. Un tiempo de prueba más largo en una etapa de preproducción te da más tiempo para la validación.
  • RolloutSequence: Este objeto 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 de las etapas anteriores se actualicen por completo y hayan completado su período de prueba antes de que la actualización continúe con la siguiente etapa. Cada RolloutSequence tiene un Rollout para cada versión nueva que se lanza.
  • Rollout: Este objeto te permite observar el progreso de una actualización de versión única a través de tu secuencia. Puedes usar Rollout para ver el estado del lanzamiento, hacer un seguimiento del progreso y ver si hay clústeres que no son aptos para la actualización y por qué. Cada Rollout se asocia con un RolloutSequence específico que representa la secuencia en la que se lanza la versión.
  • Proyecto host dedicado: Te recomendamos que uses un proyecto deCloud de Confiance by S3NS dedicado para alojar tus objetos de RolloutSequence. Colocar la secuencia en un proyecto dedicado proporciona un punto de control neutral y central para tus secuencias de lanzamiento, lo que es una práctica recomendada similar para administrar 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 forma principal de agrupar clústeres. Una etapa en una secuencia de lanzamiento puede hacer referencia a una o más flotas. Una sola secuencia de lanzamiento puede incluir flotas alojadas en varias organizaciones deCloud de Confiance by S3NS .
  • 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 cuánto tiempo se detiene GKE 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 inicia un nuevo lanzamiento en la secuencia de lanzamiento. De forma predeterminada, se inicia un lanzamiento cuando GKE establece un nuevo destino de actualización automática para los clústeres en una versión secundaria en un canal de versiones específico. Para la secuenciación de lanzamientos con etapas personalizadas, también puedes activar un lanzamiento nuevo en una secuencia de lanzamiento a una versión específica que elijas.

  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 sigue los pasos que se indican a continuación para actualizar el 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 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 produce esta situación, GKE elige la versión más reciente que también tenga los siguientes atributos:
        • El primer grupo califica la versión.
        • 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 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. Después de que finalizan todas las actualizaciones de los nodos de los clústeres en el primer grupo, GKE comienza el período de prueba para las actualizaciones de los nodos. GKE también comienza el período de prueba si transcurrieron más de 30 días desde que comenzaron las actualizaciones de los nodos.
    2. Una vez que se completa el período de prueba para las actualizaciones de los nodos del primer grupo, GKE comienza a actualizar los nodos del segundo grupo a la versión nueva. 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 tenga los siguientes atributos:
        • El primer grupo califica la versión.
        • 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 que calificó 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 a la versión nueva.

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. Para obtener más información sobre cómo controlar este proceso, consulta los siguientes recursos:

Ejemplo: El banco comunitario lanza de forma gradual los cambios de las pruebas a la producción

Un administrador de la plataforma en un banco comunitario administra tres entornos de implementación principales: pruebas, etapa de pruebas y producción. Los clústeres de producción se distribuyen en varias regiones, con diferentes niveles de importancia. Para administrar las actualizaciones de manera eficaz, el administrador agrupa los clústeres de cada entorno en flotas. Según sea necesario para la secuenciación de lanzamiento, cada clúster de las tres flotas se inscribe 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 nuevas versiones de GKE se revisen de forma exhaustiva antes de llegar al entorno de producción crítico del banco. También quieren actualizar de forma progresiva los clústeres en una región con menos tráfico primero, luego pasar a una región con más tráfico y, por último, 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 incluya etiquetar los clústeres de producción según su región. Este enfoque les permite validar una versión nueva en un pequeño subconjunto de 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 (tráfico más alto) se etiquetan con prod-region: europe-west1.
  • Los clústeres en us-east1 (tráfico más crítico) no están etiquetados. La etapa final de una flota dentro de una secuencia debe actuar como un "comodín" para todos los clústeres restantes. Por lo tanto, el administrador no necesita agregar etiquetas a estos clústeres restantes.

Luego, en un proyecto host dedicado que se usa para administrar 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 prueba de tres días para permitir una validación exhaustiva.
  2. Etapa de pruebas: Esta etapa incluye todos los clústeres de la flota staging, con un tiempo de prueba de tres días.
  3. Producción en la región us-west1: Esta etapa se orienta 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 cualquier problema 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 production, es decir, todos los clústeres de us-east1.

Este enfoque le brinda al administrador un control detallado sobre sus actualizaciones de producción, lo que mejora de forma significativa la seguridad y confiabilidad de su proceso de actualización, ya que detecta posibles problemas antes de que puedan afectar a 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 etapa de pruebas es innecesariamente largo para este tipo de actualización rutinaria.

Para acelerar este lanzamiento, el administrador modifica la definición de RolloutSequence y reduce la duración de la prueba de esfuerzo para la etapa us-west1 de la flota de producción. Debido a que este cambio en la definición de RolloutSequence actualiza el tiempo de prueba predeterminado para todos los lanzamientos actuales y futuros, el administrador toma nota para revertir el tiempo de prueba al período original de tres días después de que se complete este lanzamiento de parches específico. Este enfoque ayuda a garantizar que se aplique el tiempo de prueba estándar y más prudente 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 actualizados en una secuencia de lanzamiento:

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

Además, el administrador puede administrar un lanzamiento a través de acciones como pausar un lanzamiento si detecta problemas o completar una etapa si confía en los cambios de esa etapa y está listo para continuar de inmediato.

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.

Cómo GKE inicia el lanzamiento de una versión nueva

De forma predeterminada, GKE crea un lanzamiento nuevo cuando se establece un destino de actualización automática nuevo. La versión que GKE selecciona para lanzar depende de la versión secundaria y del canal de versiones de los clústeres de la secuencia. Por ejemplo, si tus clústeres ejecutan la versión 1.35 de GKE en el canal regular y GKE establece un objetivo de actualización automática en 1.35.5-gke.1000000, GKE crea un Rollout nuevo.

Sin embargo, también puedes elegir una versión que quieras que GKE implemente.

Lanza una versión específica

También puedes iniciar un lanzamiento a una versión específica si, por ejemplo, quieres aplicar un parche rápido a una vulnerabilidad de seguridad o solucionar un problema crítico con tus clústeres de GKE. Esta acción crea un objeto Rollout, lo que inicia un lanzamiento en tu secuencia de lanzamiento de la misma manera que cuando GKE establece un destino de actualización automática. Para lanzar una versión nueva, consulta Lanza una versión específica.

Si necesitas lanzar una versión nueva en un clúster lo más rápido posible, también puedes realizar actualizaciones manuales para los clústeres individuales. Las actualizaciones manuales de clústeres se realizan a nivel del clúster.

Elige qué tipos de actualizaciones realiza GKE en una secuencia de lanzamiento

De forma predeterminada, GKE implementa todos los tipos de actualizaciones de clústeres en una secuencia de lanzamiento, incluidas las actualizaciones de versiones de parches y versiones secundarias en el plano de control y los nodos.

Existen cuatro tipos principales de actualizaciones:

  • Actualizaciones de versiones de parches del plano de control
  • Actualizaciones de versiones de parches de los nodos
  • Actualizaciones de versiones secundarias del plano de control
  • Actualizaciones de versiones secundarias de los nodos

Puedes restringir el alcance de las actualizaciones de clústeres en una secuencia de lanzamiento para que solo se realicen tipos específicos de actualizaciones. Por ejemplo, si deseas que GKE implemente solo actualizaciones del plano de control y no de nodos, puedes especificar esto para tu secuencia de lanzamiento.

Si restringes el alcance de las actualizaciones de clústeres para una secuencia de lanzamiento, GKE no realizará ese tipo de actualización automática para ningún clúster en la secuencia de lanzamiento, excepto las actualizaciones automáticas obligatorias según sea necesario. Para obtener más información, consulta Lanzamientos para actualizaciones automáticas obligatorias. Restringir el alcance de las actualizaciones de clústeres no cancela los lanzamientos en curso del tipo que restringes, solo evita que GKE cree lanzamientos futuros de ese tipo.

Debido a que GKE no actualizará los nodos de un clúster a una versión posterior a la del plano de control, restringir el alcance de las actualizaciones del plano de control también puede restringir las actualizaciones de los nodos.

Para restringir el alcance de las actualizaciones automáticas en una secuencia de lanzamiento, consulta Elige qué tipos de actualizaciones realiza GKE en una secuencia de lanzamiento.

Restringir el alcance de una secuencia de lanzamiento funciona de manera similar a las exclusiones de mantenimiento, pero las exclusiones de mantenimiento se establecen para clústeres o grupos de nodos individuales dentro de un clúster.

Lanzamientos de actualizaciones automáticas obligatorias

Ya sea que tu clúster esté inscrito en una secuencia de lanzamiento, GKE realiza actualizaciones automáticas del clúster para garantizar la seguridad y la compatibilidad. Si los clústeres de tu secuencia de lanzamiento no tuvieron sus planos de control actualizados en 90 días o si los clústeres ejecutan una versión secundaria que alcanzó el final de la asistencia, GKE crea un lanzamiento obligatorio para realizar actualizaciones automáticas. Estos lanzamientos ayudan a garantizar que tu clúster siga siendo eficaz, disponible y seguro. GKE crea lanzamientos para estas situaciones, independientemente de las restricciones en el alcance de los lanzamientos, las exclusiones de mantenimiento o cualquier otro motivo de retraso.

No puedes pausar ni cancelar estos tipos de lanzamientos. GKE realiza estos tipos de actualizaciones de clústeres, independientemente de la inscripción en la secuencia de lanzamiento.

Para obtener más información sobre estas políticas, consulta las siguientes secciones:

Elegibilidad para el lanzamiento

Para que una versión se lance a través de una secuencia que use etapas personalizadas, los clústeres deben ser aptos para un objetivo 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, el lanzamiento del plano de control y el 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, la etapa no es apta para comenzar una nueva 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 o ignorar un clúster en una secuencia de lanzamiento, para permitir que continúe el lanzamiento. Si un clúster no es apto para ningún lanzamiento, GKE no lo actualizará automáticamente hasta que deba crear lanzamientos para actualizaciones automáticas obligatorias, como se describe en la sección anterior.

Los clústeres que ejecutan versiones posteriores al destino de 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, además, ignora 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 la 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, además, ignora los clústeres que ya están en la versión 1.33.

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

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

Por ejemplo, esta situación es relevante si configuraste exclusiones de mantenimiento para evitar de forma temporal las actualizaciones en tus clústeres de producción. Si tus clústeres de preproducción no tienen las mismas exclusiones de mantenimiento, es posible que se actualicen varias veces, lo que califica varias versiones nuevas, pero las etapas de producción no se actualizan.

Forced soaking después de 30 días

Para garantizar que una secuencia de lanzamiento termine de actualizar los clústeres, GKE inicia el período de prueba para un grupo si las actualizaciones del plano de control o del nodo, 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 prueba.

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

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

  • Períodos de mantenimiento y exclusiones: Puedes seguir usando períodos de mantenimiento y exclusiones para controlar cuándo pueden ocurrir las actualizaciones en tus clústeres y cuándo no. GKE inicia una actualización de clúster solo 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. Los siguientes dos métodos pueden restringir GKE para que realice ciertos tipos de actualizaciones:

    Sin embargo, ninguno de estos métodos que restringen el alcance de las actualizaciones de clústeres impide las actualizaciones automáticas obligatorias. Si GKE no puede actualizar un clúster debido a una exclusión o un 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.

  • 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 un nodo 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 de 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 de uso de APIs obsoletas: La detección de uso de APIs obsoletas de GKE sigue funcionando como se espera, lo que podría detener las actualizaciones en los clústeres que usan una API obsoleta.

  • Actualizaciones manuales: Actualizar de forma manual los clústeres en la primera etapa de una secuencia no califica, por sí sola, esa versión ni activa un lanzamiento para continuar. El proceso de lanzamiento automatizado se rige por los objetivos oficiales de actualización automática 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 objetivo de actualización automática designado.

  • Notificaciones de clúster: GKE proporciona notificaciones para la secuencia de lanzamiento, además de otras notificaciones de clúster disponibles. Para obtener más información, consulta Notificaciones para la secuenciación de lanzamientos.

Recibe varias actualizaciones en una secuencia

Un canal de versiones selecciona un objetivo de actualización para el clúster. Si hay una versión nueva 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 reciben 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 en 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.

Notificaciones para la secuenciación de lanzamiento

GKE envía notificaciones de clúster, que proporcionan información fundamental sobre las actualizaciones de clústeres a nivel del clúster. Además, GKE proporciona notificaciones sobre las secuencias de lanzamiento con etapas personalizadas y los lanzamientos que se realizan con esas secuencias. Por ejemplo, GKE envía notificaciones cuando una etapa de lanzamiento comienza, se completa o se bloquea. O bien, GKE envía una notificación si configuraste incorrectamente una secuencia de lanzamiento. Para obtener más información, consulta el documento Notificaciones del clúster y sus secciones respectivas para RolloutEvent y RolloutSequenceEvent.

Administra un lanzamiento

Cuando GKE lanza una versión nueva en los clústeres de tu secuencia de lanzamiento, puedes usar las siguientes acciones para controlar el proceso mientras evalúas cómo responden el clúster y las cargas de trabajo al cambio. Además, puedes crear un lanzamiento nuevo para lanzar una versión específica.

Mientras las actualizaciones están en curso, puedes verificar su estado. Según cómo se realice la actualización, puedes usar las acciones que se explican en los siguientes apartados.

Cómo pausar un lanzamiento

Puedes pausar un lanzamiento en curso. Si, por ejemplo, notas un posible problema con tus clústeres y la nueva versión que se está lanzando, puedes pausar el lanzamiento de forma temporal. GKE no iniciará operaciones de actualización nuevas a esta versión, lo que te permitirá investigar cualquier problema, según sea necesario. GKE no detendrá las operaciones de actualización en curso, pero no iniciará otras nuevas, incluidas las de las etapas posteriores.

Para pausar un lanzamiento, consulta Pausa un lanzamiento.

Después de pausar un lanzamiento, puedes reanudarlo o cancelarlo. Un lanzamiento se puede pausar por hasta 90 días. Después de 90 días, GKE cancela el lanzamiento.

Pausar un lanzamiento no impide que se inicien los lanzamientos posteriores. Sin embargo, estos lanzamientos no superarán la etapa de lanzamiento pausada. Por ejemplo, si GKE ya lanzó la versión 1.34.8-gke.1000000 en la primera y la segunda etapa, y pausas el lanzamiento en la tercera etapa, GKE puede iniciar un lanzamiento nuevo a la versión 1.35.5-gke.1163000 y actualizar los clústeres en las dos primeras etapas. Sin embargo, GKE no iniciará las actualizaciones a la versión 1.35.5-gke.1163000 en la tercera etapa hasta que se complete el lanzamiento de la versión 1.34.8-gke.1000000 en la tercera etapa o se cancele.

Si hay varios lanzamientos en curso para una secuencia de lanzamiento y quieres pausarlos todos, debes pausar cada lanzamiento de forma individual. Si deseas evitar que GKE inicie lanzamientos adicionales, puedes elegir qué tipos de actualizaciones realiza GKE en una secuencia de lanzamiento.

Reanuda un lanzamiento

Puedes reanudar un lanzamiento pausado que haya estado pausado durante menos de 90 días, después de que hayas investigado los posibles problemas y estés listo para que continúen las actualizaciones. Solo puedes reanudar un lanzamiento pausado si no se está ejecutando otro lanzamiento del mismo tipo (lanzamiento del plano de control o lanzamiento de nodos) al mismo tiempo en la misma etapa. También puedes reanudar un lanzamiento que GKE pausó de forma automática por motivos técnicos o comerciales, aunque te recomendamos que tengas cuidado antes de hacerlo.

Si reanudas el lanzamiento, GKE inicia nuevas operaciones de actualización para seguir lanzando la versión nueva en las etapas de la secuencia de lanzamiento.

Para reanudar un lanzamiento, consulta Reanuda un lanzamiento.

Cancela un lanzamiento

Puedes cancelar un lanzamiento, incluidos los que están activos o se pausaron. Cuando cancelas un lanzamiento, GKE no creará automáticamente un lanzamiento nuevo para la misma versión. Sin embargo, cancelar un lanzamiento no impide que GKE lance versiones posteriores. Si deseas que GKE deje de lanzar versiones posteriores, cancela todos los lanzamientos en curso y restringe el alcance de las actualizaciones de clústeres en la secuencia de lanzamiento.

Para cancelar un lanzamiento, consulta Cancela un lanzamiento.

Si necesitas lanzar la misma versión que se canceló, lanza una versión específica.

Cómo completar una etapa de lanzamiento

Si tienes la certeza de que el lanzamiento de una versión puede continuar a la siguiente etapa de la secuencia de lanzamiento porque, por ejemplo, completaste las pruebas en esa etapa, puedes avanzar manualmente el lanzamiento completando la etapa. Si completas la etapa, los clústeres que GKE aún no haya actualizado no se actualizarán como parte de ese lanzamiento. Si completas la etapa, también se omitirá el tiempo de prueba restante. Esta acción también significa que no tienes que cambiar el tiempo de prueba de esfuerzo en el nivel de la secuencia de lanzamiento.

Para completar una etapa de lanzamiento, consulta Completa una etapa de lanzamiento.

Administra un lanzamiento cambiando la secuencia de lanzamiento

También puedes administrar un lanzamiento tomando medidas que afecten toda la secuencia de lanzamiento. Sin embargo, considera realizar las acciones descritas en las secciones anteriores antes de hacerlo, como pausar un lanzamiento. Algunos cambios en una secuencia de lanzamiento pueden provocar que se cancelen los lanzamientos en curso, además de afectar el funcionamiento de los lanzamientos futuros en la secuencia. Si solo quieres cambiar un lanzamiento, usa las herramientas proporcionadas para administrar un lanzamiento, en lugar de cambiar toda la secuencia.

Sin embargo, si deseas cambiar el funcionamiento de una secuencia de lanzamiento para todos los lanzamientos, no solo el lanzamiento de una versión nueva, consulta la siguiente sección, Administra una secuencia de lanzamiento.

Controla las actualizaciones de clústeres individuales para administrar el lanzamiento

Para actualizaciones de clústeres individuales, puedes usar las siguientes herramientas para administrar las actualizaciones:

  • Controlar las actualizaciones de forma manual mediante 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 las 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.

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

Administra una secuencia de lanzamiento

Para administrar una secuencia de lanzamiento, puedes realizar acciones básicas como las siguientes:

  • Enumera tus secuencias de lanzamiento
  • Describe una secuencia de lanzamiento

Además, puedes realizar acciones como modificar una secuencia de lanzamiento y omitir un clúster en una secuencia de lanzamiento. Estas acciones se describen en las siguientes subsecciones.

Para obtener más información sobre cómo administrar el lanzamiento de una versión en lugar de toda la secuencia de lanzamiento, consulta la sección anterior, Administra un lanzamiento.

Ignora un clúster en una secuencia de lanzamiento

De forma predeterminada, todos los clústeres que forman parte de una flota en una secuencia de lanzamiento se actualizan como parte de la secuencia de lanzamiento. Puedes agregar clústeres a etapas específicas, o bien todos los clústeres que estén en una flota y no estén etiquetados se actualizarán juntos.

Sin embargo, si tienes un clúster que no deseas incluir en la secuencia de lanzamiento, puedes etiquetarlo para que GKE lo ignore cuando lance versiones nuevas. Es posible que debas hacerlo si, por ejemplo, necesitas tiempo adicional antes de actualizar ese clúster específico. Puedes ignorar uno o más clústeres en una secuencia de lanzamiento.

Si ignoras un clúster en una secuencia de lanzamiento, GKE no lo tendrá en cuenta cuando lance una versión nueva y no realizará actualizaciones automáticas para el clúster, excepto las actualizaciones automáticas obligatorias, incluidas las actualizaciones automáticas al final de la asistencia y las actualizaciones automáticas para los planos de control que no se actualizaron en 90 días.

Para ignorar un clúster en una secuencia de lanzamiento, consulta Ignora un clúster en una secuencia de lanzamiento.

Modifica una secuencia de lanzamiento

Si deseas cambiar la forma en que se realizan los lanzamientos en una secuencia de lanzamiento existente, puedes modificar la secuencia de una de las siguientes dos maneras:

  • Para modificar una secuencia de lanzamiento, edita el archivo de configuración YAML en el que definiste la secuencia.
  • Modifica los clústeres de la secuencia.

Si modificas una secuencia de lanzamiento, sucederá lo siguiente:

  • Si agregas o quitas una etapa, cambias el orden de las etapas o editas una etapa (por ejemplo, para cambiar el ID del proyecto o los selectores de etiquetas de esa etapa) en una secuencia de lanzamiento, GKE cancela todos los lanzamientos activos.
  • Si cambias el tiempo de prueba de una etapa, GKE no cancela los lanzamientos activos.

Para modificar una secuencia de lanzamiento, consulta Modifica una secuencia de lanzamiento.

Si modificas los clústeres en una secuencia, ocurrirá lo siguiente:

  • Si quitas un clúster de una secuencia de lanzamiento quitándolo de una flota, los lanzamientos activos continúan. GKE puede actualizar el clúster de forma automática según los procedimientos típicos para los clústeres que no están inscritos en una secuencia.
  • Si agregas un clúster a una flota en una secuencia de lanzamiento, GKE actualizará este clúster como parte de cualquier lanzamiento activo que aún no haya pasado la etapa en la que lo agregaste. Sin embargo, si se completó la etapa del lanzamiento, GKE no actualizará el clúster en ese lanzamiento.

  • Si mueves un clúster a una etapa diferente sin editar la configuración de la secuencia de lanzamiento, sucede lo siguiente, según si se completó la etapa a la que mueves el clúster:

    • Si mueves un clúster a una etapa que ya completó su lanzamiento, GKE no actualiza el clúster en ese lanzamiento.
    • Si mueves un clúster que ya se actualizó en un lanzamiento a una etapa posterior sin terminar, GKE ignora el clúster y no interrumpe el progreso del lanzamiento.

Para modificar los clústeres en una secuencia, consulta Registra un clúster en Cloud de Confiance by S3NS en tu flota.

Limitaciones

Las siguientes limitaciones se aplican cuando actualizas tus clústeres con la secuenciación de lanzamiento con etapas personalizadas:

  • No puedes usar la consola de Cloud de Confiance para crear o modificar secuencias de lanzamiento con fases personalizadas. Sin embargo, puedes usar la consola para supervisar un lanzamiento (versión preliminar).
  • 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 orientar 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 "comodín" que incluya todos los clústeres restantes de esa misma flota. Esta etapa general se orienta a la misma flota, pero no incluye un label-selector, por lo que incluye automáticamente todos los clústeres que no se seleccionaron en las etapas anteriores de la secuencia.
  • Si modificas una secuencia durante un lanzamiento, específicamente los cambios que afectan a los clústeres participantes, GKE cancela de inmediato todos los lanzamientos existentes. Si modificas solo el tiempo de prueba de una secuencia, GKE no cancela el lanzamiento.
  • 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.
  • No puedes actualizar clústeres con la secuencia de lanzamiento que usan actualizaciones automáticas de parches aceleradas.
  • Puedes crear una secuencia de lanzamiento con hasta 15 etapas.
  • Puedes incluir hasta 250 clústeres en una flota. En el caso de los clústeres con membresías livianas, puedes solicitar un aumento de la cuota para un máximo de 2,000 clústeres en una flota. Para obtener más información, consulta Cuotas y límites.
  • Puedes configurar un tiempo de prueba máximo por secuencia de hasta 90 días en todas las etapas.

Problemas conocidos

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

  • Si una etapa de tu secuencia de lanzamiento no contiene clústeres, se omite, pero el tiempo de prueba definido para esa etapa sigue transcurriendo antes de que el lanzamiento continúe con la siguiente etapa.

¿Qué sigue?