Usa una estrategia de implementación de versiones canary

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

¿Qué es una implementación de versiones canary?

Una implementación de versiones 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 objetivos admitidos

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

Canary también funciona con varios objetivos.

¿Por qué usar una estrategia de implementación de versiones canary?

Una implementación de versiones canary te permite lanzar tu aplicación de forma parcial. De esta manera, puedes asegurarte de que la nueva versión de tu aplicación sea confiable antes de entregarla a todos los usuarios.

Por ejemplo, si realizas la implementación en GKE o GKE Enterprise, implementarías la versión nueva de tu aplicación en una cantidad limitada de pods. La versión anterior seguiría ejecutándose, pero con más tráfico que se enviaría a los pods nuevos.

Si realizas la implementación en Cloud Run, esta divida el tráfico entre las revisiones anteriores y nuevas, según los porcentajes que configures.

Tipos de canarios

Cloud Deploy te permite configurar los siguientes tipos de implementaciones Canary:

  • Automático

    Con una implementación canario automatizada, configuras Cloud Deploy con una serie de porcentajes que expresan una implementación progresiva. Cloud Deploy realiza operaciones adicionales en tu nombre para distribuir los porcentajes de tráfico entre las versiones anterior y nueva.

  • Automatización personalizada

    Para una versión canary automatizada personalizada, puedes proporcionar lo siguiente:

    • El nombre de la fase
    • El objetivo de porcentaje
    • El perfil de Skaffold que se usará para la fase
    • Si se debe incluir o no un trabajo de verificación
    • Si se incluye o no una tarea de preimplementación o posimplementación, o ambas

    Sin embargo, no necesitas proporcionar información de balanceo de tráfico. Cloud Deploy crea los recursos necesarios.

  • Personalizado

    Con un canario personalizado, configuras cada fase de canario por separado, incluidos los siguientes aspectos:

    • El nombre de la fase
    • El objetivo de porcentaje
    • El perfil de Skaffold que se usará para la fase
    • Si se debe incluir o no un trabajo de verificación
    • Si se incluye o no una tarea de preimplementación o posimplementación, o ambas

    Además, para un canario completamente personalizado, debes proporcionar toda la configuración de equilibrio de tráfico, como se describe aquí.

Fases de una implementación de versiones canary

Cuando creas una versión para una implementación de versiones canary, el lanzamiento se crea con una fase para cada incremento Canary, más una fase stable final para el 100%.

Por ejemplo, si configuras un Canary para incrementos del 25%, 50% y 75%, el lanzamiento tendrá las siguientes fases:

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

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

Qué sucede durante una canary automatizada o personalizada

Para admitir tu implementación de versiones canary, Cloud Deploy incluye pasos de procesamiento especiales cuando se renderiza el manifiesto de Kubernetes o la configuración del servicio de Cloud Run:

GKE/Enterprise

A continuación, se muestra cómo Cloud Deploy ejecuta una implementación de versiones canary en GKE y GKE Enterprise basados en la red:

  1. Proporciona el nombre del recurso de Deployment y del recurso de servicio.

  2. Cloud Deploy crea un recurso de Deployment adicional, con el nombre de tu Deployment actual más -canary.

  3. Cloud Deploy modifica el servicio para ajustar el selector de modo que seleccione los pods de la Deployment actual y los pods canary.

    Cloud Deploy calcula la cantidad de pods que se usarán para el canario según el cálculo que se describe aquí. Ese cálculo difiere según si habilitas o inhabilitas el sobreaprovisionamiento de pods.

    Si omitimos la fase stable, Cloud Deploy agrega las etiquetas que se usarán para hacer coincidir los pods, de modo que estén disponibles para las ejecuciones canary posteriores.

    Cloud Deploy crea una Deployment que incluye el porcentaje de pods específico de la fase y lo actualiza para cada fase. Para ello, se calcula la cantidad de pods como un porcentaje de la cantidad original de pods. Esto puede generar una división del tráfico inexacta. Si necesitas una división de tráfico exacta, puedes lograrlo con la API de Gateway.

    Además, los Secrets y los ConfigMaps también se copian y se les cambia el nombre con -canary.

  4. Durante la fase stable, la Deployment de -canary se reduce a cero y la Deployment original se reemplaza por la nueva.

    Cloud Deploy no modifica la Deployment original hasta la fase stable.

