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
Per progetto: sono supportati un massimo di 1000 servizi Cloud Service Mesh perGoogle Cloud progetto (ad eccezione dei servizi headless Kubernetes).
Per zona per progetto: poiché Cloud Service Mesh crea gruppi di endpoint di rete per zona per i servizi GKE nel cluster, i limiti di quota NEG a livello di zona si applicano al numero di servizi per progetto che possono avere endpoint in quella zona.
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 clusterSidecar 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