Usar uma estratégia de implantação canário

Este documento descreve como configurar e usar uma estratégia de implantação canário.

O que é uma implantação canário?

Uma implantação canário é um lançamento progressivo de um aplicativo que divide o tráfego entre uma versão já implantada e uma nova, lançando-a para um subconjunto de usuários antes do lançamento completo.

Tipos de destino compatíveis

A implantação canário no Cloud Deploy é compatível com todos os tipos de destino, incluindo os seguintes:

O Canary também funciona com vários alvos.

Por que usar uma estratégia de implantação canário?

Uma implantação canário oferece a chance de lançar parcialmente o aplicativo. Dessa forma, você pode garantir que a nova versão do aplicativo seja confiável antes de entregá-la a todos os usuários.

Se você estiver implantando no GKE ou no GKE Enterprise, por exemplo, implante a nova versão do aplicativo em um número limitado de pods. A versão antiga continuaria sendo executada, mas com mais tráfego sendo enviado para os novos pods.

Se você estiver implantando no Cloud Run, ele mesmo vai dividir o tráfego entre as revisões antigas e novas, de acordo com as porcentagens configuradas.

Tipos de canário

O Cloud Deploy permite configurar os seguintes tipos de implantação canário:

  • Automatizado

    Com uma implantação canário automatizada, você configura o Cloud Deploy com uma série de porcentagens que expressam uma implantação progressiva. O Cloud Deploy realiza outras operações em seu nome para distribuir as porcentagens de tráfego entre a versão antiga e a nova.

  • Personalizado e automatizado

    Para um teste canário personalizado-automatizado, você pode fornecer o seguinte:

    • O nome da fase
    • A meta percentual
    • O perfil do Skaffold a ser usado para a fase
    • Se é necessário incluir ou não um job de verificação
    • Se é necessário incluir um job de pré-implantação ou pós-implantação ou ambos

    Mas você não precisa fornecer informações de balanceamento de tráfego. O Cloud Deploy cria os recursos necessários.

  • Personalizado

    Com um canário personalizado, você configura cada fase separadamente, incluindo o seguinte:

    • O nome da fase
    • A meta percentual
    • O perfil do Skaffold a ser usado para a fase
    • Se é necessário incluir ou não um job de verificação
    • Se é necessário incluir um job de pré-implantação ou pós-implantação ou ambos

    Além disso, para um canário totalmente personalizado, você fornece toda a configuração de balanceamento de tráfego, conforme descrito aqui.

Fases de uma implantação canário

Quando você cria uma versão para uma implantação Canary, o lançamento é criado com uma fase para cada incremento Canary, além de uma fase stable final para 100%.

Por exemplo, se você configurar um canário para incrementos de 25%, 50% e 75%, o lançamento terá as seguintes fases:

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

Leia mais sobre as fases de lançamento, jobs e execuções de jobs em Gerenciar lançamentos.

O que acontece durante um canário automático ou automático personalizado

Para oferecer suporte à implantação de canário, o Cloud Deploy inclui etapas de processamento especiais ao renderizar o manifesto do Kubernetes ou a configuração do serviço do Cloud Run:

GKE/Enterprise

Confira como o Cloud Deploy executa uma implantação canário no GKE e no GKE Enterprise baseados na rede:

  1. Você fornece o nome do recurso de implantação e do recurso de serviço.

  2. O Cloud Deploy cria um recurso de implantação adicional com o nome da implantação atual e -canary.

  3. O Cloud Deploy modifica o serviço para ajustar o seletor e selecionar os pods na implantação atual e nos pods canário.

    O Cloud Deploy calcula o número de pods a serem usados para o canário com base no cálculo descrito aqui. Esse cálculo é diferente se você ativa ou desativa o overprovisionamento de pods.

    Se estivermos pulando para a fase stable, o Cloud Deploy vai adicionar os rótulos a serem usados para corresponder aos pods, para que eles fiquem disponíveis para execuções canário subsequentes.

    O Cloud Deploy cria uma implantação que inclui a porcentagem específica da fase dos pods, atualizando-a para cada fase. Isso é feito calculando o número de pods como uma porcentagem do número original de pods. Isso pode resultar em uma divisão de tráfego imprecisa. Se você precisar de uma divisão de tráfego exata, use a API Gateway.

    Além disso, os Secrets e ConfigMaps também são copiados e renomeados com -canary.

  4. Durante a fase stable, a implantação -canary é reduzida para zero, e a implantação original é substituída pela nova.

    O Cloud Deploy não modifica a implantação original até a fase stable.

