Gestion du trafic de passerelle

Autopilot Standard

---

Cette page explique le fonctionnement de la gestion du trafic Gateway.

Présentation

La mise en réseau Google Kubernetes Engine (GKE) est basée sur Cloud Load Balancing. Avec Cloud Load Balancing, une seule adresse IP Anycast gère le trafic global. La gestion du trafic de Google fournit un équilibrage de charge global et régional, un autoscaling et une gestion des capacités qui permettent de répartir le trafic de manière égale, stable et à faible latence. Grâce au contrôleur GKE Gateway, les utilisateurs de GKE peuvent utiliser le contrôle de gestion du trafic global de Google de manière déclarative et Kubernetes native.

Pour essayer de répartir le débordement de trafic entre les clusters, consultez la page Déployer l'équilibrage de charge basé sur la capacité. Pour essayer l'autoscaling basé sur le trafic, consultez la page Autoscaling basé sur le trafic de l'équilibreur de charge.

Gestion du trafic

L'équilibrage de charge, l'autoscaling et la gestion de la capacité sont les bases d'un système de gestion du trafic. Ils fonctionnent conjointement pour égaliser et stabiliser la charge du système.

• L'équilibrage de charge répartit le trafic entre les pods backend en fonction de l'emplacement, de l'état et des différents algorithmes d'équilibrage de charge.
• L'autoscaling met à l'échelle les instances dupliquées de charge de travail pour augmenter la capacité afin d'absorber davantage de trafic.
• La gestion de la capacité surveille l'utilisation des services afin que le trafic puisse déborder sur les backends avec une capacité plutôt que d'affecter la disponibilité ou les performances de l'application.

Ces capacités peuvent être combinées de différentes manières en fonction de vos objectifs. Par exemple :

• Si vous souhaitez tirer parti de VM spot à faible coût, vous souhaiterez peut-être optimiser la répartition du trafic de manière uniforme entre les VM Spots, au prix d'une latence excessive. À l'aide de l'équilibrage de charge et de la gestion de la capacité, GKE fait déborder le trafic entre les régions en fonction de la capacité, de sorte que les VM spot soient entièrement utilisées partout où elles sont disponibles.

• Si vous souhaitez optimiser la latence côté utilisateur au prix d'un surprovisionnement, vous pouvez déployer des clusters GKE dans de nombreuses régions et augmenter votre capacité de manière dynamique lorsque la charge augmente. L'utilisation de l'équilibrage de charge et de l'autoscaling GKE permet l'autoscaling du nombre de pods lorsque le trafic augmente, de sorte que le trafic ne nécessite pas de débordement vers d'autres régions. Les régions augmentent leur capacité de manière à pouvoir gérer entièrement la charge aussi près que possible des utilisateurs.

Le schéma suivant montre comment l'équilibrage de charge, l'autoscaling et la gestion de la capacité fonctionnent conjointement :

Dans le diagramme, la charge de travail du cluster gke-us a échoué. L'équilibrage de charge et la vérification de l'état drainent les connexions actives et redirige le trafic vers le cluster le plus proche. La charge de travail dans gke-asia reçoit plus de trafic que nécessaire. Elle envoie donc de la charge sur gke-eu. gke-eu reçoit plus de charge que d'habitude en raison d'événements dans gke-us et gke-asia. Par conséquent, gke-eu effectue un autoscaling pour augmenter sa capacité de trafic.

Pour en savoir plus sur la manière dont Cloud Load Balancing gère la gestion du trafic, consultez la page Gestion de la capacité à l'échelle mondiale.

Capacités de gestion du trafic

Les ressources Gateway, HTTPRoute, Service et Policy fournissent les contrôles permettant de gérer le trafic dans GKE. Le contrôleur GKE Gateway est le plan de contrôle qui surveille ces ressources.

Les fonctionnalités de gestion du trafic suivantes sont disponibles lors du déploiement de services dans GKE :

• Capacité de service : possibilité à spécifier la capacité de trafic qu'un service peut recevoir avant que les pods ne soient soumis à l'autoscaling ou que le trafic ne déborde pas vers d'autres clusters disponibles.
• Autoscaling basé sur le trafic : autoscaling des pods au sein d'un service basé sur les requêtes HTTP reçues par seconde.

• Équilibrage de charge multicluster : capacité à équilibrer la charge des services hébergés sur plusieurs clusters GKE ou plusieurs régions.

