O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Implantações canárias no GKE e em clusters anexados do GKE usando a rede da API Gateway

Este documento descreve como configurar e usar implantações canário para implantar seus aplicativos no GKE ou em clusters anexados do GKE usando o Cloud Deploy com a malha de serviço da API Gateway do Kubernetes.

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 com antecedência e minimizar o impacto nos usuários.

Como as implantações canário funcionam para o GKE e os clusters anexados ao GKE usando a API Gateway

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.
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.

Secrets, ConfigMaps e escalonadores automáticos horizontais de pods também são copiados e renomeados com -canary.
Para cada fase de canary, o Cloud Deploy modifica a HTTPRoute para atualizar a ponderação entre os pods da implantação original e os pods da implantação de canary, com base na porcentagem dessa fase.

Como pode haver um atraso na propagação de mudanças nos recursos do HTTPRoute, inclua a propriedade routeUpdateWaitTime na sua configuração para que o sistema aguarde um período especificado por essa propagação.
Durante a fase stable, a implantação -canary é reduzida a zero, e a implantação original é atualizada para usar a implantação da nova versão.

Além disso, a HTTPRoute foi 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.

Com o Cloud Deploy, é possível configurar implantações canário em clusters do GKE e anexados do GKE 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 ou em clusters anexados do GKE, verifique se o arquivo skaffold.yaml aponta corretamente para seus manifestos e define os artefatos de build necessários. Não é necessária nenhuma configuração especial específica do canário em skaffold.yaml além do que é necessário para uma implantação padrão. Também é possível 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 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.

Além de Deployment e Service, seus manifestos precisam incluir um recurso HTTPRoute configurado para divisão de tráfego, fazendo referência ao Service e ao gateway associado.

Configurar um teste canário automatizado

Use a API Kubernetes Gateway (com Istio ou qualquer implementação compatível) para divisão de tráfego precisa e baseada em porcentagem gerenciada pela malha/gateway, orquestrada pelo Cloud Deploy.

Configure os recursos da API Gateway: verifique se o gateway e a malha de serviço subjacente (por exemplo, Istio) ou o controlador do gateway estão configurados corretamente nos clusters.
- Como usar o Istio
- GKE Gateway Controller
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
Configure o pipeline de entrega e o destino em que você vai fazer a implantação canário:
- A configuração para o destino é a mesma que 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 referenciar sua configuração da API Gateway do Kubernetes HTTPRoute, bem como sua implantação e 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 de serviço, que o Cloud Deploy exige para implantações canário em clusters anexados do GKE e do GKE.
  - DEPLOYMENT é a configuração de implantação, que o Cloud Deploy exige para implantações canário em clusters anexados ao GKE e ao GKE.
  - WAIT_TIME é um período para o Cloud Deploy aguardar a conclusão da propagação das mudanças no recurso HTTPRoute, para evitar solicitações descartadas. Por exemplo: routeUpdateWaitTime: 60s.
    
    Se você estiver executando o canary usando a API Gateway sem o Istio e a API Gateway estiver conectada a um balanceador de carga Google Cloud , uma pequena quantidade de tráfego poderá ser perdida quando a instância canary for reduzida. Configure essa opção se você observar esse comportamento.
  - LABEL é um rótulo de 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.

Configurar um teste canário personalizado e automatizado

Um canary personalizado e automatizado 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 clusters do GKE ou anexados ao GKE. 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 (definindo 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:
            gatewayServiceMesh:
              httpRoute: "my-route"
              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:
              tasks: []
            predeploy:
              tasks: []
            postdeploy:
              tasks: []
          - phaseId: "scaling"
            percentage: 50
            profiles: ["profile-b"] # Different profile for this phase
            verify:
              tasks: []
            predeploy:
              tasks: []
            postdeploy:
              tasks: []
          - phaseId: "stable"
            percentage: 100
            profiles: ["profile-b"] # Can reuse profiles
            verify:
              tasks: []
            predeploy:
              tasks: []
            postdeploy:
              tasks: []

Implantar um HTTPRoute em um cluster diferente

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

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

Configure associatedEntities no 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 seção associatedEntities:
```
associatedEntities:
  [KEY]:
    gkeClusters:
    - cluster: [PATH]
      dnsEndpoint: [true|false]
      internalIp: [true|false]
      proxyUrl:
```
Em que:
- KEY é um nome arbitrário para esse grupo de entidades associadas. Você vai usar esse nome para se referir às entidades do routeDestinations na sua configuração de teste canário.
- PATH é o caminho do recurso que identifica o cluster do GKE em que o HTTPRoute (e, opcionalmente, o serviço) será implantado.
- dnsEndpoint indica se o endpoint DNS do cluster deve ser usado se vários endpoints estiverem configurados. O padrão é false.
- internalIp indica se o IP interno (IP particular) do cluster deve ser usado ou não se vários endpoints estiverem configurados. O padrão é false.
É possível incluir qualquer número de clusters, com ou sem internalIp.
Configure routeDestinations na configuração canário.

Cada destino de rota faz referência a uma estrofe associatedEntities e indica se o serviço também precisa 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 configurado no destino, em associatedEntities. Use esse nome para fazer referência às entidades do routeDestinations na sua configuração canary.
  
  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 canary do GKE ou dos clusters anexados do GKE

Registrar pipeline e destinos: aplique o pipeline de entrega e os arquivos de configuração de destino do GKE ou dos clusters anexados ao GKE.
```
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.
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 implantação é mostrada.
  
  Neste exemplo, o lançamento tem uma fase canary-50 e uma fase stable. Seu 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 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 canários.
Saiba mais sobre a implantação paralela.
Saiba mais sobre as estratégias de implantação do Cloud Deploy.