O Cloud Deploy provisiona pods para alcançar a porcentagem de canário solicitada o mais próximo possível. Isso é baseado no número de pods, não no tráfego para os pods. Se você quiser que o canário seja baseado no tráfego, use a API Gateway.

Para o canário baseado em rede do GKE, é possível ativar ou desativar o provisionamento excessivo de pods. As seções a seguir descrevem como o Cloud Deploy calcula o número de pods a provisionar para a implantação canário em cada fase.

Provisionamento de pods com o superprovisionamento ativado

Ativar o provisionamento excessivo (disablePodOverprovisioning: false) permite que o Cloud Deploy crie pods adicionais suficientes para executar a porcentagem de canário desejada com base no número de pods que executam a implantação atual. A fórmula a seguir mostra como o Cloud Deploy calcula o número de pods a serem provisionados para a implantação canário em cada fase, quando o provisionamento excessivo de pods está ativado:

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

Com essa fórmula, o contagem de réplicas atual (o número de pods que você já tem, antes desse canário) é multiplicado pela porcentagem do canário para a fase, e o resultado é dividido por (100 menos a porcentagem).

Por exemplo, se você já tiver quatro pods e a fase de canário for de 50%, o número de pods de canário será 4. O resultado de 100-percentage é usado como uma porcentagem: 100-50=50, tratado como .50.

O comportamento padrão é o provisionamento excessivo de pods.

Provisionamento de pods com o superprovisionamento desativado

É possível desativar o provisionamento excessivo (disablePodOverprovisioning: true), para garantir que o Cloud Deploy não aumente a contagem de réplicas.

A fórmula a seguir mostra como o Cloud Deploy calcula o provisionamento de pod para a implantação de canário de cada fase de canário, quando o provisionamento excessivo de pod está desativado:

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

Nessa fórmula, ReplicaCountOfCanaryDeploymentOnCluster só existe se já houver uma fase de canário. Se esta for a primeira fase de canário, não haverá ReplicaCountOfCanaryDeploymentOnCluster.

Se você começar com quatro pods, esse número será multiplicado pela porcentagem do canário (por exemplo, 50% ou .5) para gerar 2. Assim, a implantação original é reduzida para dois pods, e dois novos pods são criados para a implantação canário. Se você tiver um estágio de canário de 75%, terá 2 (implantação original) +2 (primeiro estágio de canário), *.75, para que os pods de canário 3 e 1 executem a implantação original.

Gateway GKE/Enterprise

Confira como o Cloud Deploy executa uma implantação canário no GKE e no GKE Enterprise usando a API Gateway:

  1. Além das referências de implantação e serviço, você fornece um recurso HTTPRoute com uma regra backendRefs que faz referência ao serviço.

  2. O Cloud Deploy cria uma nova implantação com o nome da implantação original mais -canary e um novo serviço com o nome do serviço original mais -canary.

    Além disso, os Secrets, ConfigMaps e escalonadores automáticos de pods horizontais também são copiados e renomeados com -canary.

  3. Para cada fase de canário, o Cloud Deploy modifica o HTTPRoute para atualizar o peso entre os pods da implantação original e os pods da implantação de canário com base na porcentagem dessa fase.

    Como pode haver um atraso na propagação de mudanças para recursos HTTPRoute, é possível incluir a propriedade routeUpdateWaitTime na configuração para que o sistema aguarde um período especificado para essa propagação.

  4. Durante a fase stable, a implantação -canary é reduzida para zero, e a implantação original é atualizada para usar a implantação do novo lançamento.

    Além disso, a HTTPRoute agora é revertida para a original que você forneceu.

    O Cloud Deploy não modifica a implantação ou o serviço original até a fase stable.

Cloud Run

Confira como o Cloud Deploy executa uma implantação canário para o Cloud Run:

  • Para uma implantação canário no Cloud Run, não forneça uma traffic stanza no YAML do serviço.

  • Ao criar um novo lançamento para canário, o Cloud Deploy divide o tráfego entre a revisão anterior que foi implantada pelo Cloud Deploy e uma nova revisão.

Se você quiser saber as diferenças entre as fases de uma implantação canário, confira as mudanças no manifesto renderizado por fase disponível no Release Inspector. Isso pode ser feito antes mesmo do início do lançamento. Além disso, se você estiver usando a implantação paralela, também poderá inspecionar o manifesto renderizado de cada filho.