Cloud Deploy aprovisiona pods para lograr el porcentaje de Canary solicitado lo más cerca posible. Esto se basa en la cantidad de pods, no en el tráfico hacia ellos. Si deseas que tu canario se base en el tráfico, debes usar la API de Gateway.

En el caso de Canary basado en la red de GKE, puedes habilitar o inhabilitar el sobreaprovisionamiento de pods. En las siguientes secciones, se describe cómo Cloud Deploy calcula la cantidad de pods que se aprovisionarán para la implementación de versiones canary para cada fase de Canary.

Aprovisionamiento de pods con el sobreaprovisionamiento habilitado

Habilitar el sobreaprovisionamiento (disablePodOverprovisioning: false) permite que Cloud Deploy cree suficientes pods adicionales para ejecutar el porcentaje de Canary que desees, según la cantidad de pods que ejecutan tu implementación existente. En la siguiente fórmula, se muestra cómo Cloud Deploy calcula la cantidad de pods que se aprovisionarán para la implementación de versiones canary de cada fase Canary cuando el sobreaprovisionamiento de pods está habilitado:

math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))

Con esta fórmula, el recuento de réplicas actual (la cantidad de pods que ya tienes antes de esta canaria) se multiplica por el porcentaje de canaria de la fase y el resultado se divide por (100 menos el porcentaje).

Por ejemplo, si ya tienes 4 pods y tu fase canary es del 50%, entonces la cantidad de pods canary es 4. (El resultado de 100-percentage se usa como un porcentaje: 100-50=50, que se trata como .50).

El sobreaprovisionamiento de pods es el comportamiento predeterminado.

Aprovisionamiento de pods con el sobreaprovisionamiento inhabilitado

Puedes inhabilitar el sobreaprovisionamiento (disablePodOverprovisioning: true) para asegurarte de que Cloud Deploy no aumente el recuento de réplicas.

En la siguiente fórmula, se muestra cómo Cloud Deploy calcula el aprovisionamiento de pods para la implementación de versiones canary de cada fase Canary, cuando el sobreaprovisionamiento de pods está inhabilitado:

math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)

En esta fórmula, ReplicaCountOfCanaryDeploymentOnCluster solo existe si ya había una fase canaria. Si esta es la primera fase canary, no hay ReplicaCountOfCanaryDeploymentOnCluster.

Si comienzas con 4 pods, esa cantidad se multiplica por el porcentaje de Canary (por ejemplo, 50% o .5) para obtener 2. Por lo tanto, la implementación original ahora se reduce a 2, y se crean 2 pods nuevos para la implementación de versiones canary. Si luego tienes una etapa canary del 75%, tienes 2 (implementación original) +2 (primera etapa canary), *.75, para obtener pods canary 3 y el pod 1 que ejecuta la implementación original.

Puerta de enlace de GKE/Enterprise

A continuación, se muestra cómo Cloud Deploy ejecuta una implementación de versiones canary en GKE y GKE Enterprise con la API de Gateway:

  1. Además de las referencias de Deployment y Service, proporcionas un recurso HTTPRoute, con una regla backendRefs que hace referencia al servicio.

  2. Cloud Deploy crea una Deployment nueva, con el nombre de la Deployment original más -canary, y un servicio nuevo con el nombre del servicio original más -canary.

    Además, los Secrets, los ConfigMaps y los escaladores automáticos de pods horizontales también se copian y se les cambia el nombre a -canary.

  3. Para cada fase canaria, Cloud Deploy modifica HTTPRoute para actualizar la ponderación entre los pods de la Deployment original y los pods de la Deployment canaria, según el porcentaje de esa fase.

    Debido a que puede haber una demora en la propagación de cambios a los recursos HTTPRoute, puedes incluir la propiedad routeUpdateWaitTime en tu configuración para que el sistema espere una cantidad de tiempo especificada para esta propagación.

  4. Durante la fase stable, la Deployment de -canary se reduce a cero y la Deployment original se actualiza para usar la Deployment de la nueva versión.

    Además, HTTPRoute ahora se revierte al original que proporcionaste.

    Cloud Deploy no modifica la Deployment ni el servicio originales hasta la fase stable.