• Répartition du trafic : répartition explicite du trafic en fonction des pondérations entre les backends La répartition du trafic est compatible avec les passerelles à cluster unique en disponibilité générale.

Compatibilité de gestion du trafic

Les fonctionnalités de gestion du trafic disponibles dépendent de la classe GatewayClass que vous déployez. Pour obtenir la liste complète des fonctionnalités compatibles, consultez la section Fonctionnalités GatewayClass. Le tableau suivant récapitule la compatibilité de GatewayClass avec la gestion du trafic :

GatewayClass	Capacité de service	Autoscaling du trafic	Équilibrage de charge multicluster	Répartition du trafic^1
gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-gxlb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-rilb-mc
gke-l7-gxlb-mc

¹ La répartition du trafic est compatible avec les passerelles à cluster unique en disponibilité générale.

Équilibrage de charge global, régional et zonal

La capacité, l'emplacement et l'état du service déterminent la quantité de trafic envoyé par l'équilibreur de charge à un backend donné. Les décisions d'équilibrage de charge sont prises aux niveaux suivants : mondial pour les équilibreurs de charge mondiaux et régional pour les équilibreurs de charge régionaux :

• Mondial : le trafic est envoyé à la région Google Cloud la plus proche du client, qui dispose de backends opérationnels avec une capacité suffisante. Tant que la région dispose d'une capacité suffisante, elle reçoit tout son trafic le plus proche. Si une région n'a pas de capacité, le trafic excédentaire déborde vers la région la plus proche avec de la capacité. Pour en savoir plus, consultez la page sur l'équilibrage de charge au niveau mondial.
• Régional : le trafic est envoyé par l'équilibreur de charge à une région spécifique. Le trafic est équilibré entre les zones en fonction de la capacité de diffusion disponible de la zone. Pour en savoir plus, consultez la page Équilibrage de charge régional.
• Zonal : une fois le trafic déterminé pour une zone spécifique, l'équilibreur de charge le répartit équitablement entre les backends de cette zone. Les connexions TCP existantes et les paramètres de persistance de session sont conservés, de sorte que les futures requêtes soient adressées aux mêmes backends, tant que le pod de backend est opérationnel. Pour en savoir plus, consultez la page Équilibrage de charge zonal.

Équilibrage de charge au niveau mondial et débordement du trafic

Pour essayer les concepts suivants dans votre propre cluster, consultez la page Équilibrage de charge basé sur la capacité.

Dans des conditions normales, le trafic est envoyé au backend le plus proche du client. Le trafic s'arrête au point de présence Google le plus proche du client, puis traverse le réseau backbone Google jusqu'à atteindre le backend le plus proche, comme déterminé par la latence du réseau. Lorsque les backends d'une région n'ont plus de capacité disponible, le trafic déborde sur le cluster le plus proche avec des backends opérationnels ayant la capacité disponible. Si moins de 50% des pods backend d'une zone sont défectueux, le trafic bascule progressivement vers d'autres zones ou régions, indépendamment de la capacité configurée.

Le débordement du trafic ne se produit que dans les conditions suivantes :

• Vous utilisez une passerelle multicluster.
• Le même service est déployé sur plusieurs clusters, via la passerelle multicluster.
• Vous avez configuré des capacités de service de sorte que le trafic dépasse les capacités de service d'un cluster, mais pas des autres.

Le schéma suivant illustre le fonctionnement de l'équilibrage de charge global avec un débordement de trafic :

Dans le diagramme :

• Une passerelle multicluster fournit un équilibrage de charge Internet global pour le service store. Le service est déployé sur deux clusters GKE, un dans us-west1 et un autre dans europe-west1. Chaque cluster exécute deux instances dupliquées.
• Chaque service est configuré avec max-rate-per-endpoint="10", ce qui signifie que chaque service a une capacité totale de deux instances dupliquées x 10 RPS = 20 RPS dans chaque cluster.
• Les POP Google en Amérique du Nord reçoivent six RPS. L'ensemble du trafic est envoyé au backend opérationnel le plus proche disposant d'une capacité suffisante, le cluster GKE dans us-west1.
• Les POP européens reçoivent 30 RPS cumulées. Les backends les plus proches se trouvent dans europe-west1, mais ils n'ont qu'une capacité de 20 RPS. Comme les backends de us-west1 ont une capacité excédentaire, 10 RPS débordent sur us-west1 afin qu'il reçoive 16 RPS au total et distribue 8 RPS dans chaque pod.