Configurar uma implantação canário

Esta seção descreve como configurar o pipeline de entrega e os destinos para uma implantação canário.

As instruções aqui incluem apenas o que é específico para a configuração canário. O documento Implantar seu aplicativo tem as instruções gerais para configurar e executar o pipeline de implantação.

Verifique se você tem as permissões necessárias

Além das outras permissões do Identity and Access Management necessárias para usar o Cloud Deploy, você precisa das seguintes permissões para realizar outras ações que podem ser necessárias para uma implantação canário:

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

Consulte Papéis e permissões do IAM para mais informações sobre quais papéis disponíveis incluem essas permissões.

Prepare o skaffold.yaml

Assim como em uma implantação padrão, o canário precisa de um arquivo skaffold.yaml, que define como os manifestos e as definições de serviço são renderizados e implantados.

O skaffold.yaml criado para uma implantação canário não tem requisitos especiais além do necessário para a implantação padrão.

Preparar a definição de manifesto ou serviço

Assim como em uma implantação padrão, o canário precisa de um manifesto do Kubernetes ou de uma definição de serviço do Cloud Run.

GKE e GKE Enterprise

Para o canário, seu manifesto precisa ter o seguinte:

  • Uma implantação e um serviço.

  • O serviço precisa definir um seletor, e esse seletor precisa selecionar os pods da implantação especificada. O padrão é app.

  • Se você estiver usando um canário baseado na API Gateway, o manifesto também precisará ter um HTTPRoute.

Cloud Run

Para o canário no Cloud Run, o arquivo de definição de serviço normal do Cloud Run é suficiente, mas sem uma estrofe traffic. O Cloud Deploy gerencia a divisão do tráfego entre a última revisão bem-sucedida e a nova.

Configurar um canário automático

As instruções a seguir são para o Cloud Run e alvos de rede baseados em serviço do GKE e do GKE Enterprise. Se você estiver usando a API Kubernetes Gateway com o GKE ou o GKE Enterprise, consulte esta documentação.

Configure o teste canário automatizado na definição do pipeline de entrega:

GKE e GKE Enterprise

No estágio do pipeline, inclua uma propriedade strategy, conforme mostrado abaixo:

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"

Nesta configuração,

  • SERVICE_NAME é o nome do serviço do Kubernetes, definido no manifesto.

  • DEPLOYMENT_NAME é o nome da implantação do Kubernetes, definido no manifesto.

  • LABEL é um rótulo do seletor de pod. Ele precisa corresponder ao seletor de rótulos no serviço do Kubernetes definido no manifesto. Isso é opcional. O padrão é app.

  • PERCENTAGES é uma lista separada por vírgulas de valores de porcentagem que representam os incrementos de canário, por exemplo, [5, 25, 50].

    Além disso, isso não inclui 100, porque a implantação de 100% é presumenda no canário e é processada pela fase stable.

  • É possível ativar a verificação de implantação (verify: true). Se você fizer isso, um job verify será ativado em cada fase.

  • PREDEPLOY_ACTION

    É o mesmo que o ACTION_NAME usado no skaffold.yaml para definir a ação personalizada que você quer executar antes da implantação.

  • POSTDEPLOY_ACTION

    É o mesmo que o ACTION_NAME usado no skaffold.yaml para definir a ação personalizada que você quer executar após a implantação.

Cloud Run

No estágio do pipeline, inclua uma propriedade strategy, conforme mostrado abaixo:

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"

Nesta configuração,

  • PERCENTAGES é uma lista separada por vírgulas de valores de porcentagem que representam os incrementos de canário, por exemplo, [25, 50, 75]. Observe que isso não inclui 100, porque a implantação de 100% é presumenda no canário e é processada pela fase stable.

  • É possível ativar a verificação de implantação (verify: true). Se você fizer isso, um job verify será adicionado a cada fase de canário.

  • PREDEPLOY_ACTION

    É o mesmo que o ACTION_NAME usado no skaffold.yaml para definir a ação personalizada que você quer executar antes da implantação.

  • POSTDEPLOY_ACTION

    É o mesmo que o ACTION_NAME usado no skaffold.yaml para definir a ação personalizada que você quer executar após a implantação.

Configurar um canário personalizado

