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

Neste documento, descrevemos 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 para um subconjunto de usuários antes do lançamento completo.

Tipos de segmentação compatíveis

A implantação canário no Cloud Deploy dá suporte a todos os tipos de destino, incluindo o seguinte:

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

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

Uma implantação canário oferece a chance de lançar parcialmente seu aplicativo. Em Dessa forma, é possível garantir que a nova versão do aplicativo seja confiável antes entregá-lo a todos os usuários.

Se você estiver fazendo implantações no GKE ou no GKE Enterprise, exemplo, você implantaria a nova versão do aplicativo em um de pods. A versão antiga continuaria a funcionar, mas com mais tráfego que está sendo enviado para os novos pods.

Se você estiver implantando no Cloud Run, o Cloud Run divide o tráfego entre a revisão antiga e a nova, de acordo com a e porcentagens que você configurar.

Tipos de canário

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

  • Automatizado

    Com um canário automatizado você vai configurar o Cloud Deploy com uma série de percentuais que expressam uma implantação progressiva. Cloud Deploy realiza operações adicionais em seu nome, para distribuir o tráfego porcentagens entre a versão antiga e a nova.

  • Personalizado e automatizado

    Para um canário automatizado de modo personalizado, é possível fornecer o seguintes:

    • O nome da fase
    • A meta de porcentagem
    • O perfil do Skaffold a ser usado para a fase
    • Incluir ou não um job de verificação

    Mas não é preciso fornecer informações de balanceamento de tráfego. O Cloud Deploy cria os recursos necessários, conforme descrito aqui.

  • Personalizado

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

    • O nome da fase
    • A meta de porcentagem
    • O perfil do Skaffold a ser usado para a fase
    • Incluir ou não um job de verificação

    Além disso, para um canário totalmente personalizado, você fornece todos os 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 canário, o lançamento é criado com uma fase para cada incremento canário e uma fase stable final para 100%.

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

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

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

O que acontece durante um teste canário automatizado ou personalizado

Para dar suporte à implantação canário, o Cloud Deploy inclui recursos de processamento ao renderizar o manifesto do Kubernetes ou Configuração do serviço do Cloud Run:

GKE/Enterprise

Veja como o Cloud Deploy executa uma implantação canário em GKE baseado em rede e GKE Enterprise:

  1. Você fornece o nome dos recursos de implantação e de serviço.

  2. O Cloud Deploy cria outro recurso de implantação, o nome da implantação atual mais -canary;

  3. O Cloud Deploy modifica o serviço para ajustar o seletor para selecione 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 varia dependendo ative ou desative o provisionamento excessivo de pods.

    Se formos pular para a fase stable O Cloud Deploy adiciona os rótulos que serão usados para corresponder aos pods. elas vão estar disponíveis para execuções canário subsequentes.

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

    Além disso, 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 implantação.

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

O Cloud Deploy provisiona pods para alcançar o canário solicitado o mais próximo possível. Isso se baseia no número de pods, e não no tráfego para os pods. Para que a implantação canário seja baseada no tráfego, precisará usar a API Gateway.

Para o canário com base em rede do GKE, ativar ou desativar o superprovisionamento de pods. As seções a seguir descrevem como o Cloud Deploy calcula número de pods a serem provisionados para a implantação canário em cada fase canário.

Provisionamento de pods com superprovisionamento ativado

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

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

Com esta fórmula, a contagem atual de réplicas (o número de pods que você já têm, antes deste canário) é multiplicado pela porcentagem de canários para o e o resultado é dividido por (100 menos a porcentagem).

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

O superprovisionamento de pods é o comportamento padrão.

Provisionamento de pods com superprovisionamento desativado

