Esta página foi traduzida pela API Cloud Translation.

Implementações de testes beta para o GKE e o GKE Enterprise com a rede da API Gateway

Este documento descreve como configurar e usar implementações canary para implementar as suas aplicações no GKE ou no GKE Enterprise através do Cloud Deploy com a malha de serviços da API Gateway do Kubernetes.

Uma implementação canária é uma implementação progressiva de uma nova versão da sua aplicação, em que aumenta gradualmente a percentagem de tráfego enviado para a nova versão, enquanto monitoriza o desempenho da aplicação. Isto ajuda a detetar potenciais problemas antecipadamente e a minimizar o impacto nos seus utilizadores.

Como funcionam as implementações de testes beta para o GKE e o GKE Enterprise com a API Gateway

Além das referências de implementação e serviço, fornece um recurso HTTPRoute com uma regra backendRefs que faz referência ao serviço.
O Cloud Deploy cria uma nova implementação com o nome da implementação original mais -canary e um novo serviço com o nome do serviço original mais -canary.

Os segredos, os ConfigMaps e os redimensionadores automáticos horizontais de pods também são copiados e mudados de nome com -canary.
Para cada fase de teste canário, o Cloud Deploy modifica o HTTPRoute para atualizar a ponderação entre os pods da implementação original e os pods da implementação canária, com base na percentagem dessa fase.

Uma vez que pode haver um atraso na propagação das alterações aos recursos HTTPRoute, pode incluir a propriedade routeUpdateWaitTime na sua configuração, para que o sistema aguarde um período especificado para esta propagação.
Durante a fase stable, a implementação -canary é reduzida a zero e a implementação original é atualizada para usar a implementação do novo lançamento.

Além disso, o HTTPRoute é agora revertido para o original que forneceu.

O Cloud Deploy não modifica a implementação nem o serviço originais até à fase stable.

Com o Cloud Deploy, pode configurar implementações canary para o GKE e o GKE Enterprise numa única fase ou em várias fases.

As instruções aqui incluem apenas o que é específico da configuração de testes canários. O documento Implemente num cluster do Google Kubernetes Engine tem as instruções gerais para configurar e executar o pipeline de implementação.

Certifique-se de que tem as autorizações necessárias

Além de outras autorizações de gestão de identidades e acessos necessárias para usar o Cloud Deploy, precisa das seguintes autorizações para realizar ações adicionais que podem ser necessárias para uma implementação canary:

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

Consulte as funções e autorizações de IAM para mais informações sobre as funções disponíveis que incluem estas autorizações.

Prepare o seu `skaffold.yaml`

O ficheiro skaffold.yaml define como os seus manifestos do Kubernetes são renderizados e implementados. Para uma implementação canary no GKE/GKE Enterprise, certifique-se de que aponta corretamente para os seus manifestos e define todos os artefactos de compilação necessários. Não é necessária nenhuma configuração especial específica do teste canário no próprio skaffold.yaml, além do que é necessário para uma implementação padrão. Pode usar perfis do Skaffold para gerir diferentes variações de manifestos para fases de testes canários personalizados.

Prepare os manifestos do Kubernetes

Os seus manifestos do Kubernetes têm de incluir um recurso Deployment e um recurso Service. O Service tem de definir um selector que corresponda às etiquetas dos agrupamentos geridos pelo Deployment. A etiqueta predefinida que o Cloud Deploy procura é app, mas pode ser configurada no pipeline.

Além dos elementos Deployment e Service, os seus manifestos têm de incluir um recurso HTTPRoute configurado para a divisão de tráfego, que faça referência ao elemento Service e ao gateway associado.

Configure um teste canário automatizado

Use a API Kubernetes Gateway (com o Istio ou qualquer implementação suportada) para uma divisão de tráfego precisa baseada em percentagens gerida pela malha/gateway, orquestrada pelo Cloud Deploy.

