Esta página foi traduzida pela API Cloud Translation.

Implantações canário no GKE e no GKE Enterprise usando redes baseadas em serviços

Neste documento, descrevemos como configurar e usar implantações canário para implantar aplicativos no GKE ou no GKE Enterprise usando o Cloud Deploy com redes baseadas em serviços.

Uma implantação canário é um lançamento progressivo de uma nova versão do aplicativo, em que você aumenta gradualmente a porcentagem de tráfego enviado para a nova versão, enquanto monitora o desempenho do aplicativo. Isso ajuda a detectar possíveis problemas antecipadamente e minimizar o impacto nos usuários.

Como as implantações canário funcionam para o GKE e o GKE Enterprise com rede baseada em serviços

Você fornece o nome do recurso de implantação e do recurso de serviço.
O Cloud Deploy cria um recurso de implantação adicional com o nome da implantação atual mais -canary.

Secrets e ConfigMaps também são copiados e renomeados com -canary.

O Cloud Deploy modifica o serviço para ajustar o seletor e selecionar os pods na implantação atual e os 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 na seção de provisionamento de pods. Esse cálculo varia dependendo de você ativar ou desativar o superprovisionamento de pods.

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

O Cloud Deploy cria uma implantação que inclui a porcentagem de pods específica da fase, 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 exata de tráfego, use a API Gateway.
Durante a fase stable, a implantação -canary é reduzida a zero, e a implantação original é substituída pela nova.

O Cloud Deploy não modifica a implantação original até a fase stable, a menos que você desative o superprovisionamento.

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

Para o canary 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 serem provisionados para a implantação canário em cada fase.

Provisionamento de pods com superprovisionamento ativado

Ao ativar o provisionamento excessivo (disablePodOverprovisioning: false), o Cloud Deploy pode criar pods adicionais suficientes para executar a porcentagem de canary desejada, com base no número de pods que executam sua 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 overprovisioning de pods está ativado:

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

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

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

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

Provisionamento de pods com 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 pods para a implantação canário em cada fase canário quando o overprovisioning de pods está desativado:

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

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

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

Com o Cloud Deploy, é possível configurar implantações canário no GKE e no GKE Enterprise em uma única etapa ou em várias etapas.

As instruções aqui incluem apenas o que é específico da configuração de canary. O documento Implantar em um cluster do Google Kubernetes Engine tem as instruções gerais para configurar e executar seu 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 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 seu `skaffold.yaml`

O arquivo skaffold.yaml define como os manifestos do Kubernetes são renderizados e implantados. Para uma implantação canário no GKE/GKE Enterprise, verifique se ela aponta corretamente para seus manifestos e define os artefatos de build necessários. Não é necessária nenhuma configuração específica do canary no skaffold.yaml além do que é necessário para uma implantação padrão. Você pode usar perfis do Skaffold para gerenciar diferentes variações de manifesto em fases canário personalizadas.

Preparar manifestos do Kubernetes

Os manifestos do Kubernetes precisam incluir um recurso Deployment e um recurso Service. O Service precisa definir um selector que corresponda aos rótulos dos pods gerenciados pelo Deployment. O rótulo padrão que o Cloud Deploy procura é app, mas isso pode ser configurado no pipeline.

Configurar um teste canário automatizado

Configure um canary automatizado diretamente na definição do pipeline de entrega para uma etapa específica do GKE ou do GKE Enterprise usando a rede de serviços padrão do Kubernetes.

Na etapa 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"
              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 sua implantação do Kubernetes, definida no manifesto.
LABEL é um rótulo de 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 percentuais que representam seus incrementos de canário, por exemplo, [5, 25, 50].

Além disso, isso não inclui 100, porque a implantação de 100% é presumida no canary e é processada pela fase stable.
Você pode ativar a verificação de implantação (verify: true). Se 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.

Configurar um canário personalizado

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

Nomes das fases de lançamento

Em um canary totalmente automatizado, o Cloud Deploy nomeia as fases para você (canary-25, canary-75, stable, por exemplo). Com um canary personalizado, você pode dar qualquer nome a cada fase, desde que seja exclusivo entre todas as fases desse estágio canary e respeite as restrições de ID de recurso. mas o nome da fase final (100%) precisa ser stable.
Metas de porcentagem 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. Cada perfil pode usar um manifesto diferente do Kubernetes. Também é possível usar mais de um perfil para uma determinada fase. O Cloud Deploy combina os dois.
Se há um job de verificação para a fase

