Limiti di scalabilità per Cloud Service Mesh su GKE

Questo documento descrive i limiti di scalabilità del control plane per le architetture Cloud Service Mesh gestite su GKE, in modo che tu possa prendere decisioni informate in merito ai tuoi deployment.

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 control plane. Per le best practice sulla scalabilità del data plane, consulta Best practice per la scalabilità.

Alcuni dei limiti di scalabilità documentati vengono applicati dalle limitazioni delle quote. Il superamento di questi limiti richiederà richieste di aumento della quota. Altri non sono applicati rigorosamente, ma se superati possono portare a un comportamento e a prestazioni non definiti.

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

Limiti di scalabilità del servizio

La scalabilità del servizio è limitata lungo due dimensioni

Tieni presente che una volta abilitato Cloud Service Mesh per una determinata appartenenza (ad es.cluster cluster GKE), tutti i servizi Kubernetes nel cluster vengono tradotti in servizi Cloud Service Mesh, inclusi quelli che hanno come target 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 è regionale, vengono creati gruppi di endpoint di rete 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 i 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 creerà 4 servizi Cloud Service Mesh aggiuntivi, 2 per ogni sottoinsieme, per un totale di 6 servizi Cloud Service Mesh.

Deployment multi-progetto

Quando viene eseguito il deployment di un singolo mesh nei carichi di lavoro in progetti diversi, Google Cloud tutte le risorse di servizio Cloud Service Mesh vengono create nel progetto 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 sul networking di Kubernetes.

Risorse sidecar Istio

Per l'API Istio Sidecar, si applicano i seguenti limiti:

  • Sidecar senza workloadSelector: 150 per cluster

  • Sidecar con workloadSelector: 20 per cluster

Limiti di scalabilità degli endpoint

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

  • Servizio Cloud Service Mesh

  • Cluster GKE

Servizi Kubernetes regolari

Le quote per 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 sul networking di Kubernetes.

Limiti dei cluster GKE

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

Limite di scalabilità del gateway

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

  • 1500 pod gateway quando utilizzi cluster GKE regionali

  • 500 pod gateway quando utilizzi cluster GKE Autopilot o zonali