O Cloud Service Mesh e o Traffic Director são agora o Cloud Service Mesh. Para mais informações, consulte a vista geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

Aprovisione o Cloud Service Mesh gerido com o asmcli

Vista geral

O Managed Cloud Service Mesh com asmcli é um plano de controlo gerido e um plano de dados gerido que configura facilmente. A Google processa a fiabilidade, as atualizações, o dimensionamento e a segurança por si de forma retrocompatível. Este guia explica como configurar ou migrar aplicações para a malha de serviços na nuvem gerida numa configuração de cluster único ou múltiplo com o asmcli.

Para saber mais sobre as funcionalidades suportadas e as limitações da malha de serviços na nuvem gerida, consulte o artigo Funcionalidades suportadas da malha de serviços na nuvem gerida.

Pré-requisitos

Como ponto de partida, este guia pressupõe que:

Um projeto na nuvem
Uma conta do Cloud Billing
Obteve as autorizações necessárias para aprovisionar a Cloud Service Mesh
A ferramenta de instalação asmcli, o kpt e outras ferramentas especificadas em Instale as ferramentas necessárias

Para um aprovisionamento mais rápido, os seus clusters têm de ter a identidade de carga de trabalho ativada. Se o Workload Identity não estiver ativado, o aprovisionamento ativa-o automaticamente.

Requisitos

Um ou mais clusters com uma versão suportada do GKE numa das regiões suportadas.
Tenha em atenção que o Cloud Service Mesh gerido usa canais de lançamento do GKE para equilibrar a estabilidade e a velocidade de atualização. As novas alterações aos componentes no cluster do Cloud Service Mesh (incluindo CNI, MDPC, proxies e CRDs do Istio) são implementadas primeiro nos clusters que subscrevem o canal rápido do GKE. Em seguida, são promovidos ao canal normal do GKE e, finalmente, ao canal estável do GKE, assim que demonstrarem estabilidade suficiente.
- A prática recomendada é aprovisionar um subconjunto dos clusters da sua frota num canal de lançamento do GKE anterior para garantir que recebem primeiro atualizações dos componentes do Cloud Service Mesh.
- O Managed Cloud Service Mesh não suporta a alteração dos canais de lançamento do GKE.
- Se alterar o canal de lançamento do GKE, o Cloud Service Mesh não impede a operação. O Cloud Service Mesh atualiza automaticamente os componentes no cluster (CNI, MDPC, versão do proxy injetado predefinida e CRDs do Istio) para se alinharem com o canal de lançamento do GKE atual.
Certifique-se de que o cluster tem capacidade suficiente para os componentes necessários que o Cloud Service Mesh gerido instala no cluster.
- A implementação mdp-controller no espaço de nomes kube-system pede cpu: 50m, memória: 128Mi.
- O istio-cni-node daemonset no espaço de nomes kube-system pede cpu: 100m, memory: 100Mi em cada nó.
Certifique-se de que a política organizacional constraints/compute.disableInternetNetworkEndpointGroup está desativada. Se a política estiver ativada, o ServiceEntry pode não funcionar.
Certifique-se de que a máquina cliente a partir da qual aprovisiona o Cloud Service Mesh gerido tem conectividade de rede com o servidor da API.
Os seus clusters têm de estar registados numa frota. Este passo pode ser feito separadamente antes do aprovisionamento ou como parte do aprovisionamento através da transmissão das flags --enable-registration e --fleet-id.
O seu projeto tem de ter a funcionalidade de frota do Service Mesh ativada. Pode ativá-lo como parte do aprovisionamento transmitindo --enable-gcp-components ou executando o seguinte comando:
```
gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
```
onde FLEET_PROJECT_ID é o ID do projeto do projeto anfitrião da frota.
O GKE Autopilot só é suportado com a versão 1.21.3 ou superior do GKE.
O Cloud Service Mesh pode usar vários clusters do GKE num ambiente de projeto único e rede única ou num ambiente de vários projetos e rede única.
- Se juntar clusters que não estão no mesmo projeto, estes têm de estar registados no mesmo projeto anfitrião da frota e os clusters têm de estar numa configuração de VPC partilhada em conjunto na mesma rede.
- Para um ambiente de vários clusters de projeto único, o projeto da frota pode ser igual ao projeto do cluster. Para mais informações sobre frotas, consulte o artigo Vista geral das frotas.
- Para um ambiente com vários projetos, recomendamos que aloje a frota num projeto separado dos projetos de cluster. Se as políticas organizacionais e a configuração existente o permitirem, recomendamos que use o projeto de VPC partilhada como o projeto anfitrião da frota. Para mais informações, consulte Configurar clusters com a VPC partilhada.
- Se a sua organização usar os VPC Service Controls e estiver a aprovisionar o Cloud Service Mesh em clusters do GKE com uma versão igual ou superior a 1.22.1-gke.10, pode ter de realizar passos de configuração adicionais:
  - Se estiver a aprovisionar a Cloud Service Mesh no canal de lançamento normal ou estável , tem de usar a flag --use-vpcsc adicional quando aplicar o plano de controlo gerido e seguir o guia dos VPC Service Controls (pré-visualização). Caso contrário, o aprovisionamento falha nos controlos de segurança.
  - Se estiver a aprovisionar a Cloud Service Mesh no canal de lançamento rápido, não precisa de usar a flag --use-vpcsc adicional quando aplicar o plano de controlo gerido, mas tem de seguir o guia dos VPC Service Controls (DG).

