Pré-requisitos do Cloud Service Mesh no cluster
Nesta página, descrevemos os pré-requisitos e os requisitos de instalação do Cloud Service Mesh no cluster para cargas de trabalho do Kubernetes fora do Google Cloud, como licenciamento do GKE Enterprise, requisitos de cluster, de frota e gerais.
do Google Cloud
Antes de começar:
Verifique se o faturamento foi ativado para o projeto.
Licenciamento do GKE Enterprise
Para instalar o Cloud Service Mesh no local, no GKE na AWS, no Amazon EKS, no GKE no Azure ou no Microsoft AKS, você precisa ser um cliente do GKE Enterprise. Os clientes do GKE Enterprise não são cobrados separadamente para o Cloud Service Mesh porque ele já está incluído no GKE Enterprise preços. Para mais informações, consulte o Guia de preços do GKE Enterprise.
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. Consulte Como adicionar a autoridade certificadora do Cloud Service Mesh a um perímetro de serviço para mais informações.
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 pelo menos 4 vCPUs, 15 GB de memória e 4 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.comeprivateca.googleapis.com) não está disponível, configure um proxy HTTPS explícito baseado emCONNECT.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
fleet e
identidade da carga de trabalho da frota
precisa ser 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: (se aplica ao Cloud Service Mesh no cluster) O Google Distributed Cloud, Google Distributed Cloud, GKE na AWS O GKE no Azure registradas 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: (aplica-se ao Cloud Service Mesh no cluster) o cluster precisa ter um provedor de identidade OIDC do 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.