Cloud Run

A continuación, se muestra cómo Cloud Deploy ejecuta una implementación de versiones canary para Cloud Run:

  • Para una implementación de versiones canary en Cloud Run, no proporciones una estrofa traffic en el archivo YAML de tu servicio.

  • Cuando creas un lanzamiento nuevo para Canary, Cloud Deploy divide el tráfico entre la revisión anterior que Cloud Deploy implementó correctamente y una revisión nueva.

Si deseas ver las diferencias entre las fases de una implementación de versiones canary, puedes ver los cambios en el manifiesto renderizado por fase disponible en el inspector de lanzamientos. Puedes hacerlo incluso antes de que comience el lanzamiento. Además, si usas la implementación en paralelo, también puedes inspeccionar el manifiesto renderizado de cada elemento secundario.

Configura una implementación de versiones canary

En esta sección, se describe cómo configurar tu canalización de publicación y tus objetivos para una implementación de versiones canary.

Las instrucciones que se incluyen aquí solo incluyen lo que es específico de la configuración Canary. En el documento Cómo implementar tu aplicación, se incluyen las instrucciones generales para configurar y ejecutar tu canalización de implementación.

Asegúrate de tener los permisos necesarios

Además de los otros permisos de Identity and Access Management que necesitas para usar Cloud Deploy, necesitas los siguientes permisos para realizar acciones adicionales que podrían ser necesarias para una implementación de versiones canary:

  • clouddeploy.rollouts.advance
  • clouddeploy.rollouts.ignoreJob
  • clouddeploy.rollouts.cancel
  • clouddeploy.rollouts.retryJob
  • clouddeploy.jobRuns.get
  • clouddeploy.jobRuns.list
  • clouddeploy.jobRuns.terminate

Consulta Roles y permisos de IAM para obtener más información sobre qué roles disponibles incluyen estos permisos.

Prepara tu skaffold.yaml

Al igual que con una implementación estándar, tu canario necesita un archivo skaffold.yaml, que define cómo se renderizan y se implementan los manifiestos y las definiciones de servicio.

El skaffold.yaml que creas para una implementación de versiones canary no tiene ningún requisito especial más allá de lo que se necesita para la implementación estándar.

Prepara tu manifiesto o definición de servicio

Al igual que con una implementación estándar, tu canario necesita un manifiesto de Kubernetes o una declaración de servicio de Cloud Run.

GKE y GKE Enterprise

Para Canary, el manifiesto debe tener lo siguiente:

  • Una Deployment y un servicio.

  • El servicio debe definir un selector, y ese selector debe seleccionar los pods de la Deployment especificada. El valor predeterminado es app.

  • Si usas un canario basado en la API de la puerta de enlace, el manifiesto también debe tener una HTTPRoute.

Cloud Run

Para Canary en Cloud Run, tu archivo de definición de servicio normal de Cloud Run es suficiente, pero sin una estrofa traffic. Cloud Deploy administra la división del tráfico entre la última revisión correcta y la nueva.

Configura una versión canary automatizada

Las siguientes instrucciones son para Cloud Run y los objetivos de redes basados en servicios de GKE y GKE Enterprise. Si usas la API de Kubernetes Gateway con GKE o GKE Enterprise, consulta esta documentación.

Configura la versión canary automatizada en la definición de tu canalización de entrega:

GKE y GKE Enterprise

En la etapa de canalización, incluye una propiedad strategy, de la siguiente manera:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