Remarque : Si vous utilisez des passerelles à cluster unique, un service de type LoadBalancer ou des ressources Ingress, cet exemple d'équilibrage de charge global ne s'applique pas, car ces ressources ne gèrent qu'un seul cluster au sein d'une même région. Les passerelles multiclusters sont recommandées si vous avez des exigences globales d'équilibrage de charge.

Prévenir le débordement du trafic

Le débordement du trafic permet d'éviter de dépasser la capacité de l'application, ce qui peut affecter les performances ou la disponibilité.

Toutefois, vous souhaiterez peut-être faire déborder le trafic. Les applications sensibles à la latence, par exemple, peuvent ne pas bénéficier d'un débordement du trafic vers un backend beaucoup plus distant.

Vous pouvez utiliser l'une des méthodes suivantes pour éviter le débordement du trafic :

• N'utilisez que des passerelles à cluster unique pouvant héberger des services dans un seul cluster.

• Même si vous utilisez des passerelles multiclusters, les instances dupliquées d'une application déployée sur plusieurs clusters peuvent être déployées en tant que services distincts. Du point de vue de la passerelle, cela active l'équilibrage de charge multicluster, mais n'agrège pas tous les points de terminaison d'un service entre les clusters.

• Définissez des capacités de service à un niveau suffisamment élevé pour que la capacité du trafic ne soit jamais dépassée de manière réaliste, sauf si cela est absolument nécessaire.

Équilibrage de charge dans une région

Dans une région, le trafic est réparti entre les zones en fonction des capacités disponibles des backends. Il n'utilise pas de débordement, mais un équilibrage de charge directement proportionnel aux capacités de service de chaque zone. Les flux ou sessions individuels sont toujours envoyés à un pod de backend cohérent et unique, et ne sont pas répartis.

Le schéma suivant montre la répartition du trafic au sein d'une région :

Dans le diagramme :

• Un service est déployé dans un cluster GKE régional. Le service dispose de quatre pods qui sont déployés de manière inégale entre les zones. 3 pods sont dans la zone A, 1 pod est dans la zone B et 0 pods sont dans la zone C.
• Le service est configuré avec max-rate-per-endpoint="10". La zone A a une capacité totale de 30 RPS, la zone B a une capacité totale de 10 RPS et la zone C a une capacité totale de 0 RPS, car elle ne comporte pas de pod.
• La passerelle reçoit un total de 16 RPS de trafic provenant de différents clients. Ce trafic est réparti entre des zones proportionnellement à la capacité restante dans chaque zone.
• Le flux de trafic provenant de n'importe quelle source ou client est équilibré de manière cohérente vers un pod de backend unique en fonction des paramètres de persistance de la session. La répartition du trafic se divise entre différents flux de trafic sources, de sorte que les flux individuels ne sont jamais répartis. Par conséquent, une diversité minimale de la source ou du client est requise pour répartir le trafic de manière précise entre les backends.

Par exemple, si le trafic entrant passe de 16 RPS à 60 RPS, l'un des scénarios suivants se produit :

• Si vous utilisez des passerelles à cluster unique, il n'y a pas d'autres clusters ni régions vers lesquels le trafic peut déborder. Le trafic continue d'être distribué en fonction des capacités zonales relatives, même si le trafic entrant dépasse la capacité totale. Par conséquent, la zone A reçoit 45 RPS et la zone B reçoit 15 RPS.
• Si vous utilisez des passerelles multiclusters avec des services répartis sur plusieurs clusters, le trafic peut déborder vers d'autres clusters et d'autres régions, comme décrit dans la section Équilibrage de charge au niveau mondial et débordement du trafic. La zone A reçoit 30 RPS, la zone B reçoit 10 RPS et 20 RPS débordent sur un autre cluster.

Remarque : Cloud Load Balancing ne supprime pas automatiquement le trafic lorsque les backends sont en surcapacité. Le trafic déborde vers les backends disponibles disposant d'une capacité suffisante. Si tous les backends sont en surcapacité, le débordement de trafic est alors réparti entre tous les backends proportionnellement à leurs capacités totales. Cela dépasse la capacité totale du service.

Équilibrage de charge dans une zone

Une fois le trafic envoyé à une zone, il est réparti uniformément entre tous les backends de cette zone. Les sessions HTTP sont persistantes en fonction du paramètre d'affinité de session. À moins que le backend ne devienne indisponible, les connexions TCP existantes ne sont jamais transférées vers un backend différent. Cela signifie que les connexions de longue durée continuent vers le même pod de backend, même si de nouvelles connexions débordent en raison d'une capacité limitée. L'équilibreur de charge donne la priorité aux connexions existantes par rapport aux nouvelles.

