Configuration des sondes et des contrôles de santé de l'équilibreur de charge

Kubernetes propose plusieurs méthodes pour effectuer des contrôles de santé des applications en plus des contrôles de santé de l'équilibreur de charge. Vous pouvez exécuter les sondes intégrées Kubernetes suivantes avec le contrôle de l'état de l'équilibreur de charge sous forme de commande dans le contexte du pod ou de sonde HTTP/TCP vers Kubelet ou l'adresse IP de l'hôte.

Les sondes de vivacité et de préparation doivent être différentes et indépendantes (ou du moins avoir des valeurs de temporisation différentes). Si une application présente un problème temporaire, la sonde de disponibilité indiquera que le module n'est pas prêt jusqu'à ce que le problème soit résolu. Si les paramètres de la sonde de vie ne sont pas corrects, la sonde de vie peut arrêter le module.

Sonde de démarrage

Utilisez des sondes de démarrage pour protéger les applications dont les cycles d'initialisation sont longs. Jusqu'à ce que la sonde de démarrage réussisse, les autres sondes sont désactivées.

Vous pouvez définir la durée maximale pendant laquelle Kubernetes doit attendre le démarrage de l'application. Si, après la durée maximale configurée, le pod échoue toujours aux sondes de démarrage, l'application est arrêtée et un nouveau pod est créé.

Utilisez des sondes de démarrage lorsque l'heure de démarrage d'une application est imprévisible. Si vous savez que votre application a besoin de 10 secondes pour démarrer, utilisez initialDelaySeconds plutôt une sonde de vivacité ou une sonde de préparation.

Sonde Liveness

Utilisez des sondes Liveness pour détecter les problèmes liés aux applications ou pour déterminer si le processus s'exécute sans problème. Une sonde de réactivité peut détecter les situations de blocage dans lesquelles le processus continue de s'exécuter mais où l'application ne répond plus. Lorsque vous utilisez une sonde de vivacité, procédez comme suit :

• initialDelaySecondsÀ utiliser pour retarder la première sonde.

• Ne définissez pas les mêmes spécifications pour les sondes de vivacité et de disponibilité.

• Ne configurez pas une sonde de vivacité pour qu'elle dépende d'un facteur externe à votre pod (par exemple, une base de données).

• Réglez la sonde de vivacité sur un point spécifiqueterminationGracePeriodSeconds. Pour plus d'informations, consultez la documentation de Kubernetes.

Sonde de préparation

Utilisez une sonde de préparation pour détecter les éléments suivants :

• Si l'application est prête à accepter du trafic

• Disponibilité partielle, lorsque l'application peut être temporairement indisponible mais devrait être rétablie après la fin d'une certaine opération

Les sondes de préparation aident à garantir que la configuration et les dépendances de l'application s'exécutent sans problème ni erreur, afin que l'application puisse gérer le trafic. Cependant, une sonde de disponibilité mal configurée peut provoquer une panne au lieu de l'empêcher. Les sondes de disponibilité qui dépendent de facteurs externes, tels que la connectivité à une base de données, peuvent entraîner l'échec de la sonde sur tous les pods. De telles défaillances peuvent entraîner une panne, et elles peuvent entraîner une défaillance en cascade d'un service principal vers d'autres services utilisant les pods défaillants.

Contrôles de santé des ressources d'entrée et de l'équilibreur de charge

Application Load Balancer et ingress Kubernetes proposent des fonctionnalités de vérification de l'état de santé. Pour les vérifications de l'état de l'Application Load Balancer, spécifiez les ports et le chemin cibles.

Remarque : pour Kubernetesingress, il y aura une latence de désenregistrement. La valeur par défaut pour Application Load Balancer est de 300 secondes. Envisagez de configurer la vérification de l'état de votre ressource d'entrée ou de votre équilibreur de charge en utilisant les mêmes valeurs que celles que vous avez utilisées pour votre sonde de disponibilité. 

NGINX fournit également un bilan de santé. Pour plus d'informations, consultez la documentation NGINX.

Les passerelles d'entrée et de sortie Istio ne disposent pas d'un mécanisme de vérification de l'état comparable au contrôle de santé HTTP de NGINX. Cependant, vous pouvez obtenir des fonctionnalités similaires en utilisant le disjoncteur Istio ou la détection des valeurs DestinationRule aberrantes.

Pour plus d'informations, consultez EKS Best Practices — Load Balancing (disponibilité et cycle de vie des pods).