Configure os recursos da API Gateway: certifique-se de que o gateway e a malha de serviços subjacente (por exemplo, O Istio) ou o controlador de gateway estão configurados corretamente nos seus clusters.
- Usar o Istio
- Controlador do GKE Gateway
No manifesto do Kubernetes, fornecido ao Cloud Deploy quando criou o lançamento, inclua o seguinte:
- Um HTTPRoute que faz referência ao seu recurso Gateway
- Uma implementação
- Um serviço
Configure o pipeline de implementação e o destino para o qual vai fazer a implementação canary:
- A configuração do destino é igual à de qualquer destino.
- A configuração do pipeline de entrega, na sequência de progressão para o destino específico, inclui uma secção gatewayServiceMesh para referenciar a configuração da API Kubernetes Gateway HTTPRoute, bem como a implementação e o serviço.
```
strategy:
 canary:
   runtimeConfig:
     kubernetes:
       gatewayServiceMesh:
         httpRoute: "ROUTE"
         service: "SERVICE"
         deployment: "DEPLOYMENT"
         routeUpdateWaitTime: "WAIT_TIME"
         podSelectorLabel: "LABEL"
   canaryDeployment:
     percentages:
     - 50
```
  Onde…
  - ROUTE é a configuração httpRoute que define o comportamento de encaminhamento pretendido.
  - SERVICE é a configuração do serviço, que o Cloud Deploy requer para implementações de teste canário no GKE e no GKE Enterprise.
  - DEPLOYMENT é a configuração de implementação, que o Cloud Deploy requer para implementações canary no GKE e GKE Enterprise.
  - WAIT_TIME é um período durante o qual o Cloud Deploy aguarda que as alterações ao recurso HTTPRoute terminem a propagação, para evitar pedidos rejeitados. Por exemplo: routeUpdateWaitTime: 60s.
    
    Se estiver a executar o canary com a API Gateway sem o Istio e a API Gateway estiver ligada a um Google Cloud equilibrador de carga, pode perder uma pequena quantidade de tráfego quando a instância canary é reduzida. Pode configurar esta definição se observar este comportamento.
  - LABEL é uma etiqueta de seletor de pod. Tem de corresponder ao seletor de etiquetas no serviço e na implementação do Kubernetes definidos no manifesto. Esta ação é opcional. A predefinição é app.

Configure um canary automatizado personalizado

Isto combina a definição de fases personalizadas (nomes, percentagens, perfis, validação, hooks) com a gestão de tráfego automática do Cloud Deploy para o GKE ou o GKE Enterprise. Define as fases, mas o Cloud Deploy processa a manipulação de recursos subjacente com base nas percentagens e no runtimeConfig escolhido.

Para configurar esta opção, inclua uma secção runtimeConfig com serviceNetworking e a secção customCanaryDeployment (que define phaseConfigs) no bloco strategy.canary. O Cloud Deploy usa os perfis do Skaffold especificados para a renderização, mas ajusta automaticamente o tráfego de acordo com as percentagens de runtimeConfig e de fases.

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

Implemente um HTTPRoute num cluster diferente

Quando tem um teste canary configurado através da malha de serviços da API Gateway, pode especificar um cluster alternativo que não seja o de destino no qual implementar o HTTPRoute.

Para tal, usa uma secção routeDestinations na configuração da estratégia de teste canário para identificar o cluster ou os clusters de destino para o HTTPRoute e uma definição booleana para propagar o serviço ao mesmo cluster não de destino. Além disso, cria uma secção associatedEntities na configuração de destino para identificar os clusters.

Configure o associatedEntities no seu alvo.