Capacité de service

Avec la capacité de service, vous pouvez définir une valeur de requêtes par seconde (RPS) par pod dans un service. Cette valeur représente le nombre maximal de RPS par pod en moyenne qu'un service peut recevoir. Cette valeur peut être configurée sur les services et permet de déterminer l'autoscaling basé sur le trafic et l'équilibrage de charge basé sur la capacité.

Conditions requises

La capacité de service est soumise aux exigences et limites suivantes :

• Compatible uniquement avec les ressources GatewayClass et les types d'entrée définis dans la section Compatibilité avec la gestion du trafic.

• N'affecte l'équilibrage de charge que si vous utilisez l'autoscaling basé sur le trafic ou des passerelles multiclusters. Si vous n'utilisez pas ces fonctionnalités, la capacité de service n'a aucun effet sur le trafic réseau.

Configurer la capacité de service

Pour configurer la capacité de service, créez un service à l'aide de l'annotation networking.gke.io/max-rate-per-endpoint. Le fichier manifeste ci-dessous décrit un service avec un nombre maximal de RPS :

apiVersion: v1
kind: Service
metadata:
  name: store
  annotations:
    networking.gke.io/max-rate-per-endpoint: "RATE_PER_SECOND"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

Remplacez RATE_PER_SECOND par le nombre maximal de requêtes HTTP/HTTPS par seconde qu'un seul pod de ce service doit recevoir.

La valeur max-rate-per-endpoint crée une capacité dynamique pour un service en fonction du nombre de pods du service. La valeur totale de la capacité du service est calculée en multipliant la valeur max-rate-per-endpoint par le nombre d'instances dupliquées, comme décrit dans la formule suivante :

Total Service capacity = max-rate-per-endpoint * number of replicas

Si un autoscaler augmente le nombre de pods d'un service, la capacité totale du service est calculée en conséquence. Si un service est réduit à zéro pod, il dispose d'une capacité nulle et ne reçoit aucun trafic en provenance de l'équilibreur de charge.

Remarque : La configuration de la capacité de service utilisant l'annotation max-rate-per-endpoint ne s'applique qu'au trafic entrant via une passerelle compatible. Il n'a pas d'incidence sur l'équilibrage de charge basé sur la capacité pour l'équilibrage de charge ClusterIP à l'intérieur du cluster ou pour les services de type LoadBalancer.

Capacité du service et NEG autonomes

La capacité de service peut également être configurée lorsque vous utilisez des NEG autonomes, mais elle n'utilise pas l'annotation max-rate-per-endpoint. Lorsque vous utilisez des NEG autonomes, le max-rate-per-endpoint est configuré manuellement lors de l'ajout du NEG à une ressource du service de backend. À l'aide de la commande gcloud compute backend-services add- backend, l'indicateur --max-rate-per-endpoint peut configurer la capacité de chaque NEG individuellement.

Cela peut être utile dans les workflows suivants :

• Lorsque vous déployez manuellement des équilibreurs de charge internes et externes à l'aide de NEG autonomes
• Lors du déploiement de Cloud Service Mesh sur GKE à l'aide de NEG autonomes

Il n'existe aucune différence fonctionnelle lors de la configuration de la capacité de service avec des NEG autonomes. L'autoscaling du trafic et le débordement de trafic sont tous deux acceptés.

Déterminer la capacité de votre service

Pour déterminer la valeur de max-rate-per-endpoint, vous devez comprendre les caractéristiques de performance de votre application et vos objectifs d'équilibrage de charge. Les stratégies suivantes peuvent vous aider à définir les caractéristiques de performances de votre application :

• Observez votre application dans les environnements de test et de production lorsqu'elle est configurée sans capacité de service.
• Utilisez Cloud Monitoring pour créer une corrélation entre les requêtes de trafic et vos objectifs de niveau de service (SLO) de performances.

• Utilisez des métriques d'équilibreur de charge, telles que https ou request_count, pour mapper les niveaux RPS.

• Définissez les SLO de performances pour votre application. Ils peuvent correspondre à l'un ou plusieurs des éléments suivants, en fonction de ce que vous considérez comme "mauvais" ou "instable". Tous les éléments suivants peuvent être collectés à partir des métriques de l'équilibreur de charge Cloud Monitoring :
  • Codes d'erreur
  • Réponse ou latence totale
  • Indisponibilité ou temps d'arrêt du backend