Funções necessárias para instalar o Cloud Service Mesh

A tabela seguinte descreve as funções necessárias para instalar o Cloud Service Mesh gerido.

Nome da função	ID da função	Conceda acesso à localização	Descrição
Administrador do GKE Hub	roles/gkehub.admin	Projeto do Fleet	Acesso total aos GKE Hubs e recursos relacionados.
Administrador de utilização do serviço	roles/serviceusage.serviceUsageAdmin	Projeto do Fleet	Capacidade de ativar, desativar e inspecionar estados de serviços, inspecionar operações e consumir quota e faturação para um projeto de consumidor. ^{(Note 1)}
Administrador de serviço de AC ^Beta	roles/privateca.admin	Projeto do Fleet	Acesso total a todos os recursos do serviço de AC. ^{(Note 2)}

Funções necessárias para executar o Cloud Service Mesh

A tabela seguinte descreve as funções necessárias para a conta de serviço executar o Cloud Service Mesh gerido. Se os projetos de rede ou cluster forem diferentes do projeto anfitrião da frota, tem de conceder à conta de serviço no projeto da frota acesso a estas funções nos outros projetos.

Nome da função	ID da função	Conceda acesso à localização	Descrição
Agente de serviço do Anthos Service Mesh	roles/anthosservicemesh.serviceAgent	Projeto do Fleet
Agente de serviço de plano de controlo gerido de malha (antigo)	roles/meshcontrolplane.serviceAgent	Projeto do Fleet	Esta é uma função antiga que fazia parte de instalações mais antigas do Cloud Service Mesh. Se a sua instalação tiver esta função de serviço, pode deixá-la como está. As novas instalações não precisam desta função.

Limitações

Recomendamos que reveja a lista de funcionalidades e limitações suportadas do Cloud Service Mesh. Em particular, tenha em atenção o seguinte:

A API IstioOperator não é suportada, uma vez que a sua finalidade principal é controlar os componentes no cluster.

Nota: ainda pode ativar funcionalidades opcionais sem usar a API IstioOperator. Consulte o artigo Ativar funcionalidades opcionais na malha de serviços na nuvem gerida. Também pode usar a ferramenta de migração incluída no asmcli para converter automaticamente outras funcionalidades opcionais do IstioOperator para serem compatíveis com o plano de controlo gerido. Para mais informações, consulte o artigo Migre de IstioOperator.
Para clusters do GKE Autopilot, a configuração entre projetos só é suportada com o GKE 1.23 ou posterior.
Para clusters do GKE Autopilot, para se adaptar ao limite de recursos do GKE Autopilot, os pedidos e os limites de recursos de proxy predefinidos estão definidos para 500 m de CPU e 512 MB de memória. Pode substituir os valores predefinidos através da injeção personalizada.
Para clusters do GKE Autopilot, podem ser apresentados avisos para os componentes do Cloud Service Mesh "DaemonSet has no nodes selected" até que o NodePool dos clusters seja dimensionado.
Durante o processo de aprovisionamento de um plano de controlo gerido, os CRDs do Istio são aprovisionados no cluster especificado. Se existirem CRDs do Istio no cluster, estes são substituídos.
O Istio CNI e o Cloud Service Mesh não são compatíveis com o GKE Sandbox. Por conseguinte, o Cloud Service Mesh gerido com a implementação TRAFFIC_DIRECTOR não suporta clusters com o GKE Sandbox ativado.
A ferramenta asmcli tem de ter acesso ao ponto final do Google Kubernetes Engine (GKE). Pode configurar o acesso através de um servidor de"salto", como uma VM do Compute Engine na nuvem virtual privada (VPC) que dá acesso específico.

