Limites de mise à l'échelle pour Cloud Service Mesh sur GKE

Ce document décrit les limites de mise à l'échelle du plan de contrôle pour les architectures Cloud Service Mesh gérées sur GKE afin que vous puissiez prendre des décisions éclairées concernant vos déploiements.

Présentation

L'évolutivité de Cloud Service Mesh sur GKE dépend du fonctionnement efficace de ses deux principaux composants, le plan de données et le plan de contrôle. Ce document porte sur les limites de mise à l'échelle du plan de contrôle. Consultez les bonnes pratiques d'évolutivité pour découvrir les bonnes pratiques d'évolutivité du plan de données.

Certaines des limites de mise à l'échelle documentées sont appliquées par des restrictions de quota. Si vous les dépassez, vous devrez demander une augmentation de quota. D'autres ne sont pas strictement appliqués, mais peuvent entraîner un comportement et des performances non définis si elles sont dépassées.

Pour comprendre comment les ressources Istio sont traduites en ressources Google Cloud , consultez d'abord le guide Comprendre les ressources de l'API.

Limites de scaling de service

L'évolutivité des services est limitée dans deux dimensions

Notez qu'une fois Cloud Service Mesh activé pour une appartenance spécifique (par exemple, un cluster GKE), tous les services Kubernetes du cluster sont convertis en services Cloud Service Mesh, y compris ceux qui ciblent des charges de travail sans sidecar Cloud Service Mesh. Cloud Service Mesh crée des groupes de points de terminaison réseau zonaux pour tous les services du cluster GKE. Si le cluster est régional, des groupes de points de terminaison du réseau sont créés pour toutes les zones de pool de nœuds de la région.

Services Cloud Service Mesh par rapport aux services Kubernetes

Les services Cloud Service Mesh ne sont pas identiques aux services Kubernetes, car ils correspondent à un service par port.

Par exemple, ce service Kubernetes est traduit en interne en deux services Cloud Service Mesh, un pour chaque port.

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

Sous-ensembles de règles de destination

Lorsque vous configurez l'API Istio Destination Rule avec des sous-ensembles, chaque sous-ensemble peut générer plusieurs nouveaux services Cloud Service Mesh.

Prenons l'exemple de l'DestinationRule suivante qui cible le service Kubernetes défini précédemment:

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

De nouveaux services synthétiques seront créés pour chacun des sous-ensembles définis. Si le service Kubernetes d'origine a créé deux services Cloud Service Mesh, DestinationRule en créera quatre autres, deux pour chaque sous-ensemble, soit un total de six services Cloud Service Mesh.

Déploiements multiprojets

Lorsqu'un seul réseau maillé est déployé sur des charges de travail dans différents projets Google Cloud, toutes les ressources de service Cloud Service Mesh sont créées dans le projet hôte de la flotte. Cela signifie qu'ils sont tous soumis aux limites de scalabilité de Cloud Service Mesh dans le projet hôte de parc.

Services headless Kubernetes

Les services headless Kubernetes ont une limite inférieure par rapport aux services standards. Cloud Service Mesh n'est compatible qu'avec 50 services Cloud Service Mesh sans adresse IP par cluster. Pour obtenir un exemple, consultez la documentation sur la mise en réseau Kubernetes.

Limites de scaling des points de terminaison

Les limites de scaling des points de terminaison sont généralement les suivantes:

  • Service Cloud Service Mesh

  • Cluster GKE

Services Kubernetes standards

Les quotas de points de terminaison par NEG affectent le nombre maximal de points de terminaison pouvant appartenir à un seul service Kubernetes.

Services headless Kubernetes

Pour les services Kubernetes sans interface graphique, Cloud Service Mesh n'est compatible qu'avec 36 points de terminaison par service sans interface graphique. Pour obtenir un exemple, consultez la documentation sur la mise en réseau Kubernetes.

Limites des clusters GKE

Cloud Service Mesh accepte jusqu'à 5 000 points de terminaison (adresses IP de pods) par cluster.

Limite de scaling de la passerelle

Lorsque vous utilisez des passerelles Istio, en particulier pour terminer les connexions HTTPS à l'aide d'identifiants TLS dans des secrets Kubernetes, Cloud Service Mesh accepte au maximum le nombre de pods suivant:

  • 1 500 pods de passerelle lorsque vous utilisez des clusters GKE régionaux

  • 500 pods de passerelle lorsque vous utilisez des clusters GKE zonaux ou Autopilot