En esta configuración…

  • SERVICE_NAME es el nombre del servicio de Kubernetes, que se define en tu manifiesto.

  • DEPLOYMENT_NAME es el nombre de tu Deployment de Kubernetes, definido en tu manifiesto.

  • LABEL es una etiqueta de selector de pods. Debe coincidir con el selector de etiquetas del servicio de Kubernetes definido en tu manifiesto. Esto es opcional. El valor predeterminado es app.

  • PERCENTAGES es una lista separada por comas de valores porcentuales que representan tus incrementos Canary, por ejemplo, [5, 25, 50].

    Además, no incluye 100, ya que se supone que la implementación del 100% se realiza en Canary y la controla la fase stable.

  • Puedes habilitar la verificación de implementación (verify: true). Si lo haces, se habilita un trabajo verify en cada fase.

  • PREDEPLOY_ACTION

    Es igual que el ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar antes de la implementación.

  • POSTDEPLOY_ACTION

    Es el mismo que el ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar después de la implementación.

Cloud Run

En la etapa de canalización, incluye una propiedad strategy, como se indica a continuación:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

En esta configuración…

  • PERCENTAGES es una lista separada por comas de valores porcentuales que representan tus incrementos Canary, por ejemplo, [25, 50, 75]. Ten en cuenta que esto no incluye 100, ya que se supone que la implementación del 100% se realiza en Canary y la controla la fase stable.

  • Puedes habilitar la verificación de implementación (verify: true). Si lo haces, se agregará un trabajo verify a cada fase canaria.

  • PREDEPLOY_ACTION

    Es igual que el ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar antes de la implementación.

  • POSTDEPLOY_ACTION

    Es el mismo que el ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar después de la implementación.

Configura una versión canary personalizada

Puedes configurar tu canario de forma manual en lugar de depender por completo de la automatización que proporciona Cloud Deploy. Con la configuración personalizada de canary, debes especificar lo siguiente en la definición de tu canalización de publicación:

  • Nombres de las fases de lanzamiento

    En un canario completamente automatizado, Cloud Deploy asigna nombres a las fases por ti (canary-25, canary-75, stable, por ejemplo). Sin embargo, con un canario personalizado, puedes asignarle cualquier nombre a cada fase, siempre que sea único entre todas las fases de esta etapa del canario y cumpla con las restricciones de nombres de recursos. Sin embargo, el nombre de la fase final (100%) debe ser stable.

  • Objetivos porcentuales para cada fase

    Especifica los porcentajes por separado, por fase.

  • Perfiles de Skaffold que se usarán para la fase

    Puedes usar un perfil de Skaffold independiente para cada fase, el mismo perfil o cualquier combinación. Además, cada perfil puede usar un manifiesto de Kubernetes diferente o una definición de servicio de Cloud Run. También puedes usar más de un perfil para una fase determinada. Cloud Deploy las combina.

  • Indica si hay un trabajo de verificación para la fase.

    Recuerda que, si habilitas la verificación, también debes configurar tu skaffold.yaml para la verificación.

  • Si hay trabajos previos o posteriores a la implementación para la fase

    Si habilitas trabajos previos o posteriores a la implementación, debes configurar tu skaffold.yaml para esos trabajos.

Todos los tipos de segmentación son compatibles con Canary personalizado.

Elementos de configuración de versión canary personalizados

En el siguiente YAML, se muestra la configuración de las fases de la implementación canary completamente personalizada:

strategy:
  canary:
    # Custom configuration for each canary phase
    customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"

En este YAML

  • PHASE1_NAME

    Es el nombre de la fase. Cada nombre de fase debe ser único.

  • [ "PROFILE_NAME" ]

    Es el nombre del perfil que se usará para la fase. Puedes usar el mismo perfil para cada fase, uno diferente para cada una o cualquier combinación. Además, puedes especificar más de un perfil. Cloud Deploy usa todos los perfiles que especifiques, además del perfil o manifiesto que usa la etapa general.

  • stable

    La fase final debe llamarse stable.

  • PERCENTAGE1

    Es el porcentaje que se implementará para la primera fase. Cada fase debe tener un valor de porcentaje único, y ese valor debe ser un porcentaje entero (no 10.5, por ejemplo), y las fases deben estar en orden ascendente.

  • verify: true|false

    Le indica a Cloud Deploy si se debe incluir un trabajo de verificación para la fase. Ten en cuenta que, para que cada fase use la verificación, Skaffold usa el mismo perfil para la verificación que se especifica para la renderización y la implementación de esa fase.

  • PREDEPLOY_ACTION

    Es igual que el ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar antes de la implementación.

  • POSTDEPLOY_ACTION

    Es el mismo que el ACTION_NAME que usaste en tu skaffold.yaml para definir la acción personalizada que deseas ejecutar después de la implementación.

