Bonnes pratiques d'ajustement de l'échelle pour Cloud Service Mesh sur GKE

Ce guide décrit les bonnes pratiques à suivre pour résoudre les problèmes de mise à l'échelle des architectures Cloud Service Mesh gérées sur Google Kubernetes Engine. L'objectif principal de ces recommandations est de garantir des performances, une fiabilité et une utilisation optimales des ressources pour vos applications de microservices à mesure qu'elles se développent.

Pour comprendre les limites d'évolutivité, consultez la section Limites d'évolutivité de Cloud Service Mesh.

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 se concentre principalement sur la mise à l'échelle du plan de données.

Identifier les problèmes de scaling du plan de contrôle par rapport au plan de données

Dans Cloud Service Mesh, des problèmes de mise à l'échelle peuvent se produire au niveau du plan de contrôle ou du plan de données. Voici comment identifier le type de problème de mise à l'échelle que vous rencontrez:

Symptômes des problèmes de scaling du plan de contrôle

Détection de services lente:la découverte et la mise à disposition de nouveaux services ou points de terminaison prennent beaucoup de temps.

Retard de configuration:les modifications apportées aux règles de gestion du trafic ou aux règles de sécurité prennent beaucoup de temps à se propager.

Augmentation de la latence dans les opérations du plan de contrôle:les opérations telles que la création, la mise à jour ou la suppression de ressources Cloud Service Mesh deviennent lentes ou ne répondent plus.

Erreurs liées à Traffic Director:vous pouvez observer des erreurs dans les journaux Cloud Service Mesh ou les métriques du plan de contrôle indiquant des problèmes de connectivité, d'épuisement des ressources ou de limitation de l'API.

Champ d'application:les problèmes de plan de contrôle affectent généralement l'ensemble du réseau maillé, ce qui entraîne une dégradation généralisée des performances.

Symptômes des problèmes de scaling du plan de données

Augmentation de la latence dans la communication de service à service:les requêtes envoyées à un service dans le maillage présentent une latence ou des délais avant expiration plus élevés, mais l'utilisation du processeur/de la mémoire dans les conteneurs du service n'est pas élevée.

Utilisation élevée du processeur ou de la mémoire dans les proxys Envoy:une utilisation élevée du processeur ou de la mémoire peut indiquer que les proxys ont du mal à gérer la charge de trafic.

Impact localisé:les problèmes de plan de données affectent généralement des services ou des charges de travail spécifiques, en fonction des tendances de trafic et de l'utilisation des ressources des proxys Envoy.

Évoluer le plan de données

Pour faire évoluer le plan de données, essayez les techniques suivantes:

Configurer l'autoscaling horizontal des pods (HPA) pour les charges de travail

Utilisez l'autoscaling horizontal de pods (HPA) pour faire évoluer de manière dynamique les charges de travail avec des pods supplémentaires en fonction de l'utilisation des ressources. Tenez compte des points suivants lorsque vous configurez HPA:

  • Utilisez le paramètre --horizontal-pod-autoscaler-sync-period pour kube-controller-manager afin d'ajuster la fréquence d'interrogation du contrôleur HPA. Le taux de sondage par défaut est de 15 secondes. Vous pouvez le définir sur une valeur inférieure si vous prévoyez des pics de trafic plus rapides. Pour savoir quand utiliser un HPA avec GKE, consultez la section Autoscaling horizontal des pods.

  • Le comportement de mise à l'échelle par défaut peut entraîner le déploiement (ou l'arrêt) simultané d'un grand nombre de pods, ce qui peut entraîner une forte augmentation de l'utilisation des ressources. Envisagez d'utiliser des stratégies de mise à l'échelle pour limiter la vitesse de déploiement des pods.

  • Utilisez EXIT_ON_ZERO_ACTIVE_CONNECTIONS pour éviter de perdre des connexions lors de la réduction de l'échelle.

Pour en savoir plus sur les HPA, consultez la section Autoscaling horizontal des pods dans la documentation Kubernetes.

Optimiser la configuration du proxy Envoy

Pour optimiser la configuration du proxy Envoy, tenez compte des recommandations suivantes:

Limites de ressources

Vous pouvez définir des requêtes et des limites de ressources pour les sidecars Envoy dans les spécifications de vos pods. Cela évite les conflits de ressources et garantit des performances cohérentes.

Vous pouvez également configurer des limites de ressources par défaut pour tous les proxys Envoy de votre réseau maillé à l'aide d'annotations de ressources.

Les limites de ressources optimales pour vos proxys Envoy dépendent de facteurs tels que le volume de trafic, la complexité de la charge de travail et les ressources de nœud GKE. Surveillez et affinez en continu votre service mesh pour garantir des performances optimales.

