Está a ver a documentação da malha de serviço v1.23.

Versões disponíveis

Cloud Service Mesh
Arquivo 1.24
Arquivo 1.23
Arquivo 1.22
Arquivo 1.21
Arquivo 1.20
Arquivo 1.19
Arquivo 1.18

Esta página foi traduzida pela API Cloud Translation.

Aprovisione um plano de controlo do Cloud Service Mesh gerido no GKE

A malha de serviço do Google Cloud é uma malha de serviço gerida pela Google que basta ativar. A Google trata da fiabilidade, das atualizações, do dimensionamento e da segurança por si.

Esta página mostra como usar a API fleet para configurar a malha de serviços na nuvem gerida através das APIs Istio.

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
Ativado Workload Identity nos seus clusters e node pools.

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.
- O Managed Cloud Service Mesh não suporta a alteração segura dos canais de lançamento do GKE.
- Se alterar o canal de lançamento do GKE, o Cloud Service Mesh atualiza/reverte automaticamente os componentes no cluster (CNI, MDPC, versão do proxy injetado predefinida e CRDs do Istio) para se alinhar 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. Isto está incluído nas instruções ou pode ser feito separadamente antes do aprovisionamento.
O seu projeto tem de ter a funcionalidade de frota do Service Mesh ativada. Isto está incluído nas instruções ou pode ser feito separadamente.
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.

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)}

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.
A utilização do Certificate Authority Service (CA Service) requer a configuração da Cloud Service Mesh por cluster e não é suportada quando se usa a configuração fleet-default no GKE Enterprise.
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.
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.

Antes de começar

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Configure o gcloud (mesmo que esteja a usar o Cloud Shell).

Autentique-se com a CLI Google Cloud, onde FLEET_PROJECT_ID é o ID do seu projeto de anfitrião da frota. Geralmente, o FLEET_PROJECT_ID é criado por predefinição e tem o mesmo nome que o projeto.
```
       gcloud auth login --project FLEET_PROJECT_ID
```
Atualize os componentes:
```
       gcloud components update
```

Ative as APIs necessárias no projeto de anfitrião da frota.

  gcloud services enable mesh.googleapis.com \
      --project=FLEET_PROJECT_ID

A ativação de mesh.googleapis.com ativa as seguintes APIs:

API	Finalidade	Pode ser desativado
`meshconfig.googleapis.com`	O Cloud Service Mesh usa a API Mesh Configuration para retransmitir dados de configuração da sua malha para Google Cloud. Além disso, a ativação da API Mesh Configuration permite-lhe aceder às páginas do Cloud Service Mesh na Google Cloud consola e usar a autoridade de certificação do Cloud Service Mesh.	Não
`meshca.googleapis.com`	Relacionado com a autoridade de certificação do Cloud Service Mesh usada pelo Cloud Service Mesh gerido.	Não
`container.googleapis.com`	Necessário para criar clusters do Google Kubernetes Engine (GKE).	Não
`gkehub.googleapis.com`	Necessário para gerir a malha como uma frota.	Não
`monitoring.googleapis.com`	Necessário para capturar telemetria para cargas de trabalho de malha.	Não
`stackdriver.googleapis.com`	Necessário para usar a IU dos Serviços.	Não
`opsconfigmonitoring.googleapis.com`	Necessário para usar a IU dos serviços para clusters fora doGoogle Cloud Google Cloud.	Não
`connectgateway.googleapis.com`	Necessário para que o plano de controlo do Cloud Service Mesh gerido possa aceder às cargas de trabalho da malha.	Sim*
`trafficdirector.googleapis.com`	Ativa um plano de controlo gerido altamente disponível e escalável.	Sim*
`networkservices.googleapis.com`	Ativa um plano de controlo gerido altamente disponível e escalável.	Sim*
`networksecurity.googleapis.com`	Ativa um plano de controlo gerido altamente disponível e escalável.	Sim*

Aviso: desativar connectgateway.googleapis.com, trafficdirector.googleapis.com, networkservices.googleapis.com e/ou networksecurity.googleapis.com faz com que o plano de controlo do Cloud Service Mesh gerido deixe de funcionar. Se a frota não usar o Cloud Service Mesh gerido em nenhum cluster, estas APIs podem ser desativadas.

Configure o Cloud Service Mesh gerido

Os passos necessários para aprovisionar o Cloud Service Mesh gerido através da API Fleet dependem de preferir ativá-lo por predefinição para novos clusters da frota ou ativá-lo por cluster.

Configure para a sua frota

Se tiver ativado o Google Kubernetes Engine (GKE) Enterprise edition, pode ativar o Cloud Service Mesh gerido como uma configuração predefinida para a sua frota. Isto significa que todos os novos clusters do GKE no Google Cloud registados durante a criação do cluster vão ter o Cloud Service Mesh gerido ativado no cluster. Pode saber mais acerca da configuração predefinida da frota em Gerir funcionalidades ao nível da frota.

A ativação da malha de serviços na nuvem gerida como uma configuração predefinida para a sua frota e o registo de clusters na frota durante a criação de clusters só suportam a AC de malha. Se quiser usar o serviço de autoridade de certificação, recomendamos que o ative por cluster.

