Sondes de santé (Probes) : Liveness, Readiness, Startup

Au-delà de l'existence : vérifier la santé réelle des applications

Kubernetes sait comment démarrer et gérer le cycle de vie des conteneurs. Par défaut, il considère un conteneur comme étant "en cours d'exécution" tant que le processus principal du conteneur existe. Cependant, une application peut être en cours d'exécution sans être réellement fonctionnelle : elle peut être bloquée (deadlock), en cours d'initialisation, incapable de se connecter à une dépendance, ou surchargée et incapable de traiter de nouvelles requêtes.

Les sondes de santé (Probes) sont le mécanisme par lequel le Kubelet (l'agent s'exécutant sur chaque noeud worker) peut vérifier activement l'état de santé d'un conteneur allant au-delà de la simple existence de son processus. Elles permettent à Kubernetes de prendre des décisions éclairées sur la gestion du conteneur et du trafic réseau qui lui est destiné. Il existe trois types principaux de sondes : Liveness, Readiness et Startup, chacune avec un objectif distinct pour construire des applications auto-réparatrices et robustes.

Fonctionnement général et configuration des sondes

Chaque type de sonde peut être configuré pour utiliser l'une des méthodes de vérification suivantes :

• exec : Exécute une commande spécifiée à l'intérieur du conteneur. La sonde est considérée comme réussie si la commande se termine avec un code de sortie (exit code) de 0.
• httpGet : Effectue une requête HTTP GET vers une adresse IP, un port et un chemin spécifiés sur le conteneur. La sonde réussit si le code de statut de la réponse est compris entre 200 et 399 (inclus).
• tcpSocket : Tente d'ouvrir une connexion TCP sur un port spécifié du conteneur. La sonde réussit si la connexion est établie.
• grpc (depuis Kubernetes 1.23, en alpha puis beta) : Effectue une vérification de santé gRPC sur un port spécifié. La sonde réussit si l'état retourné par le service est 'SERVING'.

Plusieurs paramètres communs permettent d'affiner le comportement des sondes :

• initialDelaySeconds : Nombre de secondes à attendre après le démarrage du conteneur avant d'effectuer la première vérification. Permet à l'application de s'initialiser.
• periodSeconds : Fréquence (en secondes) à laquelle la sonde est exécutée. La valeur par défaut est 10.
• timeoutSeconds : Nombre de secondes après lesquelles la sonde est considérée comme ayant échoué si aucune réponse n'est reçue. La valeur par défaut est 1.
• failureThreshold : Nombre d'échecs consécutifs nécessaires pour que la sonde soit considérée comme ayant échoué. La valeur par défaut est 3. Pour les Startup Probes, un échec après ce seuil entraîne le redémarrage du conteneur. Pour Liveness et Readiness, l'échec déclenche l'action spécifique à la sonde.
• successThreshold : Nombre de succès consécutifs requis après un échec pour que la sonde soit de nouveau considérée comme réussie. La valeur par défaut est 1.

Sonde Liveness : l'application est-elle vivante ?

La sonde Liveness (vivacité) a pour but de déterminer si un conteneur est toujours fonctionnel ou s'il est entré dans un état irrécupérable (par exemple, un deadlock, une corruption mémoire interne) nécessitant un redémarrage.

Action en cas d'échec : Si la sonde Liveness échoue après avoir atteint le failureThreshold, le Kubelet tue le conteneur. Kubernetes tentera ensuite de le redémarrer, en respectant la politique de redémarrage (restartPolicy) définie pour le Pod (généralement 'Always').

Cas d'usage : Utile pour les applications qui peuvent devenir non responsives sans pour autant planter leur processus principal. Par exemple, une application web bloquée sur une boucle infinie ou une application incapable de progresser à cause d'un état interne corrompu.

