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 pourrez ainsi prendre des décisions éclairées concernant vos déploiements.

Présentation

La scalabilité 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 scaling du plan de contrôle. Pour connaître les bonnes pratiques en matière d'évolutivité du plan de données, consultez Bonnes pratiques en matière d'évolutivité.

Certaines limites de scaling 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ées, mais peuvent entraîner un comportement et des performances indé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 d'API.

Limites de scaling des services

La mise à l'échelle des services est limitée selon deux dimensions.

Notez qu'une fois Cloud Service Mesh activé pour une appartenance spécifique (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 les services Cloud Service Mesh sont 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 entraîner la génération de plusieurs services Cloud Service Mesh.

Par exemple, prenons l'DestinationRule suivant 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 créera quatre services Cloud Service Mesh supplémentaires (deux pour chaque sous-ensemble), ce qui portera le nombre total de services Cloud Service Mesh à six.

Déploiements multiprojets

Lorsqu'un seul maillage 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 du parc. 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 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 par cluster. Pour obtenir un exemple, consultez la documentation sur la mise en réseau Kubernetes.

Ressources de side-car Istio

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

  • Side-car sans workloadSelector : 150 par cluster

  • Sidecar 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 même service Kubernetes.

Services headless Kubernetes

Pour les services Kubernetes sans adresse IP de cluster, Cloud Service Mesh n'accepte pas plus de 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 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 mettre fin aux connexions HTTPS à l'aide d'identifiants TLS dans les secrets Kubernetes, Cloud Service Mesh prend en charge 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