Gestion du trafic de passerelle

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.

Grâce à GKE Gateway Controller, les utilisateurs de GKE peuvent contrôler la gestion du trafic de manière déclarative et Kubernetes native.

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.

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.

• 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 :

Équilibrage de charge 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 :

• Régional : le trafic est équilibré en charge entre les zones en fonction de la capacité de diffusion disponible de la zone. Pour en savoir plus, consultez la section Équilibrage de charge dans une région.
• 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.

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.

• 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, il n'y a pas d'autres clusters 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.

É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. Sinon, 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.

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 lorsque vous déployez manuellement des équilibreurs de charge internes et externes à 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.

• 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 :

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.

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.

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 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é.

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

Étape suivante

• Découvrez comment déployer des passerelles.