Attention : Une sonde Liveness mal configurée (trop sensible, dépendante d'un service externe lent) peut entraîner des boucles de redémarrage inutiles, nuisant à la disponibilité. Elle doit vérifier un état fondamental de l'application elle-même.

# Exemple de sonde Liveness HTTP
apiVersion: v1
kind: Pod
metadata:
  name: mon-app-liveness
spec:
  containers:
  - name: mon-app
    image: mon-image:latest
    livenessProbe:
      httpGet:
        path: /healthz  # Endpoint dédié à la vérification de vivacité
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20
      failureThreshold: 3

Sonde Readiness : l'application est-elle prête à servir ?

La sonde Readiness (disponibilité) a pour but de déterminer si un conteneur est prêt à accepter et traiter du trafic réseau.

Action en cas d'échec : Si la sonde Readiness échoue après avoir atteint le failureThreshold, le contrôleur des Endpoints (ou EndpointSlices) retire l'adresse IP du Pod de la liste des points de terminaison actifs pour tous les Services Kubernetes qui ciblent ce Pod. Concrètement, le Pod ne recevra plus de nouvelles requêtes via le Service. Cependant, le conteneur continue de s'exécuter. Lorsque la sonde réussit à nouveau (après successThreshold succès consécutifs), l'IP du Pod est ré-ajoutée aux Endpoints, et il recommence à recevoir du trafic.

Cas d'usage : Indispensable pour les applications qui nécessitent un temps d'initialisation avant de pouvoir servir (chargement de données, compilation de caches, établissement de connexions à des bases de données), ou qui peuvent devenir temporairement surchargées ou incapables de traiter de nouvelles requêtes tout en restant fonctionnelles. C'est aussi crucial pendant les mises à jour progressives (Rolling Updates) d'un Deployment : Kubernetes attend que la sonde Readiness d'un nouveau Pod réussisse avant de considérer ce Pod comme "disponible" et de continuer le déploiement.

# Exemple de sonde Readiness TCP
apiVersion: v1
kind: Pod
metadata:
  name: mon-app-readiness
spec:
  containers:
  - name: mon-app
    image: mon-image:latest
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      failureThreshold: 3

Sonde Startup : l'application a-t-elle fini de démarrer ?

La sonde Startup (démarrage) a été introduite pour gérer spécifiquement les applications qui ont un temps de démarrage long ou imprévisible. Auparavant, pour ces applications, il fallait configurer des initialDelaySeconds très longs ou des failureThreshold élevés sur les sondes Liveness, ce qui pouvait masquer des problèmes réels une fois l'application démarrée.

Fonctionnement : Si une sonde Startup est définie, toutes les autres sondes (Liveness et Readiness) sont désactivées jusqu'à ce que la sonde Startup réussisse. La sonde Startup est exécutée selon sa propre configuration (periodSeconds, failureThreshold, etc.).

• Si la sonde Startup réussit, le Kubelet arrête de l'exécuter et active les sondes Liveness et Readiness (si elles sont définies).
• Si la sonde Startup échoue après avoir atteint son failureThreshold, le Kubelet tue le conteneur (comme pour une sonde Liveness qui échoue) et le redémarre selon la restartPolicy.

Cas d'usage : Idéale pour les applications legacy ou complexes qui peuvent prendre plusieurs minutes à démarrer. Elle permet de leur laisser suffisamment de temps pour s'initialiser sans être prématurément tuées par une sonde Liveness trop rapide, tout en permettant ensuite d'avoir une sonde Liveness réactive une fois l'application en régime de croisière.

# Exemple de sonde Startup avec Liveness/Readiness
apiVersion: v1
kind: Pod
metadata:
  name: mon-app-startup
spec:
  containers:
  - name: mon-app-lente
    image: mon-image-lente:latest
    ports:
    - containerPort: 8080
    startupProbe:
      httpGet:
        path: /startupz # Endpoint spécifique au démarrage
        port: 8080
      failureThreshold: 30 # Laisse 30*10s = 5 minutes pour démarrer
      periodSeconds: 10
    livenessProbe: # Activée APRES succès de startupProbe
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5 # Délai court car on sait que l'app a démarré
      periodSeconds: 15
    readinessProbe: # Activée APRES succès de startupProbe
      httpGet:
        path: /readyz
        port: 8080
      periodSeconds: 5

Bonnes pratiques pour des sondes efficaces

Pour tirer le meilleur parti des sondes de santé :

• Implémentez des endpoints dédiés : Créez des chemins HTTP spécifiques (/healthz, /readyz, /startupz) ou des commandes légères pour vos sondes. Evitez d'utiliser des endpoints applicatifs lourds.
• Soyez rapide et léger : Les handlers de sondes doivent répondre très rapidement et consommer un minimum de ressources pour ne pas impacter les performances de l'application.
• Vérifiez les dépendances internes : La sonde Readiness peut (et doit souvent) vérifier la disponibilité des dépendances critiques (bases de données, autres services internes) avant de se déclarer prête. La sonde Liveness, en revanche, devrait idéalement se concentrer sur l'état interne du conteneur lui-même.
• Adaptez les seuils : Ajustez finement initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold et successThreshold en fonction du comportement attendu de votre application. Les valeurs par défaut ne sont pas toujours optimales.
• Utilisez Startup Probe si nécessaire : Ne luttez pas avec des délais initiaux énormes sur Liveness ; utilisez une sonde Startup pour les démarrages lents.
• Testez vos sondes : Assurez-vous que vos sondes se comportent comme prévu en simulant différents états de votre application (démarrage, fonctionnement normal, surcharge, échec interne).

En configurant judicieusement les sondes Liveness, Readiness et Startup, vous dotez vos applications déployées sur Kubernetes d'une capacité d'auto-réparation et d'une gestion du trafic intelligente, améliorant considérablement leur résilience et leur disponibilité.