É possível desativar o superprovisionamento (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 pod para a implantação canário em cada fase canário, quando o pod o superprovisionamento está desativado:

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

Nesta fórmula, ReplicaCountOfCanaryDeploymentOnCluster só existe se já havia uma fase canário. Se esta for a primeira fase canário, não é ReplicaCountOfCanaryDeploymentOnCluster.

Se você começar com quatro pods, esse número será multiplicado pela porcentagem de canários (por exemplo, 50% ou .5) para receber 2. A implantação original agora está com 2 pods, e 2 novos são criados para a implantação canário. Se você tem um estágio canário 75%, tem 2 (implantação original) +2 (primeiro estágio canário), *.75, para receber 3 pods canário e 1 pod que executa o implantação original.

Gateway GKE/Enterprise

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

  1. Além das referências à implantação e ao serviço, você fornece uma 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 a implantação original mais -canary, e um novo serviço com o Nome do serviço mais -canary.

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

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

    Como pode haver um atraso na propagação de mudanças em HTTPRoute recursos, você pode inclua a propriedade routeUpdateWaitTime no seu configuração, de modo que o sistema aguarda um período especificado por essa propagação.

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

    Além disso, o HTTPRoute foi revertido para o original que você forneceu.

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

Cloud Run

Veja 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 um traffic estrofe no YAML de serviço.

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

Para ver as diferenças entre as fases de uma implantação canário, podem visualizar as alterações no manifesto renderizado por fase disponível no release Inspector (link em inglês). Você pode fazer isso antes mesmo lançamento foi iniciado. Além disso, se você estiver usando implantação paralela, você também poderá inspecionar manifesto renderizado.

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 Implante seu aplicativo tem a instruções gerais para configurar e executar o pipeline de implantação.

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

Além de outras permissões do Identity and Access Management necessárias para usar Cloud Deploy, são necessárias as seguintes permissões para execute 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 os papéis e permissões do IAM. para mais informações sobre quais papéis disponíveis incluem essas permissões.

Prepare seu skaffold.yaml

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

O skaffold.yaml criado para uma implantação canário não tem além do que é necessário para os padrões implantação do Google Workspace.

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

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

GKE e GKE Enterprise

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

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

  • O serviço precisa definir um seletor app e selecionar os pods do Implantação especificada.

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

Cloud Run

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

Configurar um canário automatizado

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

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

GKE e GKE Enterprise

No estágio do pipeline, inclua uma propriedade strategy, da seguinte maneira:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false

Nesta configuração...

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

  • DEPLOYMENT_NAME é o nome do Kubernetes. Implantação, definida no manifesto.

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

    Além disso, isso não inclui 100, porque 100% da implantação está assumed no canário e é processada pelo stable.

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

Cloud Run

No estágio do pipeline, inclua uma propriedade strategy, da seguinte maneira:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false

Nesta configuração...

  • PERCENTAGES é uma lista de porcentagem separada por vírgulas valores que representam seus incrementos canário, por exemplo, [25, 50, 75]. Observação que não inclua 100, porque 100% da implantação está assumed no canário e é processada pelo stable.
  • É possível ativar a verificação da implantação. (verify: true). Se você fizer isso, um job verify será adicionado a cada fase canário.

Configurar um canário personalizado

É possível configurar seu canário manualmente em vez de depender totalmente do automatizada fornecida pelo Cloud Deploy. Com 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). Com um canário personalizado, No entanto, você pode dar a cada fase qualquer nome, desde que seja único entre todas as fases para este estágio canário e homenageia restrições de nome de recurso. Mas o último (100%) do nome da fase precisa ser stable.

  • Metas percentuais para cada fase

    Especifique as porcentagens separadamente, por fase.

  • Perfis do Skaffold a serem usados para a fase

    É possível usar um perfil do Skaffold separado para cada fase, ou o mesmo perfil, ou qualquer combinação. E cada perfil pode usar um manifesto diferente do Kubernetes ou do serviço do Cloud Run. 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, será preciso configure o skaffold.yaml para verificação também.

Todos os tipos de segmentação são compatíveis com canários personalizados.

Elementos personalizados de configuração canário

O YAML a seguir mostra a configuração das fases do canário totalmente personalizado implantação:

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

Neste YAML

  • PHASE1_NAME

    É o nome da fase. O nome de cada fase precisa ser único.

  • [ "PROFILE_NAME" ]

    É o nome do perfil a ser usado para a fase. Você pode usar o mesmo perfil para cada fase, ou uma para cada uma, ou qualquer combinação. Também é possível especifique mais de um perfil. O Cloud Deploy usa perfis especificados, além do perfil ou manifesto usado pelo usuário fase de

  • PERCENTAGE1

    É a porcentagem de implantação para a primeira fase. Cada fase deve ter um evento valor percentual, que deve ser uma porcentagem inteira (não 10.5, para exemplo), e as fases devem estar em ordem crescente.

  • verify: true|false

    Informa ao Cloud Deploy se precisa incluir um job de verificação para a fase. Observe que para cada fase a ser usada para verificar, o Skaffold usa o mesmo perfil para verificar o especificado para renderização e implantação nessa fase.

  • stable

    A fase final precisa ser nomeada como stable.