É possível configurar o canário manualmente, em vez de depender totalmente da automatização fornecida pelo Cloud Deploy. Com a configuração de canário personalizado, especifique o seguinte na definição do pipeline de entrega:

  • Nomes das fases de lançamento

    Em um canário totalmente automatizado, o Cloud Deploy nomeia as fases para você (canary-25, canary-75, stable, por exemplo). No entanto, com um canário personalizado, é possível dar a cada fase qualquer nome, desde que ele seja exclusivo entre todas as fases desse estágio do canário e respeite as restrições de nome de recurso. Mas o nome da fase final (100%) precisa ser stable.

  • Metas percentuais para cada fase

    Especifique as porcentagens separadamente, por fase.

  • Perfis do Skaffold a serem usados na fase

    É possível usar um perfil do Skaffold separado para cada fase, o mesmo perfil ou qualquer combinação. E cada perfil pode usar uma definição de serviço do Kubernetes ou do Cloud Run diferente. Também é possível usar mais de um perfil para uma determinada fase. O Cloud Deploy combina esses recursos.

  • Se há um job de verificação para a fase

    Se você ativar a verificação, também precisará configurar o skaffold.yaml para verificação.

  • Se há jobs de pré-implantação ou pós-implantação para a fase

    Se você estiver ativando jobs de pré-implantação ou pós-implantação, será necessário configurar o skaffold.yaml para esses jobs.

Todos os tipos de destino são compatíveis com o canário personalizado.

Elementos de configuração canário personalizados

O YAML a seguir mostra a configuração para os estágios de implantação de canário totalmente personalizados:

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"

Neste YAML

  • PHASE1_NAME

    É o nome da fase. Cada nome de fase precisa ser exclusivo.

  • [ "PROFILE_NAME" ]

    É o nome do perfil a ser usado para a fase. Você pode usar o mesmo perfil para cada fase, um diferente para cada uma ou qualquer combinação. Além disso, é possível especificar mais de um perfil. O Cloud Deploy usa todos os perfis especificados, além do perfil ou manifesto usado pela fase geral.

  • stable

    A fase final precisa ser nomeada como stable.

  • PERCENTAGE1

    É a porcentagem a ser implantada na primeira fase. Cada fase precisa ter um valor de porcentagem exclusivo, e esse valor precisa ser uma porcentagem inteira (não 10.5, por exemplo), e as fases precisam estar em ordem crescente.

  • verify: true|false

    Informa ao Cloud Deploy se é necessário incluir um job de verificação para a fase. Para cada fase usar a verificação, o Skaffold usa o mesmo perfil de verificação especificado para renderização e implantação para essa fase.

  • PREDEPLOY_ACTION

    É o mesmo que o ACTION_NAME usado no skaffold.yaml para definir a ação personalizada que você quer executar antes da implantação.

  • POSTDEPLOY_ACTION

    É o mesmo que o ACTION_NAME usado no skaffold.yaml para definir a ação personalizada que você quer executar após a implantação.

A porcentagem da última fase precisa ser 100. As fases são executadas de acordo com a ordem em que você as configura nesta estrofe ​customCanaryDeployment. No entanto, se os valores de porcentagem não estiverem em ordem crescente, o comando para registrar o pipeline de entrega vai falhar com um erro.

A configuração de um canário personalizado não inclui uma estrofe runtimeConfig. Se você incluir runtimeConfig, ele será considerado um canário automatizado personalizado.

Configurar um canário automático personalizado

Um canário automatizado personalizado é semelhante a um canário personalizado, porque você especifica as fases de canário separadas, com nomes de fases personalizados, valores de porcentagem, perfis do Skaffold, jobs de verificação e jobs de pré-implantação e pós-implantação. No entanto, com um canário personalizado, você não fornece as configurações que definem a alocação de tráfego. O Cloud Deploy faz isso para você, mas você ainda fornece os perfis do Skaffold para serem usados em cada fase.

Para configurar um canário personalizado automatizado, inclua uma estrofe runtimeConfig, conforme mostrado aqui, e inclua a estrofe customCanaryDeployment, conforme mostrado aqui.

Configurar uma implantação canário usando a malha de serviço da API Gateway do Kubernetes

Embora seja possível usar uma implantação canário do Cloud Deploy para implantar seu aplicativo em uma rede baseada em serviço do Kubernetes, uma alternativa é usar a malha de serviço da API Gateway do Kubernetes. Esta seção mostra como fazer isso.