Antes de começar

Configure o gcloud

Conclua os seguintes passos, mesmo que esteja a usar o Cloud Shell.

Autentique com a CLI do Google Cloud:
```
gcloud auth login --project PROJECT_ID
```
em que PROJECT_ID é o identificador exclusivo do seu projeto de cluster. Execute o seguinte comando para obter o seu PROJECT_ID:
```
   gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```
```
Atualize os componentes:
```
gcloud components update
```

Configure kubectl para apontar para o cluster.

gcloud container clusters get-credentials CLUSTER_NAME \
     --zone CLUSTER_LOCATION \
     --project PROJECT_ID

Transfira a ferramenta de instalação

Transfira a versão mais recente da ferramenta para o diretório de trabalho atual:
```
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
```
Torne a ferramenta executável:
```
chmod +x asmcli
```

Configure cada cluster

Use os passos seguintes para configurar o Cloud Service Mesh gerido para cada cluster na sua malha.

Aplique o plano de controlo gerido

Antes de aplicar o plano de controlo gerido, tem de selecionar um canal de lançamento. O seu canal do Cloud Service Mesh é determinado pelo canal do cluster do GKE no momento do aprovisionamento do Cloud Service Mesh gerido. Tenha em atenção que não é suportado ter vários canais no mesmo cluster ao mesmo tempo.

Execute a ferramenta de instalação para cada cluster que vai usar o Cloud Service Mesh gerido. Recomendamos que inclua ambas as opções seguintes:

--enable-registration --fleet_id FLEET_PROJECT_ID Estas duas flags registam o cluster numa frota, onde FLEET_ID é o ID do projeto do projeto anfitrião da frota. Se usar um único projeto, o FLEET_PROJECT_ID é igual a PROJECT_ID. O projeto anfitrião da frota e o projeto do cluster são iguais. Em configurações mais complexas, como vários projetos, recomendamos que use um projeto de anfitrião da frota separado.
--enable-all. Esta flag ativa os componentes e o registo necessários.

A ferramenta asmcliconfigura o plano de controlo gerido diretamente através de ferramentas e lógica no interior da ferramenta CLI. Use o conjunto de instruções abaixo consoante a AC preferencial.

Autoridades de certificação

Selecione uma autoridade de certificação para usar na sua malha.

Mesh CA

Execute o seguinte comando para instalar o plano de controlo com as funcionalidades predefinidas e a AC da malha. Introduza os seus valores nos marcadores de posição fornecidos.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all

Serviço de AC

Siga os passos em Configure o serviço de autoridade de certificação.
Execute o seguinte comando para instalar o plano de controlo com as funcionalidades predefinidas e o serviço de autoridade de certificação. Introduza os seus valores nos marcadores de posição fornecidos.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --ca gcp_cas \
      --ca_pool pool_name

A ferramenta transfere todos os ficheiros para configurar o plano de controlo gerido para o --output_dir especificado, instalando a ferramenta istioctl e as aplicações de exemplo. Os passos neste guia pressupõem que executa o comando istioctl a partir da localização que especificou quando executou o comando --output_dir, com o comando istioctl presente no respetivo subdiretório <Istio release dir>/bin.asmcli install

Se executar novamente asmcli no mesmo cluster, substitui a configuração do plano de controlo existente. Certifique-se de que especifica as mesmas opções e flags se quiser a mesma configuração.

Verifique se o plano de controlo foi aprovisionado

Após alguns minutos, verifique se o estado do plano de controlo é ACTIVE:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

O resultado é semelhante ao seguinte:

membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      ...
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'

Se o estado não atingir ACTIVE` em alguns minutos, consulte o artigo Verifique o estado do plano de controlo gerido para ver mais informações sobre possíveis erros.