Remarque importante :

  • Qualité de service (QoS) : définir à la fois les requêtes et les limites garantit une qualité de service prévisible pour vos proxys Envoy.

Dépendances de services de portée

Envisagez de réduire le graphique des dépendances de votre réseau maillé en déclarant toutes vos dépendances via l'API Sidecar. Cela limite la taille et la complexité de la configuration envoyée à une charge de travail donnée, ce qui est essentiel pour les maillages plus importants.

Voici un exemple de graphique de trafic pour l'application exemple de boutique en ligne.

Arbre du graphique de trafic de l'exemple d'application Online Boutique avec de nombreuses feuilles

Beaucoup de ces services sont des feuilles dans le graphique et, par conséquent, n'ont pas besoin d'informations de sortie pour les autres services du maillage. Vous pouvez appliquer une ressource Sidecar limitant la portée de la configuration du sidecar pour ces services de feuilles, comme illustré dans l'exemple suivant.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: leafservices
  namespace: default
spec:
  workloadSelector:
    labels:
      app: cartservice
      app: shippingservice
      app: productcatalogservice
      app: paymentservice
      app: emailservice
      app: currencyservice
  egress:
  -   hosts:
    -   "~/*"

Pour savoir comment déployer cet exemple d'application, consultez Exemple d'application Boutique en ligne.

Un autre avantage de la définition du champ d'application du sidecar est la réduction des requêtes DNS inutiles. L'énumération des dépendances de service garantit qu'un sidecar Envoy n'effectue des requêtes DNS que pour les services avec lesquels il communiquera réellement, et non pour tous les clusters du maillage de services.

Pour tous les déploiements à grande échelle qui rencontrent des problèmes de taille de configuration élevée dans leurs sidecars, il est fortement recommandé de définir le champ d'application des dépendances de service pour la scalabilité du maillage.

Surveiller et ajuster

Après avoir défini les limites de ressources initiales, il est essentiel de surveiller vos proxys Envoy pour vous assurer qu'ils fonctionnent de manière optimale. Utilisez les tableaux de bord GKE pour surveiller l'utilisation du processeur et de la mémoire, et ajuster les limites de ressources si nécessaire.

Pour déterminer si un proxy Envoy nécessite une augmentation des limites de ressources, surveillez sa consommation de ressources dans des conditions de trafic normales et de pointe. Voici ce que vous devez rechercher:

  • Utilisation élevée du processeur:si l'utilisation du processeur d'Envoy approche ou dépasse régulièrement sa limite, il est possible qu'il ait du mal à traiter les requêtes, ce qui entraîne une augmentation de la latence ou des requêtes abandonnées. Envisagez d'augmenter la limite de processeur.

    Dans ce cas, vous pouvez être tenté d'utiliser l'ajustement horizontal, mais si le proxy du sidecar ne parvient pas systématiquement à traiter les requêtes aussi rapidement que le conteneur de l'application, l'ajustement des limites de processeur peut donner les meilleurs résultats.

  • Utilisation élevée de la mémoire:si l'utilisation de la mémoire d'Envoy approche ou dépasse sa limite, il peut commencer à abandonner des connexions ou à rencontrer des erreurs de mémoire insuffisante (OOM). Augmentez la limite de mémoire pour éviter ces problèmes.

  • Journaux d'erreurs:examinez les journaux d'Envoy pour rechercher les erreurs liées à l'épuisement des ressources, telles que les erreurs erreur de connexion en amont, déconnexion ou réinitialisation avant les en-têtes ou trop de fichiers ouverts. Ces erreurs peuvent indiquer que le proxy a besoin de plus de ressources. Pour découvrir d'autres erreurs liées aux problèmes de mise à l'échelle, consultez la documentation de dépannage de la mise à l'échelle.

  • Métriques de performances:surveillez les métriques de performances clés telles que la latence des requêtes, les taux d'erreurs et le débit. Si vous constatez une dégradation des performances en corrélation avec une utilisation élevée des ressources, il peut être nécessaire d'augmenter les limites.

En définissant et en surveillant activement les limites de ressources pour vos proxys de plan de données, vous pouvez vous assurer que votre service mesh se met à l'échelle efficacement sur GKE.

Évoluer le plan de contrôle

Cette section décrit les paramètres à ajuster pour mettre à l'échelle votre plan de contrôle.

Sélecteurs de découverte

Les sélecteurs de découverte sont un champ de MeshConfig qui vous permet de spécifier l'ensemble d'espaces de noms que les plans de contrôle prennent en compte lors du calcul des mises à jour de configuration pour les sidecars.

Par défaut, Cloud Service Mesh surveille tous les espaces de noms du cluster. Cela peut constituer un goulot d'étranglement pour les grands clusters qui n'ont pas besoin de surveiller toutes les ressources.

