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

Esta página foi traduzida pela API Cloud Translation.

Pré-requisitos do Cloud Service Mesh no cluster

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

do Google Cloud

Antes de começar:

Selecione ou crie um Google Cloud projeto.
Verifique se o faturamento foi ativado para o projeto.

Requisitos gerais

Para serem incluídos na malha de serviço, as portas precisam ser nomeadas, e o nome precisa incluir o protocolo da porta na seguinte sintaxe: name: protocol[-suffix], em que os colchetes indicam um sufixo opcional que precisa começar com um traço. Saiba mais em Como nomear portas de serviço.
Se você tiver criado um perímetro de serviço na sua organização, talvez seja necessário adicionar o serviço de autoridade de certificação do Cloud Service Mesh ao perímetro. Saiba mais em Como adicionar uma autoridade certificadora do Cloud Service Mesh a um perímetro de serviço.
Se você quiser alterar os limites de recursos padrão do contêiner secundário istio-proxy, os novos valores precisarão ser maiores que os padrão para evitar eventos de memória (OOM).
Um projeto do Google Cloud só pode ter uma malha associada a ele.

Requisitos de cluster

Verifique se o cluster de usuário em que você instala o Cloud Service Mesh tem pelo menos quatro vCPUs, 15 GB de memória e quatro nós.
Verifique se a versão do cluster está listada em Plataformas compatíveis.
Verifique se a máquina cliente da qual você instala o Cloud Service Mesh tem conexão de rede com o servidor de API.
Para implantar sidecars em pods de aplicativos em que a conectividade direta com os serviços de CA (como meshca.googleapis.com e privateca.googleapis.com) não está disponível, configure um proxy HTTPS explícito baseado em CONNECT.
Para clusters públicos com regras de firewall de saída definidas que bloqueiam regras implícitas, verifique se você configurou regras HTTP/HTTPS e DNS para acessar as APIs públicas do Google.

Requisitos de frota

Todos os clusters precisam ser registrados em uma frota, e a identidade da carga de trabalho da frota precisa estar ativada. É possível configurar os clusters por conta própria ou permitir que asmcli registre os clusters, desde que eles atendam aos seguintes requisitos:

Clusters do GKE fora do Google Cloud: (aplicável ao Cloud Service Mesh no cluster) O Google Distributed Cloud (somente software) para VMware, o Google Distributed Cloud (somente software) para bare metal, o GKE na AWS (descontinuado) e o GKE no Azure (descontinuado) são registrados automaticamente na frota do projeto no momento da criação do cluster. A partir do GKE Enterprise 1.8, todos esses tipos de cluster ativam automaticamente a Identidade da carga de trabalho da frota quando registrados. Os clusters registrados que já existem são atualizados para usar a Identidade da carga de trabalho da frota quando fazem upgrade para o GKE Enterprise 1.8.
Clusters do Amazon EKS (descontinuado): (aplica-se ao Cloud Service Mesh no cluster) o cluster precisa ter um provedor de identidade OIDC de IAM público. Siga as instruções em Criar um provedor OIDC do IAM para o cluster para verificar se um provedor existe. Se não existir, crie um.

Ao executar asmcli install, você especifica o ID do projeto host da frota. asmcli registra o cluster se ainda não estiver registrado.