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 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 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 con etapas personalizadas.

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 entorno 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 recomendamos usar la secuenciación de lanzamiento con etapas personalizadas para los entornos nuevos:

  • Secuencia de lanzamiento con etapas personalizadas (recomendado 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 no tiene compatibilidad con la consola de Cloud de Confiance . 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. 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 lanzamientos. Elige esta opción si es la primera vez que creas una secuencia de lanzamiento.
  • Secuenciación de la implementación basada en flotas: Es la única versión de esta función que se puede usar con la consola de Cloud de Confiance , pero, por lo demás, tiene una funcionalidad más limitada y no se recomienda si creas una secuencia de implementación por primera vez.

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

Secuenciación 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 permanencia. 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 visibilidad con los nuevos objetos de API RolloutSequence y Rollout.

Este método proporciona la mayor flexibilidad y el control más 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 GKE lanza una versión nueva, primero actualiza los clústeres en la flota de pruebas y, luego, los clústeres en 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 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 espera: Es un período de espera configurable que se produce después de que se actualizan todos los clústeres en una etapa. Este tiempo de prueba te permite validar la nueva versión en un entorno y detectar posibles problemas antes de que la actualización continúe al 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 de preproducción te brinda 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 en etapas anteriores se hayan actualizado por completo y hayan completado su período de estabilización antes de que la actualización avance a 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 sola actualización de versión a través de tu secuencia. Puedes usar Rollout para ver el estado del lanzamiento, hacer un seguimiento del progreso y ver si algún clúster no es apto 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 proyectoCloud de Confiance by S3NS dedicado para alojar tus objetos RolloutSequence. Colocar la secuencia en un proyecto dedicado proporciona un punto de control central y neutral 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 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 actualiza GKE 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 inicia un nuevo lanzamiento en la secuencia de lanzamientos. 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 del lanzamiento con etapas personalizadas, también puedes activar un nuevo lanzamiento en una secuencia de lanzamiento para 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 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 calificada por 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 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 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 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 a la nueva versió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 según lo esperado.

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 vínculos:

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, etapa de pruebas 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 (con menos tráfico) 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 "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 tiene como objetivo 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 permanencia 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 fase de prueba de la etapa us-west1 de la flota de producción. Dado que 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 actualizados 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.

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 nueva versión

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

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

Lanza una versión específica

También puedes iniciar un lanzamiento para una versión específica si, por ejemplo, deseas aplicar un parche rápidamente a una vulnerabilidad de seguridad o corregir un problema crítico con tus clústeres de GKE. Esta acción crea un objeto Rollout, lo que inicia un lanzamiento en toda la 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 implementar una versión nueva en un clúster lo más rápido posible, también puedes realizar actualizaciones manuales del clúster para los clústeres individuales. Las actualizaciones manuales del clúster se realizan a nivel del clúster.

Cómo elegir los tipos de actualizaciones que GKE realiza en una secuencia de lanzamiento

De forma predeterminada, GKE lanza todos los tipos de actualizaciones de clúster en una secuencia de lanzamiento, incluidas las actualizaciones de la versión de parche y la versión secundaria para 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 realizar solo tipos específicos de actualizaciones. Por ejemplo, si deseas que GKE lance solo las actualizaciones del plano de control y no las de los nodos, puedes especificarlo en la 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 de la secuencia de lanzamiento, excepto las actualizaciones automáticas obligatorias según sea necesario. Para obtener más información, consulta Lanzamientos de actualizaciones automáticas obligatorias. Restringir el alcance de las actualizaciones del clúster no cancela las implementaciones en curso del tipo que restringes, sino que solo impide que GKE cree implementaciones futuras de ese tipo.

Dado 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 estas se configuran para clústeres individuales o grupos de nodos dentro de un clúster.

Lanzamientos de actualizaciones automáticas obligatorias

Independientemente de si 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 actualizaron sus planos de control en 90 días o si ejecutan una versión secundaria que alcanzó el final de la asistencia, GKE crea un lanzamiento obligatorio para realizar actualizaciones automáticas. Estas implementaciones ayudan a garantizar que tu clúster siga siendo seguro, esté disponible y tenga un buen rendimiento. 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 demora.

No puedes pausar ni cancelar este tipo 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 usa etapas personalizadas, los clústeres deben ser aptos para un objetivo de actualización de su canal de versiones. Cuando hay una versión nueva 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 estado SOAKING con una versión en particular, 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 las actualizaciones automáticas obligatorias, como se describe en la sección anterior.

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, esta situación es pertinente si configuraste exclusiones de mantenimiento para evitar temporalmente las actualizaciones en tus clústeres de producción. Si tus clústeres de preproducción no tenían las mismas exclusiones de mantenimiento, es posible que se actualicen varias veces, lo que calificaría varias versiones nuevas, pero tus etapas de producción no se actualizarían.

Forced soaking después de 30 días

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.

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. Ambos 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 del clúster impide las actualizaciones automáticas obligatorias. 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.

  • 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 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 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 se detengan 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 por sí solo 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 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 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.

Notificaciones para la secuenciación de lanzamiento

GKE envía notificaciones del clúster, que proporcionan información crítica sobre las actualizaciones 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 comienza, se completa o se bloquea una etapa de lanzamiento. O bien, GKE envía una notificación si configuraste de forma incorrecta una secuencia de lanzamiento. Para obtener más información, consulta el documento Notificaciones del clúster y sus respectivas secciones para RolloutEvent y RolloutSequenceEvent.

Cómo administrar un lanzamiento

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

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

Cómo pausar un lanzamiento

Puedes pausar un lanzamiento en curso. Por ejemplo, si detectaste un posible problema con tus clústeres y la nueva versión que se está lanzando, puedes pausar temporalmente el lanzamiento. GKE no iniciará nuevas operaciones de actualización 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á operaciones nuevas, incluidas las de etapas posteriores.

Para pausar un lanzamiento, consulta Cómo pausar un lanzamiento.

Después de detener un lanzamiento, puedes reanudarlo o cancelarlo. El lanzamiento se puede pausar por hasta 90 días. Después de 90 días, GKE cancelará el lanzamiento.

Detener un lanzamiento no impide que se inicien lanzamientos posteriores. Sin embargo, estos lanzamientos no reemplazarán la etapa de lanzamiento pausado. Por ejemplo, si GKE ya lanzó la versión 1.34.8-gke.1000000 en las etapas primera y segunda, y pausas el lanzamiento en la tercera etapa, GKE puede iniciar un nuevo lanzamiento 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 en una secuencia de lanzamientos 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.

Cómo reanudar un lanzamiento

Puedes reanudar un lanzamiento en pausa que se haya pausado durante menos de 90 días después de investigar los posibles problemas y cuando esté todo listo para que se realicen 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 del nodo) al mismo tiempo en la misma etapa. También puedes reanudar un lanzamiento que GKE pausó automáticamente por motivos técnicos o comerciales, aunque te recomendamos que tengas precaución antes de hacerlo.

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

