Anthos Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Prerequisiti di Cloud Service Mesh in-cluster

Questa pagina descrive i prerequisiti e i requisiti per l'installazione di Cloud Service Mesh in-cluster per i workload Kubernetes esterni a Google Cloud, ad esempio requisiti del cluster, del parco risorse e generali.

Progetto cloud

Prima di iniziare:

Seleziona o crea un Google Cloud progetto.
Verifica che la fatturazione sia attivata per il tuo progetto.

Requisiti generali

Per essere incluse nel mesh di servizi, le porte di servizio devono essere denominate e il nome deve includere il protocollo della porta con la seguente sintassi: name: protocol[-suffix] dove le parentesi quadre indicano un suffisso facoltativo che deve iniziare con un trattino. Per saperne di più, consulta Denominazione delle porte di servizio.
Se vuoi modificare i limiti delle risorse predefiniti per il container sidecar istio-proxy, i nuovi valori devono essere superiori a quelli predefiniti per evitare eventi di esaurimento della memoria (OOM).
Un progetto Google Cloud può avere una sola mesh associata.

Requisiti per i cluster

Assicurati che il cluster utente su cui installi Cloud Service Mesh abbia almeno 4 vCPU, 15 GB di memoria e 4 nodi.
Verifica che la versione del cluster sia elencata in Piattaforme supportate.
Assicurati che la macchina client da cui installi Cloud Service Mesh abbia la connettività di rete al server API.
Se esegui il deployment di sidecar nei pod delle applicazioni in cui la connettività diretta ai servizi CA (come meshca.googleapis.com e privateca.googleapis.com) non è disponibile, devi configurare un proxy HTTPS esplicito basato su CONNECT.
Per i cluster pubblici con regole firewall in uscita impostate che bloccano le regole implicite, assicurati di aver configurato le regole HTTP/HTTPS e DNS per raggiungere le API di Google pubbliche.

Requisiti del parco risorse

Tutti i cluster devono essere registrati in un parco risorse e deve essere abilitata l'identità del workload del parco risorse. Puoi configurare i cluster autonomamente oppure puoi consentire a asmcli di registrarli, a condizione che soddisfino i seguenti requisiti:

Cluster GKE esterni a Google Cloud: (si applica a Cloud Service Mesh nel cluster) Google Distributed Cloud (solo software) per VMware, Google Distributed Cloud (solo software) per bare metal, GKE su AWS (ritirato) e GKE su Azure (ritirato) vengono registrati automaticamente nel parco risorse del progetto al momento della creazione del cluster. A partire da GKE Enterprise 1.8, tutti questi tipi di cluster abilitano automaticamente Workload Identity del parco risorse al momento della registrazione. I cluster registrati esistenti vengono aggiornati per utilizzare Workload Identity del parco risorse quando vengono eseguiti l'upgrade a GKE Enterprise 1.8.
Cluster Amazon EKS (ritirati): (si applica a Cloud Service Mesh nel cluster) Il cluster deve avere un provider di identità OIDC IAM pubblico. Segui le istruzioni riportate in Crea un provider OIDC IAM per il tuo cluster per verificare se esiste un provider e crearne uno, se necessario.

Quando esegui asmcli install, specifichi l'ID progetto del progetto host del parco risorse. asmcli registra il cluster se non è già registrato.

A partire dalla versione 1.25 di asmcli, tutti gli upgrade e le installazioni in-cluster di Cloud Service Mesh eseguono il provisioning del controller dei servizi canonici gestito. Per questa operazione è necessario che la funzionalità Cloud Service Mesh sia abilitata nel progetto del parco risorse. Per consentire a asmcli di attivare automaticamente questa funzionalità durante l'installazione o l'upgrade, devi eseguire il comando asmcli con il flag --enable_gcp_components.