A porcentagem da última fase precisa ser 100. As fases são executadas de acordo na ordem em que você os configura nesta ​customCanaryDeployment estrofe, mas se os valores percentuais não estiverem em ordem crescente, o comando para registre o pipeline de entrega falha com um erro.

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

Configurar um canário automatizado personalizado

Um canário personalizado e automatizado é semelhante a um canário personalizado. porque você especifica as fases canário separadas, com nomes de fases personalizadas, valores percentuais, perfis do Skaffold e jobs de verificação. Com um canário personalizado, você não fornecer as configurações que definem a distribuição de tráfego. O Cloud Deploy faz isso mas você ainda fornece Perfis do Skaffold que será usado em cada etapa.

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

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

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

Você pode usar a API Gateway com o Istio ou qualquer implementação compatível.

  1. Configure os recursos da API Gateway:

    Esses 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 da implantação canário para:

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

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

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

      Em que…

      • ROUTE é a configuração de httpRoute que define o roteamento comportamento que você quer.

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

      • DEPLOYMENT é a configuração da implantação, que O Cloud Deploy exige que as implantações canário GKE e GKE Enterprise.

      • WAIT_TIME é um tempo necessário para que o Cloud Deploy aguardar a conclusão da propagação das alterações no recurso HTTPRoute para evitar o descarte de solicitações. Por exemplo: routeUpdateWaitTime: 60s.

        Se você estiver executando a versão canário usando a API Gateway sem o Istio, e o está conectada a um balanceador de carga do Google Cloud, o tráfego pode ser perdido quando a instância canário for reduzida. Você pode defina essa configuração se observar esse comportamento.

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 que você está implantando progressivamente pode abranger dois ou mais destinos filhos. Por exemplo, é possível implantar progressivamente em clusters em locais ao mesmo tempo.

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

  • Assim como na implantação canário de destino único, se você estiver implantando em destinos do GKE, você precisa 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 canário de destino único, a configuração do pipeline de entrega precisa incluir uma estrofe de strategy.canary dentro da definição da etapa para o estágio aplicável.

  • Além disso, você precisa configurar vários destinos, e você precisa configure os destinos filhos que esse destino faz referência.

  • Ao criar 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 dos controladores. Quando você avança o controle do lançamento para a próxima etapa, os lançamentos filhos também serão avançados, Cloud Deploy.

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

    Só é possível executar um job novamente 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 o lançamento de um controlador, mas não é possível cancelar lançamentos filhos.

  • Você pode encerrar execuções de jobs somente 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 dependendo do que acontece com os lançamentos filhos:

  • Se um ou mais lançamentos filhos falharem, mas pelo menos um deles ainda estiver IN_PROGRESS, o lançamento do controlador continua sendo IN_PROGRESS.

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

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

    HALTED oferece a você a chance de ignorar, tentar de novo jobs com falha no lançamento filho com falha ou cancelar o lançamento do controle e impedir outras ações nos lançamentos filhos.

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

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 entrega inclui a configuração canário automatizada ou personalizada, para o ambiente de execução escolhido.

    Esse comando pressupõe que seus destinos estão definidos no mesmo arquivo ou têm já foi registrado. Caso contrário, registre seus destinos também.

  2. Crie 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 canário personalizada ou automática 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 que deste lançamento faz parte.

    PIPELINE_NAME é o nome da entrega. pipeline usado para gerenciar a implantação desta versão.

    REGION é o nome da região em que o 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 da o andamento do pipeline de entrega.

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

      A página de detalhes do lançamento é exibida.

      detalhes do lançamento no console do Google Cloud

      Neste exemplo, o lançamento tem uma fase canary-50 e uma stable. Seu lançamento pode ter mais fases ou diferentes fases.

    4. Clique em Avançar o lançamento.

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

Fases ignoradas

Se você implantar um canário e seu aplicativo não tiver sido implantado nesse o ambiente de execução atual, o Cloud Deploy ignora a fase canário e executa a versão fase de testes. Consulte Como pular fases na primeira vez. para descobrir por que isso acontece.

A seguir