Para reanudar un lanzamiento, consulta Cómo reanudar un lanzamiento.

Cómo cancelar un lanzamiento

Puedes cancelar un lanzamiento, incluidos los que estén activos o en pausa. Cuando cancelas un lanzamiento, GKE no crea automáticamente un lanzamiento nuevo para la misma versión. Sin embargo, cancelar un lanzamiento no impide que GKE lance versiones posteriores. Si deseas evitar que GKE también lance versiones posteriores, cancela todos los lanzamientos en curso y restringe el alcance de las actualizaciones del clúster en la secuencia de lanzamiento.

Para cancelar un lanzamiento, consulta Cómo cancelar 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 avanzar 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 remojo restante. Esta acción también significa que no tienes que cambiar el tiempo de remojo a nivel de la secuencia de lanzamiento.

Para completar una etapa de lanzamiento, consulta Cómo completar una etapa de lanzamiento.

Administra un lanzamiento cambiando la secuencia de lanzamiento

También puedes administrar un lanzamiento realizando acciones que afecten toda la secuencia de lanzamiento. Sin embargo, considera realizar las acciones que se describen 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 para 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 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.

Cómo ignorar 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 se actualizarán juntos todos los clústeres que se encuentren en una flota y no estén etiquetados.

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 implementación, GKE no lo tendrá en cuenta cuando implemente una versión nueva ni realizará actualizaciones automáticas para el clúster, excepto las actualizaciones automáticas obligatorias, incluidas las actualizaciones automáticas al final de la compatibilidad y las actualizaciones automáticas para los planos de control que no se hayan actualizado en 90 días.

Para ignorar un clúster en una secuencia de lanzamiento, consulta Cómo ignorar un clúster en una secuencia de lanzamiento.

Cómo modificar 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:

  • Modifica una secuencia de lanzamiento editando 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, ocurrirá lo siguiente:

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

Para modificar una secuencia de lanzamiento, consulta Cómo modificar una secuencia de lanzamiento.

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

  • Si quitas un clúster de una secuencia de lanzamiento quitándolo de una flota, los lanzamientos activos continuarán. GKE puede actualizar el clúster automáticamente 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 superado la etapa en la que lo agregaste. Sin embargo, si la etapa se completó para el lanzamiento, GKE no actualizará el clúster en ese lanzamiento.

  • Si mueves un clúster a otra etapa sin editar la configuración de la secuencia de lanzamiento, sucederá 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 actualizará el clúster en ese lanzamiento.
    • Si mueves un clúster que ya se actualizó en un lanzamiento a una etapa posterior sin finalizar, GKE ignorará el clúster y no interrumpirá 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

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

  • No puedes usar la consola de Cloud de Confiance 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.
  • 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 secuenciación de lanzamiento que usen 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 ligeras, puedes solicitar un aumento de la cuota de hasta 2,000 clústeres en una flota. Para obtener más información, consulta Cuotas y límites.
  • Puedes configurar un tiempo de permanencia máximo por secuencia de hasta 90 días en todas las etapas.

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?