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, como o licenciamento do GKE Enterprise, os requisitos do cluster, os requisitos da frota e os requisitos gerais. Google Cloud
Projeto na nuvem
Antes de começar:
Confirme se a faturação está ativada para o seu projeto.
Licenciamento do GKE Enterprise
Para instalar o Cloud Service Mesh no local, no GKE no AWS, no Amazon EKS, no GKE no Azure ou no Microsoft AKS, tem de ser cliente do GKE Enterprise. Os clientes do GKE Enterprise não são faturados separadamente pelo Cloud Service Mesh porque já está incluído nos preços do GKE Enterprise. Para mais informações, consulte o guia de preços do GKE Enterprise.
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
eprivateca.googleapis.com
) não está disponível, tem de configurar um proxy HTTPS explícito baseado emCONNECT
.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 à malha de serviços na cluster) Google Distributed Cloud (apenas software) para VMware, Google Distributed Cloud (apenas software) para bare metal, GKE no AWS e GKE no Azure 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: (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.