Importance des Liveness & Readiness Probes (assurer la santé applicative)

Le défi : quand un conteneur démarré n'est pas synonyme d'application fonctionnelle

Le simple fait qu'un conteneur soit en état 'Running' dans Kubernetes ne signifie pas nécessairement que l'application qu'il héberge fonctionne correctement. Une application peut rencontrer un blocage interne (deadlock), manquer de ressources, échouer à se connecter à une dépendance cruciale, ou simplement nécessiter un temps de démarrage conséquent avant d'être prête à traiter des requêtes. Sans un moyen pour Kubernetes de connaître l'état interne réel de l'application, il ne peut pas agir intelligemment.

Imaginez un serveur web qui démarre mais dont le processus principal se fige. Pour Kubernetes, le conteneur tourne toujours, mais l'application est incapable de répondre aux requêtes. Ou encore, une application qui doit charger une grande quantité de données en mémoire au démarrage ; si Kubernetes lui envoie du trafic immédiatement, les requêtes échoueront jusqu'à ce que l'initialisation soit terminée.

C'est précisément pour résoudre ces problèmes que Kubernetes introduit les concepts de Liveness Probes (sondes de vivacité) et de Readiness Probes (sondes de préparation). Ces mécanismes, configurés au niveau du conteneur, permettent au Kubelet (l'agent Kubernetes sur chaque noeud) de vérifier périodiquement l'état de santé de l'application elle-même, allant au-delà du simple statut du processus conteneur.

La Liveness Probe : détecter et redémarrer les conteneurs défaillants

La Liveness Probe a pour objectif principal de répondre à la question : "Est-ce que cette application est toujours en vie et fonctionnelle ?". Elle est utilisée par le Kubelet pour déterminer si un conteneur doit être redémarré. Si la Liveness Probe échoue plusieurs fois consécutives (selon la configuration `failureThreshold`), le Kubelet considère que le conteneur est dans un état irrécupérable et le tue. Ensuite, conformément à la politique de redémarrage du Pod (généralement `Always`), le Kubelet tentera de redémarrer le conteneur.

Ce mécanisme est particulièrement utile pour détecter les blocages ou les états où l'application ne répond plus mais où le processus principal est toujours actif. Sans Liveness Probe, un tel conteneur pourrait rester indéfiniment dans un état défaillant. Avec une Liveness Probe bien configurée, Kubernetes peut automatiquement tenter de corriger la situation en redémarrant le conteneur, contribuant ainsi à l'auto-réparation du système.

Il existe trois types de Liveness Probes :

• HTTP GET : Le Kubelet envoie une requête HTTP GET à un chemin spécifique sur une IP/port du conteneur. Si la réponse a un code de statut entre 200 et 399 (inclus), la sonde est considérée comme réussie.
• TCP Socket : Le Kubelet tente d'établir une connexion TCP sur un port spécifique du conteneur. Si la connexion réussit, la sonde est réussie.
• Exec Command : Le Kubelet exécute une commande spécifique à l'intérieur du conteneur. Si la commande se termine avec un code de sortie 0, la sonde est réussie.

Voici un exemple de configuration de Liveness Probe HTTP GET dans un manifeste de Pod/Deployment :

apiVersion: v1
kind: Pod
metadata:
  name: mon-app-pod
spec:
  containers:
  - name: mon-app-container
    image: mon-app:1.0
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /healthz # Chemin de l'endpoint de santé
        port: 8080
      initialDelaySeconds: 15 # Attendre 15s après le démarrage avant la 1ère sonde
      periodSeconds: 20    # Vérifier toutes les 20s
      timeoutSeconds: 5     # Considérer comme échec après 5s sans réponse
      failureThreshold: 3  # Redémarrer après 3 échecs consécutifs

La Readiness Probe : déterminer quand un conteneur est prêt pour le trafic

La Readiness Probe répond à une question différente : "Est-ce que cette application est prête à recevoir et traiter des requêtes utilisateur ?". Contrairement à la Liveness Probe dont l'échec entraîne un redémarrage, l'échec d'une Readiness Probe a une conséquence différente : le Kubelet signale au plan de contrôle Kubernetes (en particulier aux objets Service) que ce Pod n'est pas prêt.

