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 la lanza a un subconjunto de usuarios antes de lanzarla 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 lanzamiento 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 la aplicación en GKE (o en clústeres adjuntos de GKE), 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.

  • Personalizado y automatizado

    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 predespliegue o de postdespliegue, 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 predespliegue o de postdespliegue, o ambas

    Además, en el caso de una versión canary totalmente personalizada, 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 canary, se crea un lanzamiento con una fase por cada incremento canary, además de una fase stable final del 100%.

Por ejemplo, si configura un lanzamiento de versión 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 un lanzamiento canary mediante el lanzamiento paralelo. 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 caso del despliegue canario 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 una publicación controlada y las publicaciones secundarias.

    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 adelantar 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 implementaciones secundarias.

  • 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 un lanzamiento secundario, no en un lanzamiento de controlador.

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

Cuando falla el lanzamiento de un elemento secundario, el lanzamiento del controlador puede pasar a diferentes estados, en función de lo que ocurra con los lanzamientos de los elementos secundarios:

  • Si falla una o más implementaciones secundarias, pero al menos una sigue siendo IN_PROGRESS, la implementación del controlador sigue siendo 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 trata de la fase stable, el lanzamiento del controlador es FAILED.

    HALTED te da la opción 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 debido a un lanzamiento secundario fallido y no tienes en cuenta el trabajo fallido en el lanzamiento secundario, el lanzamiento del controlador volverá al estado IN_PROGRESS.

Siguientes pasos