Limites de scaling pour Cloud Service Mesh sur GKE

Ce document décrit les limites de scaling du plan de contrôle pour les architectures Cloud Service Mesh gérées sur GKE. Vous pouvez ainsi 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 composants principaux : le plan de données et le plan de contrôle. Ce document se concentre sur les limites de scaling du plan de contrôle. Pour connaître les bonnes pratiques d'évolutivité du plan de données, consultez Bonnes pratiques d'évolutivité.

Certaines des limites de scaling documentées sont appliquées par des restrictions de quota. Si vous les dépassez, vous devrez envoyer des demandes d'augmentation de quota. D'autres ne sont pas strictement appliquées, 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 Google Cloud ressources, consultez d'abord le guide Comprendre les ressources d'API.

Limites de scaling des services

Le scaling des services est limité selon deux dimensions :

Notez qu'une fois Cloud Service Mesh activé pour une appartenance particulière (c'est-à-dire un cluster GKE), tous les services Kubernetes du cluster sont traduits en services Cloud Service Mesh, y compris ceux qui ciblent des charges de travail sans side-car Cloud Service Mesh. Cloud Service Mesh crée des groupes de points de terminaison du 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 et 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

L'utilisation des services Cloud Service Mesh peut être suivie en examinant l'utilisation du quota BackendService dans le projet.

Déploiements multiclusters

Lorsqu'un seul maillage est déployé sur des charges de travail dans différents Google Cloud clusters, toutes les ressources de service Cloud Service Mesh sont répliquées par défaut sur tous les clusters. Cela signifie qu'un service Kubernetes déployé dans un seul cluster crée plusieurs services Cloud Service Mesh, un pour chaque cluster.

Sous-ensembles de règles de destination

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

Prenons l'exemple de la 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, la DestinationRule créera quatre services Cloud Service Mesh supplémentaires, deux pour chaque sous-ensemble, ce qui donnera un total de six services Cloud Service Mesh.

Déploiements multiprojets

Lorsqu'un seul maillage est déployé sur des charges de travail dans différents Google Cloud projets, toutes les ressources de service Cloud Service Mesh sont créées dans le projet hôte du parc. Cela signifie qu'elles sont toutes soumises aux limites de scaling de Cloud Service Mesh dans le projet hôte du parc.

Services Kubernetes sans adresse IP de cluster

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

Ressources side-car Istio

Pour l'API Istio Sidecar, les limites suivantes s'appliquent :

  • Side-car sans workloadSelector : 150 par cluster

  • Side-car avec workloadSelector : 20 par cluster

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 Kubernetes sans adresse IP de cluster

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

Limites des clusters GKE

Cloud Service Mesh est compatible avec un maximum de 20 000 points de terminaison (adresses IP de pods, instances Cloud Run, clients gRPC sans proxy) par projet.

Limite de scaling des passerelles

Lorsque vous utilisez Istio Gateways, en particulier pour mettre fin aux connexions HTTPS à l'aide d'identifiants TLS dans des secrets Kubernetes , Cloud Service Mesh est compatible avec le nombre maximal 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