Pré-requisitos do Cloud Service Mesh
Esta página descreve os pré-requisitos e os requisitos para instalar o Cloud Service Mesh, como o licenciamento do GKE Enterprise, os requisitos do cluster, os requisitos da frota e os requisitos gerais.
Projeto na nuvem
Antes de começar:
Confirme se a faturação está ativada para o seu projeto.
Licenciamento do GKE Enterprise
GKE
O Cloud Service Mesh está disponível com o GKE Enterprise ou como um serviço autónomo.
As APIs Google são usadas para determinar a sua forma de faturação. Para usar o Cloud Service Mesh como um serviço autónomo, não ative a API GKE Enterprise no seu projeto.
O asmcli
ativa todas as outras APIs Google necessárias. Para ver informações sobre os preços do Cloud Service Mesh, consulte a página Preços.
- Os subscritores do GKE Enterprise devem certificar-se de que ativam a API GKE Enterprise.
Se não for subscritor do GKE Enterprise, pode continuar a instalar o Cloud Service Mesh, mas determinados elementos da IU e funcionalidades na Google Cloud consola só estão disponíveis para subscritores do GKE Enterprise. Para ver informações sobre o que está disponível para subscritores e não subscritores, consulte o artigo Diferenças entre a IU do GKE Enterprise e do Cloud Service Mesh.
Se ativou a API GKE Enterprise, mas quer usar o Cloud Service Mesh como um serviço autónomo, desative a API GKE Enterprise.
Fora do Google Cloud
Para instalar o Cloud Service Mesh nas instalações, no GKE no AWS, no Amazon EKS 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 no preço 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
GKE
Confirme se a versão do cluster está listada em Plataformas suportadas.
O seu cluster do GKE tem de cumprir os seguintes requisitos:
O cluster do GKE tem de ser padrão. Os clusters do Autopilot só são suportados com a malha de serviços na nuvem gerida.
Um tipo de máquina com, pelo menos, 4 vCPUs, como
e2-standard-4
. Se o tipo de máquina do seu cluster não tiver, pelo menos, 4 vCPUs, altere o tipo de máquina conforme descrito no artigo Migrar cargas de trabalho para diferentes tipos de máquinas.O número mínimo de nós depende do tipo de máquina. O Cloud Service Mesh requer, pelo menos, 8 vCPUs. Se o tipo de máquina tiver 4 vCPUs, o cluster tem de ter, pelo menos, 2 nós. Se o tipo de máquina tiver 8 vCPUs, o cluster só precisa de 1 nó. Se precisar de adicionar nós, consulte o artigo Redimensionar um cluster.
É necessária a identidade de carga de trabalho do GKE. Recomendamos que ative a identidade da carga de trabalho antes de instalar o Cloud Service Mesh. A ativação do Workload Identity altera a forma como as chamadas das suas cargas de trabalho para as APIs Google são protegidas, conforme descrito nas limitações do Workload Identity. Tenha em atenção que não precisa de ativar o servidor de metadados do GKE em pools de nós existentes.
Opcional, mas recomendado: inscreva o cluster num canal de lançamento. Recomendamos que se inscreva no canal de lançamento Regular, uma vez que outros canais podem basear-se numa versão do GKE não suportada pelo Cloud Service Mesh 1.26.4. Para mais informações, consulte o artigo Plataformas suportadas. Siga as instruções em Inscrever um cluster existente num canal de lançamento se tiver uma versão estática do GKE.
Se estiver a instalar o Cloud Service Mesh num cluster privado, tem de abrir a porta 15017 na firewall para que os webhooks usados para a injeção automática de sidecars e a validação da configuração funcionem. Para mais informações, consulte o artigo Abrir uma porta num cluster privado.
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.
Para cargas de trabalho do Windows Server, o Cloud Service Mesh não é suportado. Se o seu cluster tiver pools de nós do Linux e do Windows Server, ainda pode instalar o Cloud Service Mesh e usá-lo nas suas cargas de trabalho do Linux.
- Após o aprovisionamento da Cloud Service Mesh, tem de contactar o apoio técnico antes de iniciar a rotação de IPs ou a rotação de credenciais de certificados.
Fora de Google Cloud
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
Com o Cloud Service Mesh 1.11 e posterior, 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:
GKE: (aplica-se ao Cloud Service Mesh gerido e no cluster) Ative o Workload Identity do GKE no seu cluster do Google Kubernetes Engine, se ainda não estiver ativado. Além disso, tem de registar o cluster através do Workload Identity da frota.
Os clusters do GKE fora Google Cloud: (aplica-se ao Cloud Service Mesh no cluster) Google Distributed Cloud, Google Distributed Cloud, 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.