Cada entidade é um cluster onde o Cloud Deploy implementa o HTTPRoute e, opcionalmente, o serviço Kubernetes. Na definição do destino, inclua uma secção associatedEntities:
```
associatedEntities:
  [KEY]:
    gkeClusters:
    - cluster: [PATH]
      dnsEndpoint: [true|false]
      internalIp: [true|false]
      proxyUrl:
```
Onde:
- KEY é um nome arbitrário para este grupo de entidades associadas. Vai usar este nome para fazer referência às entidades do routeDestinations na sua configuração de teste.
- PATH é o caminho do recurso que identifica o cluster do GKE onde a HTTPRoute (e, opcionalmente, o serviço) vai ser implementada.
- dnsEndpoint indica se deve ou não usar o endpoint DNS do cluster se estiverem configurados vários endpoints. A predefinição é false.
- internalIp indica se deve ou não usar o IP interno (IP privado) do cluster se estiverem configurados vários pontos finais. A predefinição é false.
Pode incluir qualquer número de clusters, com ou sem internalIp.
Configure routeDestinations na configuração de teste beta.

Cada destino de rota faz referência a uma secção associatedEntities e indica se o serviço também deve ser implementado no cluster alternativo. Adicione o seguinte dentro da secção gatewayServiceMesh na configuração de teste canário:
```
routeDestinations:
  destinationIds: ["KEY"]
  propagateService: [true|false]
```
Onde:
- KEY é o nome que configurou no destino, em associatedEntities. Use este nome para fazer referência às entidades do routeDestinations na sua configuração canary.
  
  Também pode fornecer o valor @self para implementar o HTTPRoute no cluster de destino, além do destino associado.
- propagateService indica se quer ou não implementar o serviço no cluster associado, além do HTTPRoute. O valor predefinido é false.

Execute o teste canary do GKE ou GKE Enterprise

Registe o pipeline e os alvos: aplique os ficheiros de configuração do pipeline de entrega e do alvo do GKE ou GKE Enterprise.
```
gcloud deploy apply --file=delivery-pipeline.yaml --region=REGION
gcloud deploy apply --file=gke-targets.yaml --region=REGION
```
O pipeline de implementação inclui a configuração canary automática ou personalizada para o tempo de execução escolhido.

Crie uma versão: inicie a implementação, indicando 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 canary automatizada ou personalizada descrita neste documento.

Avançar o teste:
CLI gcloud
```
gcloud deploy rollouts advance ROLLOUT_NAME \
                            --release=RELEASE_NAME \
                            --delivery-pipeline=PIPELINE_NAME \
                            --region=REGION
```
Onde:

ROLLOUT_NAME é o nome da implementação atual que está a avançar para a fase seguinte.

RELEASE_NAME é o nome do lançamento do qual esta implementação faz parte.

PIPELINE_NAME é o nome do pipeline de entrega que está a usar para gerir a implementação deste lançamento.

REGION é o nome da região em que o lançamento foi criado, por exemplo, us-central1. Este campo é obrigatório.

Consulte a referência do Google Cloud SDK para mais informações acerca do comando gcloud deploy rollouts advance.
Google Cloud consola
1. Abra a página Pipelines de fornecimento.
2. Clique no pipeline apresentado na lista de pipelines de fornecimento.
  
  A página de detalhes do pipeline de fornecimento mostra uma representação gráfica do progresso do pipeline de fornecimento.
3. No separador Implementações, em Detalhes do pipeline de fornecimento, clique no nome da implementação.
  
  É apresentada a página de detalhes da implementação para essa implementação.
  
  Repare que, neste exemplo, a implementação tem uma fase canary-50 e uma fase stable. A implementação pode ter mais fases ou fases diferentes.
4. Clique em Avançar implementação.
  
  A implementação avança para a fase seguinte.

Fases ignoradas

Se implementar uma versão canary e a sua aplicação ainda não tiver sido implementada nesse tempo de execução, o Cloud Deploy ignora a fase canary e executa a fase estável. Consulte a secção Ignorar fases na primeira vez para saber por que motivo isto acontece.

O que se segue?

Experimente o início rápido da implementação canary.
Saiba como gerir o ciclo de vida das implementações de testes beta.
Saiba mais sobre a implementação em paralelo.
Saiba mais sobre as estratégias de implementação do Cloud Deploy.