Partager via


Application cliente hébergée par Kubernetes

Connexions clientes à partir de plusieurs pods

Lorsque vous avez plusieurs pods se connectant à un serveur Redis, assurez-vous que les nouvelles connexions en provenance des pods sont créées de manière échelonnée. Si plusieurs pods démarrent en peu de temps sans échelonnement, cela provoque un pic soudain du nombre de connexions client créées. Le nombre élevé de connexions entraîne une charge élevée sur le serveur Redis et peut entraîner des délais d’attente.

Évitez le même scénario lors de l’arrêt de plusieurs pods en même temps. Un échec d’échelonnement de l’arrêt peut entraîner une chute abrupte du nombre de connexions conduisant à une sollicitation du processeur.

Ressources de pod suffisantes

Assurez-vous que le pod exécutant votre application cliente dispose de suffisamment de ressources processeur et mémoire. Si l’application cliente est exécutée à un niveau proche de ses limites de ressources, cela peut entraîner des délais d’attente.

Ressources de nœud suffisantes

Un pod exécutant l’application cliente peut être affecté par d’autres pods en cours d’exécution sur le même nœud, et limiter les connexions Redis ou les opérations d’E/S. Par conséquent, assurez-vous toujours que le nœud sur lequel vos pods d’application cliente sont exécutés disposent de mémoire, de processeur et de bande passante réseau en quantité suffisante. Si l’une de ces ressources présente un niveau insuffisant, cela peut entraîner des problèmes de connectivité.

Applications clientes hébergées sur Linux et paramètres TCP

Si votre application cliente Azure Cache pour Redis s’exécute sur un conteneur Linux, nous vous recommandons de mettre à jour certains paramètres TCP. Ces paramètres sont détaillés dans Paramètres TCP pour les applications clientes hébergées sur Linux.

Collision de connexion potentielle avec Istio/Envoy

Actuellement, Azure Cache pour Redis utilise les ports 15xxx pour les caches en cluster afin d'exposer les nœuds de cluster aux applications clientes. Comme indiqué ici, les mêmes ports sont également utilisés par Istio.io proxy sidecar appelé Envoy et pourrait interférer avec la création de connexions, en particulier sur le port 15001 et 15006.

Lors de l’utilisation de Istio avec un cluster Azure Cache pour Redis, envisagez d’exclure les ports de collision potentiels avec une annotation istio.

annotations:
  traffic.sidecar.istio.io/excludeOutboundPorts: "15000,15001,15004,15006,15008,15009,15020"

Pour éviter les interférences de connexion, nous vous recommandons les opérations suivantes :

  • Envisagez d’utiliser un cache non clusterisé ou un cache de niveau Entreprise à la place
  • Évitez de configurer des side-cars Istio sur des pods exécutant Azure Cache pour Redis