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

Pré-requisitos do Cloud Service Mesh no cluster

Esta página descreve os pré-requisitos e os requisitos para instalar o Cloud Service Mesh no cluster para cargas de trabalho do Kubernetes fora do cluster Google Cloud, como requisitos de cluster, requisitos de frota e requisitos gerais.

Projeto na nuvem

Antes de começar:

Selecione ou crie um Google Cloud projeto.
Confirme se a faturação está ativada para o seu projeto.

Requisitos gerais

Para serem incluídas na malha de serviços, as portas de serviço têm de ter um nome e o nome tem de incluir o protocolo da porta na seguinte sintaxe: name: protocol[-suffix] onde os parênteses retos indicam um sufixo opcional que tem de começar com um traço. Para mais informações, consulte o artigo Atribuir nomes a portas de serviço.
Se tiver criado um perímetro de serviço na sua organização, pode ter de adicionar o serviço de autoridade de certificação do Cloud Service Mesh ao perímetro. Consulte o artigo Adicionar uma autoridade de certificação do Cloud Service Mesh a um perímetro de serviço para mais informações.
Se quiser alterar os limites de recursos predefinidos para o contentor sidecar, os novos valores têm de ser superiores aos valores predefinidos para evitar eventos de falta de memória (OOM).istio-proxy
Um Google Cloud projeto só pode ter uma malha associada.

Requisitos de clusters

Certifique-se de que o cluster de utilizadores no qual instala o Cloud Service Mesh tem, pelo menos, 4 vCPUs, 15 GB de memória e 4 nós.
Confirme se a versão do cluster está listada em Plataformas suportadas.
Certifique-se de que a máquina cliente a partir da qual instala o Cloud Service Mesh tem conectividade de rede com o servidor da API.
Se estiver a implementar sidecars em pods de aplicações onde a conetividade direta aos serviços de AC (como meshca.googleapis.com e privateca.googleapis.com) não está disponível, tem de configurar um proxy HTTPS explícito baseado em CONNECT.
Para clusters públicos com regras de firewall de saída definidas que estão a bloquear regras implícitas, certifique-se de que configurou regras HTTP/HTTPS e DNS para alcançar as APIs Google públicas.

Requisitos da frota

Todos os clusters têm de estar registados numa frota e a identidade da carga de trabalho da frota tem de estar ativada. Pode configurar os clusters ou permitir que o asmcli registe os clusters, desde que estes cumpram os seguintes requisitos:

Os clusters do GKE fora Google Cloud: (aplica-se ao Cloud Service Mesh no cluster) Google Distributed Cloud (apenas software) para VMware, Google Distributed Cloud (apenas software) para bare metal, GKE no AWS (descontinuado) e GKE no Azure (descontinuado) são registados automaticamente na sua frota de projetos no momento da criação do cluster. A partir do GKE Enterprise 1.8, todos estes tipos de clusters ativam automaticamente a identidade de carga de trabalho da frota quando registados. Os clusters registados existentes são atualizados para usar o Workload Identity da frota quando são atualizados para o GKE Enterprise 1.8.
Clusters do Amazon EKS (descontinuado): (aplica-se à malha de serviços na nuvem no cluster) O cluster tem de ter um fornecedor de identidade OIDC do IAM público. Siga as instruções em Crie um fornecedor OIDC do IAM para o seu cluster para verificar se existe um fornecedor e crie um, se necessário.

Quando executa asmcli install, especifica o ID do projeto do projeto anfitrião da frota. asmcli regista o cluster se ainda não estiver registado.