Utilisez discoverySelectors pour réduire la charge de calcul sur le plan de contrôle en limitant le nombre de ressources Kubernetes (telles que les services, les pods et les points de terminaison) surveillées et traitées.

Lorsque vous utilisez l'implémentation du plan de contrôle TRAFFIC_DIRECTOR, Cloud Service Mesh ne crée que des ressources Google Cloud , telles que les services backend et les groupes de points de terminaison réseau, pour les ressources Kubernetes dans les espaces de noms spécifiés dans discoverySelectors.

Pour en savoir plus, consultez la section Sélecteurs de découverte dans la documentation d'Istio.

Intégrer la résilience

Vous pouvez ajuster les paramètres suivants pour renforcer la résilience de votre service mesh:

Détection des anomalies

La détection des anomalies surveille les hôtes d'un service en amont et les supprime du pool d'équilibrage de charge lorsqu'ils atteignent un seuil d'erreur.

  • Configuration des clés:
    • outlierDetection: paramètres contrôlant l'éviction des hôtes défaillants du pool d'équilibrage de charge.
  • Avantages:maintient un ensemble d'hôtes opérationnels dans le pool d'équilibrage de charge.

Pour en savoir plus, consultez la section Détection d'anomalies dans la documentation d'Istio.

Tentatives

Atténuez les erreurs temporaires en renouvelant automatiquement les requêtes ayant échoué.

  • Configuration des clés:
    • attempts: nombre de nouvelles tentatives à effectuer.
    • perTryTimeout: délai avant nouvelle tentative. Définissez-le sur une valeur inférieure à votre délai avant expiration global. Il détermine la durée d'attente pour chaque tentative de nouvelle tentative.
    • retryBudget: nombre maximal de tentatives simultanées.
  • Avantages:taux de réussite plus élevé pour les requêtes, impact réduit des échecs intermittents.

Facteurs à prendre en compte :

  • Idempotence:assurez-vous que l'opération réessayée est idempotente, ce qui signifie qu'elle peut être répétée sans effets secondaires involontaires.
  • Max. tentatives:limite le nombre de nouvelles tentatives (par exemple, trois tentatives au maximum) pour éviter les boucles infinies.
  • Disjoncteur:intègrez des tentatives avec des disjoncteurs pour éviter les tentatives lorsque le service échoue de manière cohérente.

Pour en savoir plus, consultez la section Répétitions dans la documentation d'Istio.

Délais avant expiration

Utilisez des délais avant expiration pour définir la durée maximale autorisée pour le traitement des requêtes.

  • Configuration des clés:
    • timeout: délai avant expiration des requêtes pour un service spécifique.
    • idleTimeout: durée pendant laquelle une connexion peut rester inactive avant d'être fermée.
  • Avantages:meilleure réactivité du système, prévention des fuites de ressources, renforcement contre le trafic malveillant.

Facteurs à prendre en compte :

  • Latence réseau:tient compte du délai aller-retour (DAR) attendu entre les services. Laissez un peu de marge pour les retards inattendus.
  • Graphique des dépendances de service:pour les requêtes en chaîne, assurez-vous que le délai avant expiration d'un service appelant est plus court que le délai avant expiration cumulé de ses dépendances afin d'éviter les défaillances en cascade.
  • Types d'opérations:les tâches de longue durée peuvent nécessiter des délais avant expiration beaucoup plus longs que les récupérations de données.
  • Gestion des erreurs:les délais avant expiration doivent déclencher la logique de gestion des erreurs appropriée (par exemple, nouvelle tentative, solution de remplacement, interruption du circuit).

Pour en savoir plus, consultez la section Timeouts (Délais avant expiration) dans la documentation d'Istio.

Surveiller et ajuster

Commencez par les paramètres par défaut pour les délais avant expiration, la détection des anomalies et les nouvelles tentatives, puis ajustez-les progressivement en fonction de vos exigences de service spécifiques et des tendances de trafic observées. Par exemple, examinez les données réelles sur le temps de réponse moyen de vos services. Ajustez ensuite les délais avant expiration en fonction des caractéristiques spécifiques de chaque service ou point de terminaison.

Télémétrie

Utilisez la télémétrie pour surveiller en permanence votre réseau de services et ajuster sa configuration afin d'optimiser les performances et la fiabilité.

  • Métriques:utilisez des métriques complètes, en particulier les volumes de requêtes, la latence et les taux d'erreur. Intégrez Cloud Monitoring pour la visualisation et l'envoi d'alertes.
  • Traçage distribué:activez l'intégration du traçage distribué avec Cloud Trace pour obtenir des insights détaillés sur les flux de requêtes dans vos services.
  • Journalisation:configurez la journalisation des accès pour capturer des informations détaillées sur les requêtes et les réponses.

Autres ressources à lire