Atualizações zero-touch

Assim que o plano de controlo gerido estiver instalado, a Google atualiza-o automaticamente quando estiverem disponíveis novas versões ou patches.

Plano de dados gerido

Se usar o Cloud Service Mesh gerido, a Google gere totalmente as atualizações dos seus proxies.

Com a funcionalidade do plano de dados gerido ativada, os proxies sidecar e os gateways injetados são atualizados ativamente e de forma automática em conjunto com o plano de controlo gerido reiniciando as cargas de trabalho para injetar novamente novas versões do proxy. Este processo começa após a atualização do plano de controlo e, normalmente, fica concluído no prazo de 2 semanas após o início.

Tenha em atenção que o plano de dados gerido depende do canal de lançamento do GKE. Se alterar o canal de lançamento do GKE enquanto o plano de dados gerido estiver ativado, o Cloud Service Mesh gerido atualiza os proxies de todas as cargas de trabalho existentes, como um lançamento do plano de dados gerido.

Se estiver desativada, a gestão de proxies é feita passivamente, sendo conduzida pelo ciclo de vida natural dos pods no cluster e tem de ser acionada manualmente pelo utilizador para controlar a taxa de atualização.

O plano de dados gerido atualiza os proxies ao remover pods que estão a ser executados em versões anteriores do proxy. As remoções são feitas gradualmente, respeitando o orçamento de interrupção de pods e controlando a taxa de alteração.

O plano de dados gerido não gere o seguinte:

Agrupamentos não injetados
Agrupamentos injetados manualmente
Empregos
StatefulSets
DaemonSets

Se aprovisionou o Cloud Service Mesh gerido num cluster mais antigo, pode ativar a gestão do plano de dados para todo o cluster:

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
mesh.cloud.google.com/proxy='{"managed":"true"}'

Em alternativa, pode ativar o plano de dados gerido seletivamente para uma revisão, um espaço de nomes ou um pod do plano de controlo específicos, anotando-o com a mesma anotação. Se controlar os componentes individuais de forma seletiva, a ordem de precedência é a revisão do plano de controlo, seguida do espaço de nomes e, por fim, do pod.

O serviço pode demorar até dez minutos a ficar pronto para gerir os proxies no cluster. Execute o seguinte comando para verificar o estado:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Resultado esperado

membershipStates:
  projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
    servicemesh:
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'

Se o serviço não ficar pronto no prazo de dez minutos, consulte o artigo Estado do plano de dados gerido para ver os passos seguintes.

Desative o plano de dados gerido (opcional)

Se estiver a aprovisionar o Cloud Service Mesh gerido num novo cluster, pode desativar o plano de dados gerido completamente ou para namespaces ou pods individuais. O plano de dados gerido vai continuar desativado para clusters existentes onde foi desativado por predefinição ou manualmente.

Para desativar o plano de dados gerido ao nível do cluster e reverter para a gestão dos proxies sidecar, altere a anotação:

kubectl annotate --overwrite controlplanerevision -n istio-system \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Para desativar o plano de dados gerido para um espaço de nomes:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Para desativar o plano de dados gerido para um pod:

kubectl annotate --overwrite pod POD_NAME \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Ative as janelas de manutenção para o plano de dados gerido

Se tiver um período de manutenção do GKE configurado, as atualizações ativas começam no início do próximo período de manutenção disponível e continuam sem pausas até que todos os pods geridos sejam atualizados (normalmente, 12 horas). O período de manutenção não é observado para implementações relacionadas com CVEs.

O Cloud Service Mesh usa a janela de manutenção do GKE para se alinhar com o GKE.

Ative as notificações de manutenção para o plano de dados gerido

Pode pedir para receber uma notificação sobre a manutenção do plano de dados gerido até uma semana antes da manutenção agendada. Por predefinição, as notificações de manutenção não são enviadas. Também tem de configurar um período de manutenção do GKE antes de poder receber notificações. Quando ativadas, as notificações são enviadas, pelo menos, dois dias antes da operação de atualização.

Para ativar as notificações de manutenção do plano de dados gerido:

Aceda à página Comunicação.