Se você estiver ativando a verificação, configure seu skaffold.yaml para verificação também.
Se há jobs de pré-implantação ou pós-implantação para a fase

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

Todos os tipos de destino são compatíveis com o canary personalizado.

Elementos de configuração canário personalizados

O YAML a seguir mostra a configuração das fases de implantação canário totalmente 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"

Neste YAML

PHASE1_NAME

É o nome da fase. Cada nome de fase precisa ser exclusivo.
[ "PROFILE_NAME" ]

É o nome do perfil a ser usado na 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 etapa geral.
stable

A fase final precisa ser chamada de stable.
PERCENTAGE1

É a porcentagem a ser implantada na primeira fase. Cada fase precisa ter um valor de porcentagem exclusivo, que precisa ser um número inteiro (não 10.5, por exemplo), e as fases precisam estar em ordem crescente.
verify: true|false

Informa ao Cloud Deploy se deve incluir um job de verificação para a fase. Para que cada fase use a verificação, o Skaffold usa o mesmo perfil para verificação especificado para renderização e implantação dessa 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 na ordem em que você as configura nesta seção customCanaryDeployment, mas 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 canary personalizado não inclui uma seção runtimeConfig. Se você incluir runtimeConfig, ele será considerado um canário personalizado baseado em serviço.

Configurar um teste canário automatizado personalizado

Isso combina a definição de fase personalizada (nomes, porcentagens, perfis, verificação, hooks) com o gerenciamento automático de tráfego do Cloud Deploy para GKE ou GKE Enterprise. Você define as fases, mas o Cloud Deploy processa a manipulação de recursos subjacentes com base nas porcentagens e no runtimeConfig escolhido.

Para configurar isso, inclua uma seção runtimeConfig com serviceNetworking e a seção customCanaryDeployment (que define phaseConfigs) no bloco strategy.canary. O Cloud Deploy vai usar os perfis do Skaffold especificados para renderização, mas vai ajustar automaticamente o tráfego de acordo com as porcentagens de runtimeConfig e fase.

serialPipeline:
  stages:
  - targetId: gke-prod
    profiles: []
    strategy:
      canary:
        # Include runtimeConfig for automatic traffic management
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "my-app"
              deployment: "my-deployment"
        # Include customCanaryDeployment for phase customization
        customCanaryDeployment:
          phaseConfigs:
          - phaseId: "warmup"
            percentage: 10
            profiles: ["profile-a"] # Profile used for rendering this phase
            verify: true
          - phaseId: "scaling"
            percentage: 50
            profiles: ["profile-b"] # Different profile for this phase
            verify: true
          - phaseId: "stable"
            percentage: 100
            profiles: ["profile-b"] # Can reuse profiles
            verify: true

Executar o canary do GKE ou do GKE Enterprise

Registrar pipeline e destinos: aplique o pipeline de entrega e os arquivos de configuração de destino do GKE ou do GKE Enterprise.
```
gcloud deploy apply --file=delivery-pipeline.yaml --region=REGION
gcloud deploy apply --file=gke-targets.yaml --region=REGION
```
O pipeline de entrega inclui a configuração canário automatizada ou personalizada para o ambiente de execução escolhido.

Crie um lançamento: inicie a implantação fornecendo o nome da imagem.


gcloud deploy releases create RELEASE_NAME \
                                --delivery-pipeline=PIPELINE_NAME \
                                --region=REGION
  # e.g., --images=my-cloudrun-service=gcr.io/my-project/my-app:v1.1
  # Add --skaffold-file or --source if not using default Skaffold config discovery

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

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 de que este lançamento faz parte.

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.
Google Cloud console
1. Abra a página "Pipelines de entrega".
2. Clique no pipeline mostrado na lista de pipelines de entrega.
  
  A página "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.
  
  Neste exemplo, o lançamento tem uma fase canary-50 e uma fase stable. Sua implantação 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 canary e o aplicativo ainda não tiver sido implantado nesse ambiente de execução, o Cloud Deploy vai pular a fase canary e executar a fase estável. Consulte Pular fases na primeira vez para saber por que isso acontece.

A seguir

Confira o guia de início rápido da implantação canário.
Saiba como gerenciar o ciclo de vida dos rollouts do seu canary.
Saiba mais sobre a implantação paralela.
Saiba mais sobre as estratégias de implantação do Cloud Deploy.