Limiti di scalabilità per Cloud Service Mesh su GKE

Questo documento descrive i limiti di scalabilità del piano di controllo per le architetture Cloud Service Mesh gestite su GKE, in modo da poter prendere decisioni consapevoli in merito ai tuoi implementazioni.

Panoramica

La scalabilità di Cloud Service Mesh su GKE dipende dal funzionamento efficiente dei suoi due componenti principali, il data plane e il control plane. Questo documento si concentra sui limiti di scalabilità del piano di controllo. Consulta la sezione Best practice per la scalabilità per informazioni sulle best practice per la scalabilità del piano dati.

Alcuni dei limiti di scalabilità documentati vengono applicati da limitazioni di quota. Il superamento di queste quote richiederà richieste di aumento della quota. Altri non vengono applicati rigorosamente, ma possono portare a comportamenti e prestazioni indefiniti se superati.

Per capire come le risorse Istio vengono tradotte in risorse Google Cloud , consulta prima la guida Informazioni sulle risorse API.

Limiti di scalabilità del servizio

La scalabilità del servizio è limitata in due dimensioni

Tieni presente che, una volta attivato Cloud Service Mesh per un determinato gruppo di appartenenza (ad es.il cluster GKE), tutti i servizi Kubernetes nel cluster vengono tradotti in servizi Cloud Service Mesh, inclusi quelli che hanno come target i carichi di lavoro senza un sidecar Cloud Service Mesh. Cloud Service Mesh crea gruppi di endpoint di rete zonali per tutti i servizi nel cluster GKE. Se il cluster è a livello di regione, i gruppi di endpoint di rete vengono creati per tutte le zone del pool di nodi nella regione.

Servizi Cloud Service Mesh e servizi Kubernetes

I servizi Cloud Service Mesh non sono uguali ai servizi Kubernetes in quanto i servizi Cloud Service Mesh sono un servizio per porta.

Ad esempio, questo servizio Kubernetes viene tradotto internamente in due servizi Cloud Service Mesh, uno per ogni porta.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    -   port: 80
      targetPort: 80
      protocol: TCP
      name: http
    -   port: 443
      targetPort: 443
      protocol: TCP
      name: https

Sottoinsiemi di regole di destinazione

Quando configuri l'API Istio Destination Rule con sottoinsiemi, ogni sottoinsieme può comportare la generazione di più nuovi servizi Cloud Service Mesh.

Ad esempio, considera il seguente DestinationRule che ha come target il servizio Kubernetes definito in precedenza:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-destinationrule
spec:
  host: my-service
  subsets:
  -   name: testversion
    labels:
      version: v3
  -   name: prodversion
    labels:
      version: v2

Verranno creati nuovi servizi sintetici per ciascuno dei sottoinsiemi definiti. Se il servizio Kubernetes originale ha creato due servizi Cloud Service Mesh, DestinationRule ne creerà altri 4, 2 per ogni sottoinsieme, per un totale di 6 servizi Cloud Service Mesh.

Deployment di più progetti

Quando un singolo mesh viene implementato in più carichi di lavoro in progetti Google Cloud diversi, tutte le risorse di servizio Cloud Service Mesh vengono create nel progetto Google Cloud host del parco risorse. Ciò significa che sono tutti soggetti alle limitazioni di scalabilità di Cloud Service Mesh nel progetto host del parco risorse.

Servizi headless Kubernetes

I servizi headless Kubernetes hanno un limite inferiore rispetto ai servizi regolari. Cloud Service Mesh supporta solo 50 servizi Cloud Service Mesh headless per cluster. Per un esempio, consulta la documentazione sulla rete Kubernetes.

Limiti di scalabilità degli endpoint

I limiti di scalabilità degli endpoint sono in genere i seguenti:

  • Servizio Cloud Service Mesh

  • Cluster GKE

Servizi Kubernetes standard

Le quote di endpoint per NEG influiscono sul numero massimo di endpoint che possono appartenere a un singolo servizio Kubernetes.

Servizi headless Kubernetes

Per il servizio headless Kubernetes, Cloud Service Mesh supporta non più di 36 endpoint per servizio headless. Per un esempio, consulta la documentazione relativa alla rete Kubernetes.

Limiti dei cluster GKE

Cloud Service Mesh supporta fino a 5000 endpoint (IP dei pod) per cluster.

Limite di scalabilità del gateway

Quando utilizzi Istio Gateways, soprattutto per terminare le connessioni HTTPS utilizzando le credenziali TLS nei segreti Kubernetes, Cloud Service Mesh supporta al massimo il seguente numero di pod:

  • 1500 pod gateway quando si utilizzano cluster GKE a livello di regione

  • 500 pod gateway se utilizzi cluster GKE zonali o Autopilot