El porcentaje de la última fase debe ser 100. Las fases se ejecutan según el orden en que las configuras en esta estrofa ​customCanaryDeployment, pero si los valores de porcentaje no están en orden ascendente, el comando para registrar la canalización de publicación falla con un error.

Ten en cuenta que la configuración de un canario personalizado no incluye una stanza runtimeConfig. Si incluyes runtimeConfig, se considera un canario personalizado y automatizado.

Configura una versión canary automatizada personalizada

Un canario personalizado automatizado es similar a un canario personalizado porque especificas las fases de canario separadas, con nombres de fases personalizados, valores de porcentaje, perfiles de Skaffold, trabajos de verificación y trabajos de preimplementación y postimplementación. Sin embargo, con un canario personalizado, no proporcionas las configuraciones que definen la distribución del tráfico. Cloud Deploy lo hace por ti, pero debes proporcionar los perfiles de Skaffold que se usarán para cada etapa.

Para configurar una versión canary automatizada personalizada, incluye una estrofa runtimeConfig, como se muestra aquí, y la estrofa customCanaryDeployment, como se muestra aquí.

Configura una implementación de versiones canary con la malla de servicios de la API de Kubernetes Gateway

Si bien puedes usar una implementación de versiones canary de Cloud Deploy para implementar tu aplicación en las herramientas de redes basadas en servicios de Kubernetes, una alternativa es usar la malla de servicios de la API de la puerta de enlace de Kubernetes. En esta sección, se describe cómo hacerlo.

Puedes usar la API de Gateway con Istio o cualquier implementación compatible.

  1. Configura tus recursos de la API de Gateway:

    Estos son solo ejemplos.

  2. En el manifiesto de Kubernetes que proporcionaste a Cloud Deploy cuando creaste la versión, incluye lo siguiente:

    • Un HTTPRoute que hace referencia a tu recurso de puerta de enlace

    • Una Deployment

    • Un servicio

  3. Configura la canalización de entrega y el destino al que implementarás la canalización de detección de fallos:

    • La configuración del objetivo es la misma que para cualquier otro objetivo.

    • La configuración de la canalización de lanzamiento, en la secuencia de progresión del objetivo específico, incluye una estrofa gatewayServiceMesh para hacer referencia a la configuración de HTTPRoute de la API de Kubernetes Gateway, así como a tu Deployment y servicio.

      strategy:
 canary:
   runtimeConfig:
     kubernetes:
       gatewayServiceMesh:
         httpRoute: "ROUTE"
         service: "SERVICE"
         deployment: "DEPLOYMENT"
         routeUpdateWaitTime: "WAIT_TIME"
         podSelectorLabel: "LABEL"
   canaryDeployment:
     percentages:
     - 50

      En el ejemplo anterior, se ilustra lo siguiente:

      • ROUTE es tu configuración de httpRoute que define el comportamiento de enrutamiento que deseas.

      • SERVICE es la configuración de tu servicio, que Cloud Deploy requiere para las implementaciones Canary en GKE y GKE Enterprise.

      • DEPLOYMENT es la configuración de Deployment que Cloud Deploy requiere para las implementaciones Canary en GKE y GKE Enterprise.

      • WAIT_TIME es la cantidad de tiempo que Cloud Deploy debe esperar a que se propaguen los cambios en el recurso HTTPRoute para evitar que se descarten las solicitudes. Por ejemplo: routeUpdateWaitTime: 60s.

        Si ejecutas Canary con la API de Gateway sin Istio, y la API de Gateway está conectada a un balanceador de cargas de Google Cloud, es posible que se pierda una pequeña cantidad de tráfico cuando se reduzca la escala de la instancia de Canary. Puedes configurar este parámetro si observas este comportamiento.

      • LABEL es una etiqueta de selector de pods. Debe coincidir con el selector de etiquetas en el servicio y la Deployment de Kubernetes definidos en tu manifiesto. Esto es opcional. El valor predeterminado es app.