Para ativar as predefinições ao nível da frota para a malha de serviços na nuvem gerida, conclua os seguintes passos:

Consola

Na Google Cloud consola, aceda à página Gestor de funcionalidades.

Aceda ao Gestor de funcionalidades
No painel Service Mesh, clique em Configurar.
Reveja as definições herdadas por todos os novos clusters que criar na consola e registar na frota. Google Cloud

Nota: estas definições são definições do GKE que são pré-requisitos para usar a Cloud Service Mesh.
Para aplicar estas definições, clique em Configurar.
Na caixa de diálogo de confirmação, clique em Confirmar.
Opcional: sincronize os clusters existentes com as predefinições:
1. Na lista Clusters na frota, selecione os clusters que quer sincronizar. Só pode selecionar clusters com o Cloud Service Mesh instalado.
2. Clique em Sincronizar com as definições da frota e clique em Confirmar na caixa de diálogo de confirmação apresentada. Esta operação pode demorar alguns minutos a ser concluída.

gcloud

Para configurar as predefinições ao nível da frota através da Google Cloud CLI, tem de estabelecer as seguintes definições:

Definições ao nível da frota

Crie um ficheiro mesh.yaml que contenha apenas a linha única management: automatic:
```
echo "management: automatic" > mesh.yaml
```

Ative o Cloud Service Mesh para a sua frota:

gcloud container fleet mesh enable --project FLEET_PROJECT_ID \
    --fleet-default-member-config mesh.yaml

Se vir o seguinte erro, tem de ativar o GKE Enterprise.

ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The
[anthos.googleapis.com] service is required for this operation and is not
enabled for the project [PROJECT_NUMBER]. Please use the Google Developers
Console to enable it.: failed precondition

Definições ao nível da rede
- Se o projeto da sua rede for diferente do projeto anfitrião da frota (por exemplo, se estiver a usar uma VPC partilhada), tem de permitir que as contas de serviço da Cloud Service Mesh no projeto da frota acedam ao projeto de rede. Só tem de o fazer uma vez para o projeto de rede.
  
  Conceda autorização às contas de serviço no projeto da frota para aceder ao projeto de rede:
```
gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent
```
Definições ao nível do cluster
- Quando estiver pronto para criar clusters para usar com o Cloud Service Mesh, crie-os e registe-os num único passo com a Google Cloud CLI para usar a configuração predefinida. Por exemplo:
```
gcloud container clusters create-auto CLUSTER_NAME \
    --fleet-project FLEET_PROJECT_ID \
    --location=LOCATION
```
  Pode obter o número do projeto do seu projeto de frota executando o seguinte comando:
```
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
```
  A flag --location é a zona ou a região de computação (como us-central1-a ou us-central1) para o cluster.
- Se o projeto do cluster for diferente do projeto anfitrião da frota, tem de permitir que as contas de serviço da Cloud Service Mesh no projeto da frota acedam ao projeto do cluster e ativar as APIs necessárias no projeto do cluster. Só tem de o fazer uma vez para cada projeto de cluster.
  
  Conceda autorização às contas de serviço no projeto da frota para acederem ao projeto do cluster:
```
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent
```
  Ative a API Mesh no projeto do cluster:
```
gcloud services enable mesh.googleapis.com \
  --project=CLUSTER_PROJECT_ID
```
  Substitua CLUSTER_PROJECT_ID pelo identificador exclusivo do projeto do cluster. Se criou o cluster no mesmo projeto que a sua frota, o CLUSTER_PROJECT_ID é igual ao FLEET_PROJECT_ID.

Continue para Verificar se o plano de controlo foi aprovisionado.

Configure por cluster

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

Ative a funcionalidade de frota do Cloud Service Mesh

Ative o Cloud Service Mesh no projeto da frota. Tenha em atenção que, se planear registar vários clusters, a ativação da Cloud Service Mesh ocorre ao nível da frota, pelo que só tem de executar este comando uma vez.

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Registe clusters numa frota

Registe um cluster do GKE com a identidade de carga de trabalho da frota. A flag --location é a zona de computação ou a região (como us-central1-a ou us-central1) do cluster.
```
gcloud container clusters update CLUSTER_NAME \
  --location CLUSTER_LOCATION \
  --fleet-project FLEET_PROJECT_ID
```

Verifique se o cluster está registado:

gcloud container fleet memberships list --project FLEET_PROJECT_ID

Exemplo de saída:

NAME                 EXTERNAL_ID                           LOCATION
cluster-1            1d8e255d-2b55-4df9-8793-0435461a2cbc  us-central1

Tome nota do MEMBERSHIP_NAME, uma vez que vai precisar dele quando ativar a gestão automática.

Se o projeto da rede do cluster for diferente do projeto anfitrião da frota (por exemplo, se estiver a usar uma VPC partilhada), tem de permitir que as contas de serviço do Cloud Service Mesh no projeto da frota acedam ao projeto da rede. Só tem de o fazer uma vez para o projeto de rede.