Concrètement, si la Readiness Probe d'un Pod échoue, ce Pod est temporairement retiré de la liste des points de terminaison (endpoints) du ou des Services qui le ciblent. Le trafic ne lui sera plus envoyé tant que la sonde ne réussit pas à nouveau. Dès que la Readiness Probe redevient positive, le Pod est réintégré dans la liste des endpoints et recommence à recevoir du trafic.

Ce mécanisme est essentiel pour gérer les démarrages d'applications qui nécessitent un certain temps d'initialisation (chargement de données, compilation de cache, établissement de connexions...). Il empêche d'envoyer du trafic à un Pod qui n'est pas encore capable de le traiter correctement. Il est également crucial lors des déploiements progressifs (rolling updates) : un nouveau Pod ne recevra du trafic qu'une fois sa Readiness Probe passée au vert.

Les types de Readiness Probes sont les mêmes que pour les Liveness Probes (HTTP GET, TCP Socket, Exec Command) et leur configuration est très similaire :

apiVersion: v1
kind: Pod
metadata:
  name: mon-app-pod
spec:
  containers:
  - name: mon-app-container
    image: mon-app:1.0
    ports:
    - containerPort: 8080
    readinessProbe:
      httpGet:
        path: /ready # Chemin de l'endpoint de préparation
        port: 8080
      initialDelaySeconds: 5  # Attendre 5s avant la 1ère vérification
      periodSeconds: 10   # Vérifier toutes les 10s
      successThreshold: 1 # Considérer comme prêt après 1 succès
      failureThreshold: 3 # Retirer du service après 3 échecs
    livenessProbe: # ... (peut coexister avec la liveness probe)
      # ...

Liveness vs Readiness : comprendre la différence et bien choisir

Il est crucial de bien distinguer les rôles et les conséquences des deux types de sondes. La Liveness Probe est là pour détecter les conteneurs irrécupérables et les redémarrer. La Readiness Probe est là pour savoir quand un conteneur est prêt à recevoir du trafic et pour le retirer temporairement du service s'il ne l'est plus.

Un conteneur peut être "vivant" (Liveness OK) mais pas encore "prêt" (Readiness KO), par exemple pendant sa phase de démarrage. Inversement, un conteneur peut devenir "non prêt" (Readiness KO) parce qu'il est surchargé ou attend une dépendance, sans pour autant être dans un état justifiant un redémarrage (Liveness OK).

Utilisez une Liveness Probe si vous voulez que Kubernetes redémarre automatiquement un conteneur lorsqu'il détecte un état bloqué ou non réactif. Utilisez une Readiness Probe si vous voulez que Kubernetes attende que votre application soit pleinement initialisée avant de lui envoyer du trafic via un Service, ou si votre application peut temporairement devenir indisponible sans nécessiter un redémarrage.

Il est fréquent et souvent recommandé d'utiliser les deux types de sondes conjointement pour une gestion fine de la santé applicative. Cependant, soyez particulièrement prudent avec la configuration de la Liveness Probe pour éviter les boucles de redémarrage inutiles.

Configuration et bonnes pratiques pour des sondes efficaces

La configuration correcte des sondes est essentielle à leur efficacité. Portez une attention particulière aux paramètres suivants : `initialDelaySeconds` (pour laisser le temps à l'application de démarrer avant la première sonde), `periodSeconds` (fréquence des vérifications), `timeoutSeconds` (délai d'attente pour une réponse), `failureThreshold` (nombre d'échecs consécutifs avant action) et `successThreshold` (nombre de succès consécutifs pour considérer le conteneur comme prêt/vivant après un échec).

Choisissez le type de sonde le plus adapté à votre application. Une sonde HTTP est souvent préférable pour les serveurs web car elle peut vérifier un endpoint spécifique qui teste plusieurs aspects de l'application. Une sonde TCP est plus simple mais moins informative. Une sonde Exec est flexible mais peut être plus lourde.

Commencez avec des configurations raisonnables et ajustez les délais et seuils en fonction du comportement observé de votre application. Il vaut mieux des sondes un peu moins agressives au début qu'une Liveness Probe qui redémarre votre application en permanence à cause d'une surcharge temporaire.

En conclusion, les Liveness et Readiness Probes sont des outils fondamentaux dans Kubernetes pour construire des applications fiables et résilientes. Elles permettent à Kubernetes de comprendre l'état réel de vos applications, d'automatiser leur redémarrage en cas de problème critique et de gérer intelligemment le flux de trafic pour garantir une expérience utilisateur fluide, même pendant les phases de démarrage ou de mise à jour.