Usa la implementación en paralelo con una estrategia de implementación de versiones canary

Puedes ejecutar una implementación de versiones canary con la implementación en paralelo. Esto significa que el objetivo al que implementas de forma progresiva puede incluir dos o más objetivos secundarios. Por ejemplo, puedes implementar de forma progresiva en clústeres de regiones separadas al mismo tiempo.

Diferencias entre un canario en paralelo y uno de un solo objetivo

  • Al igual que con la implementación de versiones canary de un solo objetivo, si realizas implementaciones en objetivos de GKE, necesitas una configuración de implementación de Kubernetes y una configuración de servicio de Kubernetes en tu manifiesto.

  • Al igual que con la implementación de versiones canary de un solo objetivo, la configuración de la canalización de entrega debe incluir una estrofa strategy.canary dentro de la definición de la etapa aplicable.

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

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

    Ambos tipos de lanzamientos (controlador y secundario) tienen fases separadas para todos los porcentajes de Canary configurados y una fase stable para el 100% de Canary.

  • No puedes avanzar un lanzamiento secundario.

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

  • No puedes reintentar trabajos fallidos en el lanzamiento del controlador.

    Solo puedes reintentar una tarea en los lanzamientos secundarios.

  • No puedes ignorar trabajos con errores en la implementación del controlador.

    Solo puedes ignorar los trabajos con errores en los lanzamientos secundarios.

  • Puedes cancelar un lanzamiento de controlador, pero no puedes cancelar los lanzamientos secundarios.

  • Puedes finalizar ejecuciones de trabajos solo en un lanzamiento secundario, no en un lanzamiento del controlador.

Qué hacer si falla un lanzamiento en paralelo en Canary

Cuando falla un lanzamiento secundario, el lanzamiento del controlador puede pasar a diferentes estados, según lo que suceda con los lanzamientos secundarios:

  • Si uno o más lanzamientos secundarios fallan, pero al menos uno de ellos sigue en IN_PROGRESS, el lanzamiento del controlador seguirá en IN_PROGRESS.

  • Si uno o más lanzamientos secundarios fallan, pero al menos uno se realiza correctamente, el lanzamiento del controlador es HALTED si hay más fases después de la actual.

    Si esta es la fase stable, el lanzamiento del controlador es FAILED.

    HALTED te permite ignorar, volver a intentar los trabajos fallidos dentro del lanzamiento secundario con errores o cancelar el lanzamiento del controlador y evitar más acciones en los lanzamientos secundarios.

  • Si el lanzamiento del controlador está en un estado HALTED debido a un lanzamiento secundario con errores y ignoras el trabajo con errores en el lanzamiento secundario, el lanzamiento del controlador vuelve a un estado IN_PROGRESS.

Implementa una HTTPRoute en un clúster diferente

Cuando tienes un canario configurado con la malla de servicios de la API de Gateway, puedes especificar un clúster alternativo que no sea de destino en el que implementar HTTPRoute.