Aceda à página Comunicação
Na linha Atualização do Cloud Service Mesh, na coluna Email, selecione o botão de opção para ativar as notificações de manutenção .

Cada utilizador que pretenda receber notificações tem de ativar esta opção separadamente. Se quiser definir um filtro de email para estas notificações, a linha de assunto é:

Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME".

O exemplo seguinte mostra uma notificação típica de manutenção do plano de dados gerido:

Linha de assunto: Atualização pendente para o cluster "<location/cluster-name>" do Cloud Service Mesh

Olá, utilizador do Cloud Service Mesh,

Os componentes do Cloud Service Mesh no cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) vão ser atualizados a ${scheduled_date_human_readable} às ${scheduled_time_human_readable}.

Pode consultar as notas de lançamento (https://cloud.google.com/service-mesh/docs/release-notes) para saber mais sobre a nova atualização.

Se esta manutenção for cancelada, recebe outro email.

Atentamente,

A equipa do Cloud Service Mesh

(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043 Recebeu este anúncio para ficar a par de alterações importantes à Google Cloud Platform ou à sua conta. Para desativar as notificações sobre o período de manutenção, edite as suas preferências de utilizador: https://console.cloud.google.com/user-preferences/communication?project=${project_id}

Configure a descoberta de endpoints (apenas para instalações de vários clusters)

Se a sua malha tiver apenas um cluster, ignore estes passos de vários clusters e avance para Implementar aplicações ou Migrar aplicações.

Antes de continuar, certifique-se de que o Cloud Service Mesh está configurado em cada cluster.

Clusters públicos

Configure a deteção de pontos finais entre clusters públicos

Se estiver a operar em clusters públicos (clusters não privados), pode configurar a deteção de pontos finais entre clusters públicos ou, mais simplesmente, ativar a deteção de pontos finais entre clusters públicos.

Clusters privados

Configure a descoberta de pontos finais entre clusters privados

Quando usar clusters privados do GKE, tem de configurar o ponto final do plano de controlo do cluster para ser o ponto final público em vez do ponto final privado. Consulte o artigo Configure a deteção de pontos finais entre clusters privados.

Para ver um exemplo de aplicação com dois clusters, consulte o exemplo de serviço HelloWorld.

Implemente aplicações

Ative o espaço de nomes para injeção. Os passos dependem da sua implementação do plano de controlo.

Gerido (TD)

Aplique a etiqueta de injeção predefinida ao espaço de nomes:

kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

Gerido (Istiod)

Recomendação: execute o seguinte comando para aplicar a etiqueta de injeção predefinida ao espaço de nomes:

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

Se for um utilizador existente com o plano de controlo do Istiod gerido: recomendamos que use a injeção predefinida, mas a injeção baseada em revisões é suportada. Siga as instruções abaixo:

Execute o seguinte comando para localizar os canais de lançamento disponíveis:
```
kubectl -n istio-system get controlplanerevision
```
O resultado é semelhante ao seguinte:
```
NAME                AGE
asm-managed-rapid   6d7h
```
NOTA: se aparecerem duas revisões do plano de controlo na lista acima, remova uma delas. Ter vários canais do plano de controlo no cluster não é suportado.

Na saída, o valor na coluna NAME é a etiqueta de revisão que corresponde ao canal de lançamento disponível para a versão do Cloud Service Mesh.

Aplique a etiqueta de revisão ao espaço de nomes:

kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

Valide se a etiqueta do espaço de nomes está aplicada corretamente através do seguinte comando.

  kubectl get namespace -L istio-injection

Exemplo de saída:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

Neste momento, configurou com êxito a malha de serviços na nuvem gerida. Se tiver cargas de trabalho existentes em espaços de nomes etiquetados, reinicie-as para que recebam proxies injetados.

Se implementar uma aplicação numa configuração de vários clusters, replique a configuração do Kubernetes e do plano de controlo em todos os clusters, a menos que planeie limitar essa configuração específica a um subconjunto de clusters. A configuração aplicada a um cluster específico é a fonte de verdade para esse cluster.

Personalize a injeção (opcional)

Pode substituir os valores predefinidos e personalizar as definições de injeção, mas isto pode originar erros de configuração imprevistos e problemas resultantes com contentores auxiliares. Antes de personalizar a injeção, leia as informações após o exemplo para ver notas sobre definições e recomendações específicas.

A configuração por pod está disponível para substituir estas opções em pods individuais. Isto é feito adicionando um contentor istio-proxy ao seu podcast. A injeção de sidecar trata qualquer configuração definida aqui como uma substituição do modelo de injeção predefinido.

Por exemplo, a seguinte configuração personaliza várias definições, incluindo a redução dos pedidos de CPU, a adição de uma montagem de volume e a adição de um gancho preStop:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

Em geral, é possível definir qualquer campo num pod. No entanto, deve ter cuidado com determinados campos:

O Kubernetes requer que o campo image seja definido antes da execução da injeção. Embora possa definir uma imagem específica para substituir a predefinição, recomendamos que defina o valor image como auto, o que faz com que o injetor de sidecar selecione automaticamente a imagem a usar.
Alguns campos em containers dependem de definições relacionadas. Por exemplo, o valor de {0} tem de ser inferior ou igual ao limite da CPU. Se ambos os campos não estiverem configurados corretamente, o pod pode não ser iniciado.
O Kubernetes permite-lhe definir requests e limits para recursos no seu Pod spec. O GKE Autopilot só considera requests. Para mais informações, consulte o artigo Definir limites de recursos no Autopilot.

Além disso, determinados campos são configuráveis por anotações no Pod, embora seja recomendado usar a abordagem acima para personalizar as definições. Tome especial atenção às seguintes anotações:

Para o GKE Standard, se sidecar.istio.io/proxyCPU estiver definido, certifique-se de que define explicitamente sidecar.istio.io/proxyCPULimit. Caso contrário, o limite de CPU do sidecar é definido como ilimitado.
Para o GKE Standard, se sidecar.istio.io/proxyMemory estiver definido, certifique-se de que define explicitamente sidecar.istio.io/proxyMemoryLimit. Caso contrário, o limite de memória do sidecar é definido como ilimitado.
Para o GKE Autopilot, a configuração de recursos requests e limits através de anotações pode aprovisionar recursos em excesso. Use a abordagem de modelo de imagem para evitar. Veja exemplos de modificação de recursos no piloto automático.

Por exemplo, veja a anotação de recursos abaixo:

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

Valide as métricas do plano de controlo

Pode ver a versão do plano de controlo e do plano de dados no Explorador de métricas.

Para verificar se a configuração funciona como esperado:

Na Google Cloud consola, veja as métricas do plano de controlo:

Aceda ao Metrics Explorer
Escolha o seu espaço de trabalho e adicione uma consulta personalizada com os seguintes parâmetros:
- Tipo de recurso: contentor do Kubernetes
- Métrica: clientes proxy
- Filtro: container_name="cr-REVISION_LABEL"
- Agrupar por: etiqueta revision e etiqueta proxy_version
- Agregador: soma
- Período: 1 minuto
Quando executa o Cloud Service Mesh com um plano de controlo gerido pela Google e um plano de controlo no cluster, pode distinguir as métricas pelo nome do respetivo contentor. Por exemplo, as métricas geridas têm container_name="cr-asm-managed", enquanto as métricas não geridas têm container_name="discovery". Para apresentar métricas de ambos, remova o filtro em container_name="cr-asm-managed".
Valide a versão do plano de controlo e a versão do proxy inspecionando os seguintes campos no Explorador de métricas:
- O campo revision indica a versão do plano de controlo.
- O campo proxy_version indica a proxy_version.
- O campo valor indica o número de proxies ligados.
Para ver o mapeamento da versão do canal atual para a versão do Cloud Service Mesh, consulte o artigo Versões do Cloud Service Mesh por canal.

Migre aplicações para o Cloud Service Mesh gerido

Prepare-se para a migração

Para se preparar para migrar aplicações do Cloud Service Mesh no cluster para o Cloud Service Mesh gerido, siga estes passos:

Execute a ferramenta conforme indicado na secção Aplique o plano de controlo gerido pela Google.

(Opcional) Se quiser usar o plano de dados gerido pela Google, ative a gestão do plano de dados:

  kubectl annotate --overwrite controlplanerevision REVISION_TAG \
  mesh.cloud.google.com/proxy='{"managed":"true"}'

Migre aplicações

Para migrar aplicações do Cloud Service Mesh no cluster para o Cloud Service Mesh gerido, siga estes passos:

Substituir a etiqueta do espaço de nomes atual. Os passos dependem da sua implementação do plano de controlo.

Gerido (TD)

Aplique a etiqueta de injeção predefinida ao espaço de nomes:

kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

Gerido (Istiod)

Recomendação: execute o seguinte comando para aplicar a etiqueta de injeção predefinida ao espaço de nomes:

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

Execute o seguinte comando para localizar os canais de lançamento disponíveis:
```
kubectl -n istio-system get controlplanerevision
```
O resultado é semelhante ao seguinte:
```
NAME                AGE
asm-managed-rapid   6d7h
```
NOTA: se aparecerem duas revisões do plano de controlo na lista acima, remova uma delas. Ter vários canais do plano de controlo no cluster não é suportado.

Na saída, o valor na coluna NAME é a etiqueta de revisão que corresponde ao canal de lançamento disponível para a versão do Cloud Service Mesh.

Aplique a etiqueta de revisão ao espaço de nomes:

kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

Faça uma atualização contínua das implementações no espaço de nomes:
```
kubectl rollout restart deployment -n NAMESPACE
```
Teste a sua aplicação para verificar se as cargas de trabalho funcionam corretamente.
Se tiver cargas de trabalho noutros espaços de nomes, repita os passos anteriores para cada espaço de nomes.
Se implementou a aplicação numa configuração de vários clusters, replique a configuração do Kubernetes e do Istio em todos os clusters, a menos que queira limitar essa configuração apenas a um subconjunto de clusters. A configuração aplicada a um cluster específico é a fonte de verdade para esse cluster.

Se tiver a certeza de que a sua aplicação funciona como esperado, pode remover o istiod no cluster depois de mudar todos os espaços de nomes para o plano de controlo gerido ou mantê-los como uma cópia de segurança. O istiod é reduzido automaticamente para usar menos recursos. Para remover, avance para a secção Eliminar plano de controlo antigo.

Se encontrar problemas, pode identificá-los e resolvê-los através das informações em Resolver problemas do plano de controlo gerido e, se necessário, reverter para a versão anterior.

Elimine o plano de controlo antigo

Depois de instalar e confirmar que todos os espaços de nomes usam o plano de controlo gerido pela Google, pode eliminar o plano de controlo antigo.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

Se usou istioctl kube-inject em vez da injeção automática ou se instalou gateways adicionais, verifique as métricas do plano de controlo e confirme que o número de pontos finais ligados é zero.

Reverter

Execute os passos seguintes se precisar de reverter para a versão anterior do plano de controlo:

Atualize as cargas de trabalho para serem injetadas com a versão anterior do plano de controlo. No comando seguinte, o valor de revisão asm-191-1 é usado apenas como exemplo. Substitua o valor de exemplo pela etiqueta de revisão do seu plano de controlo anterior.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
Reinicie os agrupamentos para acionar a reinjeção, para que os proxies tenham a versão anterior:
```
kubectl rollout restart deployment -n NAMESPACE
```

O plano de controlo gerido é automaticamente dimensionado para zero e não usa recursos quando não está em uso. Os webhooks de mutação e o aprovisionamento permanecem e não afetam o comportamento do cluster.

O gateway está agora definido para a revisão asm-managed. Para reverter, volte a executar o comando de instalação do Cloud Service Mesh, que volta a implementar o gateway apontando para o plano de controlo no cluster:

kubectl -n istio-system rollout undo deploy istio-ingressgateway

Espere este resultado em caso de êxito:

deployment.apps/istio-ingressgateway rolled back

Desinstalar

O plano de controlo gerido é dimensionado automaticamente para zero quando nenhum espaço de nomes o está a usar. Para ver os passos detalhados, consulte o artigo Desinstale o Cloud Service Mesh.

Resolução de problemas

Para identificar e resolver problemas quando usar o plano de controlo gerido, consulte o artigo Resolução de problemas do plano de controlo gerido.

O que se segue?

Saiba mais sobre os canais de lançamento.
Migre do IstioOperator.
Migre um gateway para o plano de controlo gerido.
Saiba como ativar funcionalidades opcionais geridas do Cloud Service Mesh, como: