Usar una estrategia de despliegue canary

En este documento se describe cómo configurar y usar una estrategia de implementación canaria.

¿Qué es un despliegue canary?

Un lanzamiento canary es un lanzamiento progresivo de una aplicación que divide el tráfico entre una versión ya implementada y una nueva, y que se lanza a un subconjunto de usuarios antes de lanzarse por completo.

Tipos de segmentación admitidos

La implementación canary en Cloud Deploy admite todos los tipos de destino, incluidos los siguientes:

Canary también funciona con varios objetivos.

¿Por qué usar una estrategia de despliegue canary?

Un despliegue canary te da la oportunidad de lanzar tu aplicación parcialmente. De esta forma, puedes asegurarte de que la nueva versión de tu aplicación es fiable antes de ofrecerla a todos los usuarios.

Por ejemplo, si vas a desplegar tu aplicación en GKE o GKE Enterprise, desplegarías la nueva versión en un número limitado de pods. La versión antigua seguiría ejecutándose, pero se enviaría más tráfico a los nuevos pods.

Si vas a implementar en Cloud Run, Cloud Run dividirá el tráfico entre las revisiones antiguas y las nuevas según los porcentajes que configures.

Tipos de canary

Cloud Deploy te permite configurar los siguientes tipos de despliegue canary:

  • Automatizada

    Con un despliegue canario automatizado (para redes de servicios, API de gateway o Cloud Run), puedes configurar Cloud Deploy con una serie de porcentajes que expresan un despliegue progresivo. Cloud Deploy realiza operaciones adicionales en tu nombre para asignar porcentajes de tráfico entre las versiones antiguas y nuevas.

  • Personalizada y automatizada

    Para una versión canary personalizada y automatizada (para redes de servicios, API de gateway o Cloud Run), puedes proporcionar lo siguiente:

    • Nombre de la fase
    • El objetivo de porcentaje
    • El perfil de Skaffold que se va a usar en la fase
    • Si se debe incluir o no un trabajo de verificación
    • Si se debe incluir una tarea de pre-implementación o post-implementación, o ambas

    Sin embargo, no es necesario que proporcione información sobre el balanceo de carga del tráfico, ya que Cloud Deploy crea los recursos necesarios (para redes de servicios, API de gateway o Cloud Run).

  • Personalizado

    Con una versión canary personalizada, puedes configurar cada fase de la versión canary por separado, incluidas las siguientes:

    • Nombre de la fase
    • El objetivo de porcentaje
    • El perfil de Skaffold que se va a usar en la fase
    • Si se debe incluir o no un trabajo de verificación
    • Si se debe incluir una tarea de pre-implementación o post-implementación, o ambas

    Además, en el caso de un lanzamiento canary totalmente personalizado, debes proporcionar toda la configuración de equilibrio de carga.

    Se admiten todos los tipos de destino para las versiones canary personalizadas.

Fases de un despliegue canary

Cuando creas una versión para un lanzamiento de tipo canario, se crea un lanzamiento con una fase por cada incremento de la versión canario, además de una fase stable final para el 100%.

Por ejemplo, si configura un lanzamiento canary con incrementos del 25%, el 50 % y el 75 %, el lanzamiento tendrá las siguientes fases:

  • canary-25
  • canary-50
  • canary-75
  • stable

Puedes consultar más información sobre las fases de lanzamiento, los trabajos y las ejecuciones de trabajos en Gestionar lanzamientos.

Usar el despliegue paralelo con una estrategia de despliegue canary

Puedes llevar a cabo una implementación canaria mediante la implementación paralela. Esto significa que el objetivo al que estás implementando progresivamente puede incluir dos o más objetivos secundarios. Por ejemplo, puedes implementar progresivamente en clústeres de regiones independientes al mismo tiempo.

¿En qué se diferencia una versión canary paralela de una versión canary de un solo objetivo?

  • Al igual que en el despliegue canary de un solo destino, si vas a desplegar en destinos de GKE, necesitas una configuración de despliegue de Kubernetes y una configuración de servicio de Kubernetes en tu manifiesto.

  • Al igual que en el despliegue canary de un solo destino, la configuración de tu flujo de procesamiento de entrega debe incluir una estrofa strategy.canary dentro de la definición de la fase correspondiente.

  • Además, debes configurar un elemento de destino múltiple y configurar los elementos de destino secundarios a los que hace referencia ese elemento de destino múltiple.

  • Cuando creas una versión, se crean un lanzamiento controlado y los lanzamientos secundarios.

    Ambos tipos de lanzamiento (controlador y secundario) tienen fases independientes para todos los porcentajes de lanzamiento canary configurados y una fase stable para el 100 % del lanzamiento canary.

  • No puedes avanzar una implementación secundaria.

    Solo puedes avanzar los lanzamientos de controladores. Cuando avanzas el lanzamiento del controlador a la siguiente fase, Cloud Deploy también avanza los lanzamientos secundarios.

  • No puedes volver a intentar los trabajos fallidos en el lanzamiento del controlador.

    Solo puedes volver a intentar un trabajo en lanzamientos secundarios.

  • No puedes ignorar las tareas fallidas en el lanzamiento del controlador.

    Solo puede ignorar los trabajos fallidos en las implementaciones secundarias.

  • Puedes cancelar el lanzamiento de un controlador, pero no puedes cancelar el lanzamiento de un elemento secundario.

  • Solo puedes finalizar ejecuciones de trabajos en una implementación secundaria, no en una implementación de controlador.

Qué hacer si una implementación paralela falla en la versión canary

Cuando falla el lanzamiento de una versión secundaria, el lanzamiento de la versión principal puede pasar a diferentes estados, en función de lo que ocurra con los lanzamientos de las versiones secundarias:

  • Si se produce un error en una o varias implementaciones secundarias, pero al menos una de ellas sigue en estado IN_PROGRESS, la implementación del controlador permanece en ese estado.IN_PROGRESS

  • Si se produce un error en una o varias implementaciones secundarias, pero al menos una se completa correctamente, la implementación del controlador será HALTED si hay más fases después de la actual.

    Si se encuentra en la fase stable, el lanzamiento del controlador está FAILED.

    HALTED te da la oportunidad de ignorar, volver a intentar los trabajos fallidos en el lanzamiento secundario fallido o cancelar el lanzamiento del controlador y evitar que se realicen más acciones en los lanzamientos secundarios.

  • Si el lanzamiento del controlador está en estado HALTED porque ha fallado el lanzamiento secundario y no tienes en cuenta el error del trabajo en el lanzamiento secundario, el lanzamiento del controlador vuelve al estado IN_PROGRESS.

Siguientes pasos