• Observez votre application dans des conditions de charge du trafic tant dans les environnements de test que de production. Dans les environnements de test, soumettez votre application à une augmentation de la charge des requêtes afin de pouvoir voir comment les différentes métriques de performances sont affectées à mesure que le trafic augmente. Dans les environnements de production, observez des niveaux de modèles de trafic réalistes.

Capacité de service par défaut

Une capacité de service par défaut est définie pour tous les services associés aux ressources GKE, même si elle n'est pas explicitement configurée à l'aide de l'annotation. Pour en savoir plus, consultez la section Capacité de service par défaut.

Le tableau suivant décrit les capacités par défaut :

Type de ressource d'équilibrage de charge	max-rate-per-endpoint par défaut
Ingress (interne et externe)	1 RPS
Gateway (toutes les GatewayClasses)	100 000 000 RPS
MultiClusterIngress	100 000 000 RPS

Autoscaling basé sur le trafic

L'autoscaling basé sur le trafic est une fonctionnalité de GKE qui intègre nativement les signaux de trafic des équilibreurs de charge aux pods d'autoscaling. L'autoscaling basé sur le trafic n'est disponible que pour les passerelles à cluster unique.

Pour utiliser l'autoscaling basé sur le trafic, consultez la page Autoscaling basé sur le trafic de l'équilibreur de charge.

L'autoscaling basé sur le trafic offre les avantages suivants :

• Les applications qui ne sont pas strictement liées au processeur ou à la mémoire peuvent avoir des limites de capacité qui ne sont pas reflétées dans leur utilisation du processeur ou de la mémoire.
• Dans certains cas, le trafic ou les requêtes par seconde est plus facile à comprendre, car il est plus adapté à l'utilisation des applications et aux métriques commerciales, telles que les pages vues ou les utilisateurs actifs par jour.
• Le trafic est un indicateur principal qui représente une demande instantanée par rapport au processeur ou à la mémoire, qui sont des indicateurs de retard.
• La combinaison des métriques du processeur, de la mémoire et de l'autoscaling du trafic offre un moyen holistique d'effectuer un autoscaling des applications qui utilise plusieurs dimensions pour garantir que la capacité est correctement provisionnée.

Le schéma suivant illustre le fonctionnement de l'autoscaling basé sur le trafic :

Dans le diagramme :

• Le propriétaire du service configure la capacité de service et une utilisation cible pour le déploiement.
• La passerelle reçoit le trafic des clients allant vers le service store. La passerelle envoie la télémétrie d'utilisation à l'autoscaler de pod GKE. L'utilisation est égale au trafic réel reçu par un pod individuel, divisé par la capacité configurée du pod.
• L'autoscaler de pod GKE effectue un scaling des pods à la hausse ou à la baisse en fonction de l'utilisation cible configurée.

Comportement d'autoscaling

Le schéma suivant illustre le fonctionnement de l'autoscaling basé sur le trafic sur une application recevant 10 RPS via l'équilibreur de charge :

Dans le diagramme, le propriétaire du service a configuré la capacité du service de magasin sur 10 RPS, ce qui signifie que chaque pod peut recevoir un maximum de 10 RPS. L'élément HorizontalPodAutoscaler est configuré avec averageUtilization est défini sur 70, ce qui signifie que l'utilisation cible est de 70% de 10 RPS par pod.

L'autoscaler tente de procéder au scaling des instances dupliquées pour obtenir l'équation suivante :

replicas = ceiling[ current traffic / ( averageUtilization * max-rate-per-endpoint) ]

Dans le diagramme, cette équation calcule :

ceiling[ 10 rps / (0.7 * 10 rps) ] = ceiling[ 1.4 ] = 2 replicas

10 RPS de trafic génèrent deux instances dupliquées. Chaque instance dupliquée reçoit 6 RPS, ce qui est inférieur à l'utilisation cible de 7 RPS.

Remarque : Les modifications de niveau de trafic ou des pics de trafic peuvent entraîner l'approximation de l'équation des instances dupliquées cibles par l'autoscaler. Dans des conditions d'état stable, la quantité d'instances dupliquées approche la cible, mais elle n'est pas toujours exacte, en particulier lorsque le trafic varie.

Répartition du trafic