É possível usar a API Gateway com o Istio ou qualquer implementação com suporte.

  1. Configure os recursos da API Gateway:

    Estes são apenas exemplos.

  2. No manifesto do Kubernetes, fornecido ao Cloud Deploy quando você criou a versão, inclua o seguinte:

    • Um HTTPRoute que faz referência ao recurso de gateway

    • Uma implantação

    • Um serviço

  3. Configure o pipeline de entrega e o destino para o qual você vai fazer o deploy canário:

    • A configuração do destino é a mesma para qualquer destino.

    • A configuração do pipeline de entrega, na sequência de progressão para o destino específico, inclui uma estrofe gatewayServiceMesh para fazer referência à sua configuração HTTPRoute da API Gateway do Kubernetes, bem como à sua implantação e ao serviço.

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

      Em que…

      • ROUTE é a configuração httpRoute que define o comportamento de roteamento desejado.

      • SERVICE é a configuração do serviço, que o Cloud Deploy exige para implantações canário no GKE e no GKE Enterprise.

      • DEPLOYMENT é a configuração de implantação, que o Cloud Deploy exige para implantações canário no GKE e no GKE Enterprise.

      • WAIT_TIME é o tempo que o Cloud Deploy leva para esperar que as mudanças no recurso HTTPRoute sejam concluídas para evitar solicitações perdidas. Por exemplo: routeUpdateWaitTime: 60s.

        Se você estiver executando o canário usando a API Gateway sem o Istio e a API Gateway estiver conectada a um balanceador de carga do Google Cloud, uma pequena quantidade de tráfego poderá ser perdida quando a instância do canário for reduzida. É possível configurar essa configuração se você observar esse comportamento.

      • LABEL é um rótulo do seletor de pod. Ele precisa corresponder ao seletor de rótulos no serviço e na implantação do Kubernetes definidos no manifesto. Isso é opcional. O padrão é app.

Usar a implantação paralela com uma estratégia de implantação canário

É possível executar uma implantação canário usando a implantação paralela. Isso significa que o destino para o qual você está implantando progressivamente pode incluir dois ou mais destinos filhos. Por exemplo, é possível implantar de forma progressiva em clusters em regiões separadas ao mesmo tempo.

Qual é a diferença entre um canário paralelo e um de único alvo

  • Assim como na implantação canário de destino único, se você estiver implantando para destinos do GKE, precisará de uma configuração de implantação do Kubernetes e uma configuração de serviço do Kubernetes no manifesto.

  • Assim como na implantação de canário de destino único, a configuração do pipeline de entrega precisa incluir uma estrofe strategy.canary dentro da definição de estágio para o estágio aplicável.

  • Além disso, é necessário configurar um destino múltiplo e configurar os destinos filhos a que o destino múltiplo faz referência.

  • Quando você cria uma versão, um lançamento do controlador e os lançamentos filhos são criados.

    Os dois tipos de lançamento, controlador e filho, têm fases separadas para todas as porcentagens de canário configuradas e uma fase stable para o canário 100%.

  • Não é possível avançar um lançamento filho.

    Só é possível avançar os lançamentos de controladores. Quando você avança o lançamento do controlador para a próxima fase, os lançamentos filhos também são avançados pelo Cloud Deploy.

  • Não é possível repetir jobs com falha no lançamento do controlador.

    Só é possível tentar novamente um job em lançamentos filhos.

  • Não é possível ignorar jobs com falha no lançamento do controlador.

    Só é possível ignorar jobs com falha em lançamentos filhos.

  • É possível cancelar um lançamento de controlador, mas não é possível cancelar lançamentos filhos.

  • É possível encerrar as execuções de job apenas em um lançamento filho, não em um lançamento do controlador.

O que fazer se um lançamento paralelo falhar no canário

Quando um lançamento filho falha, o lançamento do controlador pode fazer a transição para diferentes estados, dependendo do que acontece com os lançamentos filhos:

  • Se um ou mais lançamentos filhos falharem, mas pelo menos um lançamento filho ainda estiver IN_PROGRESS, o lançamento do controlador vai permanecer IN_PROGRESS.

  • Se um ou mais lançamentos filhos falharem, mas pelo menos um lançamento filho tiver sucesso, o lançamento do controlador será HALTED se houver mais fases após a atual.

    Se esta for a fase stable, o lançamento do controlador será FAILED.

    HALTED permite que você ignore, tente novamente jobs com falha no lançamento filho com falha ou cancele o lançamento do controlador e evite outras ações nos lançamentos filhos.

  • Se o lançamento do controlador estiver em um estado HALTED devido a um lançamento filho com falha e você ignorar o job com falha no lançamento filho, o lançamento do controlador será revertido para um estado IN_PROGRESS.