Conceda autorização às contas de serviço no projeto da frota para aceder ao projeto de rede:
```
 gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
      --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
      --role roles/anthosservicemesh.serviceAgent
```
Se o projeto do cluster for diferente do projeto anfitrião da frota, tem de permitir que as contas de serviço do Cloud Service Mesh no projeto da frota acedam ao projeto do cluster e ativar as APIs necessárias no projeto do cluster.

Só tem de fazer isto uma vez para cada projeto de cluster. Se configurou anteriormente o Cloud Service Mesh gerido para esta combinação de projetos de cluster e de frota, estas alterações já foram aplicadas e não tem de executar os seguintes comandos.

Conceda autorização às contas de serviço no projeto da frota para aceder ao projeto do cluster:
```
 gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
     --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
     --role roles/anthosservicemesh.serviceAgent
```
Ative a API Mesh no projeto do cluster:
```
 gcloud services enable mesh.googleapis.com \
     --project=CLUSTER_PROJECT_ID
```

Configure o Certificate Authority Service (opcional)

Se a implementação da malha de serviços exigir o serviço de autoridade de certificação (serviço de CA), siga o artigo Configure o serviço de autoridade de certificação para a malha de serviços na nuvem gerida para o ativar para a sua frota. Certifique-se de que conclui todos os passos antes de avançar para a secção seguinte.

Ative a gestão automática

Execute o seguinte comando para ativar a gestão automática:

  gcloud container fleet mesh update \
     --management automatic \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID \
     --location MEMBERSHIP_LOCATION

where:

MEMBERSHIP_NAME é o nome da associação apresentado quando validou que o seu cluster estava registado na frota.
MEMBERSHIP_LOCATION é a localização da sua subscrição (uma região ou global).

Se criou recentemente a associação através do comando neste guia, esta deve ser a região do seu cluster. Se tiver um cluster zonal, use a região correspondente à zona do cluster. Por exemplo, se tiver um cluster zonal em us-central1-c, use o valor us-central1.

Este valor pode ser global se se tiver registado antes de maio de 2023 ou se tiver especificado a localização global quando registou a subscrição. Pode consultar a localização da sua subscrição com gcloud container fleet memberships list --project FLEET_PROJECT_ID.

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:

...
membershipSpecs:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
        implementation: ISTIOD | TRAFFIC_DIRECTOR
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

Tome nota do plano de controlo apresentado no campo implementation, ISTIOD ou TRAFFIC_DIRECTOR. Consulte as funcionalidades suportadas do Cloud Service Mesh para ver as diferenças do painel de controlo e as configurações suportadas, bem como a forma como a implementação do painel de controlo é selecionada.

Configure o `kubectl` para apontar para o cluster

As secções seguintes envolvem a execução de comandos kubectl em cada um dos seus clusters. Antes de avançar para as secções seguintes, execute o comando seguinte para cada um dos seus clusters para configurar kubectl de modo a apontar para o cluster.

gcloud container clusters get-credentials CLUSTER_NAME \
      --location CLUSTER_LOCATION \
      --project CLUSTER_PROJECT_ID

Tenha em atenção que um gateway de entrada não é implementado automaticamente com o plano de controlo. A desassociação da implementação do gateway de entrada e do plano de controlo permite-lhe gerir os gateways num ambiente de produção. Se quiser usar um gateway de entrada do Istio ou um gateway de saída, consulte o artigo Implementar gateways. Se quiser usar a API Kubernetes Gateway, consulte o artigo Prepare o Gateway para a malha. Para ativar outras funcionalidades opcionais, consulte o artigo Ativar funcionalidades opcionais na Cloud Service Mesh.

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

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

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

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 seu 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/v1.23/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 do 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.

A ativação da malha de serviços na nuvem com a API Fleet permite a deteção de pontos finais para este cluster. No entanto, tem de abrir portas da firewall. Para desativar a deteção de pontos finais para um ou mais clusters, consulte as instruções para a desativar em Deteção de pontos finais entre clusters com a API declarativa.

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"

Migre aplicações para o Cloud Service Mesh gerido

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

Desinstale o Cloud Service Mesh

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.

Aprovisione um plano de controlo do Cloud Service Mesh gerido no GKE

Pré-requisitos

Requisitos

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

Limitações

Antes de começar

A ativação de mesh.googleapis.com ativa as seguintes APIs:

Configure o Cloud Service Mesh gerido

Configure para a sua frota

Consola

gcloud

Configure por cluster

Ative a funcionalidade de frota do Cloud Service Mesh

Registe clusters numa frota

Configure o Certificate Authority Service (opcional)

Ative a gestão automática

Verifique se o plano de controlo foi aprovisionado

Configure o kubectl para apontar para o cluster

Plano de dados gerido

Desative o plano de dados gerido (opcional)

Ative as janelas de manutenção

Ative as notificações de manutenção

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

Implemente aplicações

Gerido (TD)

Gerido (Istiod)

Personalize a injeção (opcional)

Migre aplicações para o Cloud Service Mesh gerido

Gerido (TD)

Gerido (Istiod)

Elimine o plano de controlo antigo

Reverter

Desinstale o Cloud Service Mesh

Configure o `kubectl` para apontar para o cluster