La répartition du trafic utilise un ratio explicite, appelé pondération, qui définit la proportion des requêtes HTTP envoyées à un service. Les ressources HTTPRoute vous permettent de configurer des pondérations sur une liste de services. Les pondérations relatives entre les services définissent la répartition du trafic entre eux. Cela s'avère utile pour répartir le trafic lors des déploiements, des modifications Canary ou des situations d'urgence.

Le schéma suivant décrit un exemple de configuration de répartition du trafic :

Dans le diagramme :

• Le propriétaire du service configure deux services pour une seule route, avec une règle de répartition du trafic de 90 % vers store-v1 et de 10 % vers store-v2.
• La passerelle reçoit le trafic des clients acheminés vers l'URL de l'application du magasin. Le trafic est réparti selon la règle configurée : 90 % des routes du trafic vers store-v1 et 10 % des routes vers store-v2.

La répartition du trafic est acceptée entre les services d'un même cluster et entre les services de différents clusters :

• Répartition du trafic entre les services : permet de répartir le trafic pour les déploiements de versions d'applications. En utilisant l'exemple de répartition du trafic, vous obtiendrez deux déploiements distincts, store-v1 et store-v2, qui possèdent chacun leur propre service, store-v1 et store-v2. Les pondérations sont configurées entre les deux services pour basculer progressivement le trafic jusqu'à ce que store-v2 soit complètement déployé.

  Remarque : La GatewayClass gke-l7-gxlb n'est pas compatible avec la répartition du trafic.

• Répartition du trafic entre ServiceImports : permet de déplacer le trafic vers ou depuis des clusters spécifiques à des fins de maintenance, de migration ou d'urgence. Les objets ServiceImport représentent des services multiclusters et permettent de répartir le trafic entre différents services sur différents clusters. L'exercice Routage bleu-vert multicluster avec passerelle illustre la répartition du trafic entre les clusters.

  Remarque : La GatewayClass gke-l7-gxlb-mc n'est pas compatible avec la répartition du trafic.

Weight et capacité

Les pondérations et les capacités contrôlent toutes deux le volume de trafic envoyé à différents services. Bien qu'elles aient des effets similaires, elles fonctionnent différemment et présentent des cas d'utilisation différents. Elles peuvent, et même doivent, être utilisées conjointement à des fins différentes.

Poids

La pondération est un contrôle explicite du trafic. Elle définit les proportions exactes du trafic, indépendamment du trafic entrant et de l'utilisation du backend. Dans l'exemple de répartition du trafic, si store-v2 était en surcapacité ou si toutes ses instances dupliquées ont échoué, 10% du trafic reste alloué à  : store-v2, ce qui peut entraîner la suppression du trafic. En effet, le poids ne modifie pas la proportion du trafic en fonction de l'utilisation ou de l'état.

La pondération est mieux adaptée aux cas d'utilisation suivants :

• Basculer le trafic entre différentes versions d'un service pour les déploiements
• Intégrer manuellement des services à l'aide de répartitions de trafic explicites
• Déplacement du trafic hors d'un ensemble de backends à des fins d'urgence ou de maintenance.

Capacité

La capacité est un contrôle implicite du trafic. Elle définit indirectement les proportions du trafic, car elles dépendent de la quantité de trafic entrant, de l'utilisation du backend et de l'emplacement source du trafic. La capacité est une propriété inhérente à un service et est généralement mise à jour beaucoup moins fréquemment.

La capacité est mieux adaptée aux cas d'utilisation suivants :

• Prévenir la surutilisation du backend lors des pics de trafic
• Contrôler le taux d'autoscaling par rapport au trafic

La configuration de la capacité de service pour faire déborder le trafic peut ne pas toujours être le comportement souhaité. Considérons l'exemple d'équilibrage de charge global. La capacité de service protège les backends contre la surutilisation en faisant déborder le trafic, mais cela peut entraîner une latence supplémentaire pour les requêtes qui ont débordé, car ces requêtes se déplacent vers une région plus distante.

Si votre application n'est pas très sensible à la surutilisation, vous pouvez configurer une capacité de service très élevée pour que le trafic ne risque pas de déborder vers une autre région. Si la disponibilité ou la latence de votre application est sensible à la surutilisation, le débordement du trafic vers d'autres clusters ou régions peut être préférable à l'absorption du trafic excédentaire sur des backends surexploités. Pour en savoir plus sur la configuration de la capacité de service de votre application, consultez la page Déterminer la capacité de votre service.

Étape suivante

• Découvrez comment déployer des passerelles.

• Découvrez comment déployer des passerelles multiclusters.