Para ello, usa una estrofa routeDestinations, en la configuración de tu estrategia de canario, para identificar el clúster o los clústeres de destino de HTTPRoute y un parámetro de configuración booleano para propagar el servicio al mismo clúster que no es de destino. Además, creas una estrofa associatedEntities en la configuración de destino para identificar los clústeres.

  1. Configura associatedEntities en tu destino.

    Cada entidad es un clúster en el que Cloud Deploy implementará HTTPRoute y, de manera opcional, el servicio de Kubernetes. En tu definición de destino, incluye una estrofa associatedEntities:

    associatedEntities:
  [KEY]:
    gkeClusters:
    - cluster: [PATH]
      internalIp: [true|false]
      proxyUrl:

    Aquí:

    • KEY es un nombre arbitrario para este grupo de entidades asociadas. Usarás este nombre para hacer referencia a las entidades de routeDestinations en tu configuración canary.

    • PATH es la ruta de acceso del recurso que identifica el clúster de GKE en el que se implementará tu HTTPRoute (y, de manera opcional, el servicio).

    • internalIp indica si deseas usar o no la IP interna (IP privada) si el clúster tiene configurada una IP interna y una IP pública. El valor predeterminado false.

    Puedes incluir cualquier cantidad de clústeres, con o sin internalIp.

  2. Configura routeDestinations en tu configuración canary.

    Cada destino de ruta hace referencia a una estrofa associatedEntities y indica si también se debe implementar el servicio en el clúster alternativo. Agrega lo siguiente dentro de la estrofa gatewayServiceMesh en tu configuración canary:

    routeDestinations:
  destinationIds: ["KEY"]
  propagateService: [true|false]

    Aquí:

    • KEY es el nombre que configuraste en el destino, en associatedEntities. Usa este nombre para hacer referencia a las entidades de routeDestinations en tu configuración Canary.

      También puedes proporcionar el valor @self para implementar HTTPRoute en el clúster de destino, además del destino asociado.

    • propagateService indica si deseas implementar el servicio en el clúster asociado, además de la HTTPRoute. El valor predeterminado es false.

Ejecuta la versión canary configurada

Para ejecutar la implementación de versiones canary, haz lo siguiente:

  1. Registra la canalización de entrega y los destinos configurados.

    gcloud deploy apply --file=PIPELINE

    La canalización de publicación incluye la configuración de Canary automatizada o personalizada para el entorno de ejecución que elijas.

    Este comando supone que tus objetivos se definen en el mismo archivo o que ya se registraron. De lo contrario, asegúrate de registrar tus objetivos también.

  2. Crea una versión:

    gcloud deploy releases create RELEASE_NAME \
                              --delivery-pipeline=PIPELINE_NAME \
                              --region=REGION

    La canalización de entrega que identifica PIPELINE_NAME contiene la configuración de canary automatizada o personalizada que se describe en este documento.

  3. Avanza la versión canary:

    gcloud CLI 

    gcloud deploy rollouts advance ROLLOUT_NAME \
                            --release=RELEASE_NAME \
                            --delivery-pipeline=PIPELINE_NAME \
                            --region=REGION

    Aquí:

    ROLLOUT_NAME es el nombre del lanzamiento actual al que avanzas a la siguiente fase.

    RELEASE_NAME es el nombre de la versión de la que forma parte esta implementación.

    PIPELINE_NAME es el nombre de la canalización de entrega que usas para administrar la implementación de esta versión.

    REGION es el nombre de la región en la que se creó la versión, por ejemplo, us-central1. Este campo es obligatorio.

    Consulta la referencia del SDK de Google Cloud para obtener más información sobre el comando gcloud deploy rollouts advance.

    Consola de Google Cloud

    1. Abre la página Canalizaciones de entrega.

    2. Haz clic en tu canalización que se muestra en la lista de canalizaciones de publicación.

      La página Detalles de la canalización de entrega muestra una representación gráfica del progreso de tu canalización de entrega.

    3. En la pestaña Lanzamientos, en Detalles de la canalización de publicación, haz clic en el nombre de tu lanzamiento.

      Se mostrará la página de detalles del lanzamiento.

      detalles del lanzamiento en la consola de Google Cloud

      Observa que, en este ejemplo, el lanzamiento tiene una fase canary-50 y una fase stable. Es posible que el lanzamiento tenga más fases o fases diferentes.

    4. Haz clic en Adelantar lanzamiento.

      El lanzamiento pasa a la siguiente fase.

Fases omitidas

Si implementas una canary y tu aplicación aún no se implementó en ese tiempo de ejecución, Cloud Deploy omite la fase canary y ejecuta la fase estable. Consulta Cómo omitir fases la primera vez para descubrir por qué sucede esto.

¿Qué sigue?