Implantar um HTTPRoute em um cluster diferente

Quando você tem um canário configurado usando a malha de serviço da API Gateway, é possível especificar um cluster alternativo que não é de destino para implantar o HTTPRoute.

Para fazer isso, use uma estrofe routeDestinations na configuração da estratégia de canário para identificar o cluster de destino ou clusters para o HTTPRoute e uma configuração booleana para propagar o serviço para o mesmo cluster não de destino. E você cria uma estrofe associatedEntities na configuração de destino para identificar os clusters.

  1. Configure associatedEntities no seu destino.

    Cada entidade é um cluster em que o Cloud Deploy implanta a HTTPRoute e, opcionalmente, o serviço do Kubernetes. Na definição de destino, inclua uma estrofe associatedEntities:

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

    Em que:

    • KEY é um nome arbitrário para esse grupo de entidades associadas. Use esse nome para fazer referência às entidades do routeDestinations na configuração do canário.

    • PATH é o caminho do recurso que identifica o cluster do GKE em que o HTTPRoute (e, opcionalmente, o serviço) será implantado.

    • internalIp indica se você quer usar ou não o IP interno (IP particular) se o cluster tiver um IP interno e um IP público configurados. O padrão é false.

    É possível incluir qualquer número de clusters, com ou sem internalIp.

  2. Configure routeDestinations na configuração do canário.

    Cada destino de rota faz referência a uma estrofe associatedEntities e indica se o serviço também será implantado no cluster alternativo. Adicione o seguinte à estrofe gatewayServiceMesh na configuração do Canary:

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

    Em que:

    • KEY é o nome que você configurou no destino, em associatedEntities. Use esse nome para fazer referência às entidades do routeDestinations na configuração do canário.

      Você também pode fornecer o valor @self para implantar o HTTPRoute no cluster de destino, além do destino associado.

    • propagateService indica se você quer implantar o serviço no cluster associado, além do HTTPRoute. O padrão é false.

Executar o canário configurado

Para executar a implantação canário:

  1. Registre o pipeline de entrega e os destinos configurados.

    gcloud deploy apply --file=PIPELINE

    O pipeline de envio inclui a configuração canário automática ou personalizada para o ambiente de execução escolhido.

    Esse comando pressupõe que os destinos são definidos no mesmo arquivo ou já foram registrados. Caso contrário, registre também suas metas.

  2. Criar uma versão:

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

    O pipeline de entrega identificado por PIPELINE_NAME contém a configuração de teste canário automatizada ou personalizada descrita neste documento.

  3. Avançar o canário:

    CLI da gcloud 

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

    Em que:

    ROLLOUT_NAME é o nome do lançamento atual que você está avançando para a próxima fase.

    RELEASE_NAME é o nome da versão a que este lançamento pertence.

    PIPELINE_NAME é o nome do pipeline de entrega que você está usando para gerenciar a implantação dessa versão.

    REGION é o nome da região em que a versão foi criada, por exemplo, us-central1. Obrigatório.

    Consulte a referência do SDK Google Cloud para mais informações sobre o comando gcloud deploy rollouts advance.

    Console do Google Cloud

    1. Abra a página "Pipelines de entrega".

    2. Clique no pipeline mostrado na lista de pipelines de entrega.

      A página de detalhes do pipeline de entrega mostra uma representação gráfica do progresso do pipeline de entrega.

    3. Na guia Lançamentos, em Detalhes do pipeline de entrega, clique no nome do lançamento.

      A página de detalhes da implementação é mostrada.

      Detalhes do lançamento no console do Google Cloud

      Observe que, neste exemplo, o lançamento tem uma fase canary-50 e uma stable. O lançamento pode ter mais fases ou fases diferentes.

    4. Clique em Continuar lançamento.

      O lançamento é avançado para a próxima fase.

Fases ignoradas

Se você implantar um canário e o aplicativo ainda não tiver sido implantado nesse ambiente de execução, o Cloud Deploy vai pular a fase de canário e executar a fase estável. Consulte Pular fases na primeira vez para descobrir por que isso acontece.

A seguir