Les probes (sondes) sont des mécanismes intégrés à Kubernetes permettant de surveiller l’état des conteneurs au sein d’un Pod. Elles permettent au kubelet d’évaluer dynamiquement si une application est fonctionnelle, prête à recevoir du trafic ou encore en cours d’initialisation. Trois types de sondes sont disponibles : livenessProbe, readinessProbe et startupProbe, chacune répondant à un besoin opérationnel précis.

Types de gestionnaires de sonde

Pour évaluer la santé d’un conteneur, Kubernetes utilise l’un des trois gestionnaires suivants :

• ExecAction : exécute une commande dans l’espace utilisateur du conteneur. Le résultat est considéré comme positif si le code de sortie vaut 0.
• TCPSocketAction : tente une connxeion TCP sur une adresse IP et un port spécifiés. Une connexion réussie signifie que le service est accessible.
• HTTPGetAction : envoie une requête HTTP GET vers une URL définie (chemin + port). Une réponse avec un statut HTTP entre 200 et 399 est jugée valide.

Chaque sonde renvoie l’un des trois états suivants :

• Success : la vérification a réussi.
• Failure : la vérification a échoué.
• Unknown : la sonde n’a pas pu être exécutée — aucune action n’est déclenchée.

Rôles distincts des sondes

LivenessProbe

Cette sonde détermine si le processus applicatif est toujours actif. En cas d’échec répété, le kubelet redémarre le conteneur selon sa politique de redémarrage (Always, OnFailure, ou Never). Si non définie, la sonde est implicitement considérée comme toujours réussie.

ReadinessProbe

Elle indique si le conteneur est prêt à servir du trafic. Lorsqu’elle échoue, le contrôleur de endpoints retire automatiquement l’IP du Pod de la liste des endpoints associés aux Services. Cela évite d’acheminer des requêtes vers des instances non opérationnelles. Par défaut, avant le délai initial, le statut est Failure.

StartupProbe

Introduite en version stable depuis Kubernetes 1.20, elle sert à valider le démarrage d’applications longues à initialiser (ex. : chargement de modèles ML, migrations de base de données). Tant qu’elle n’est pas validée, les autres sondes sont suspendues. En cas d’échec, le conteneur est redémarré.

Quand utiliser chaque type ?

• Liveness : à privilégier lorsque l’application peut rester « vivante » sans être fonctionnelle (ex. : thread bloqué, boucle infinie). Elle garantit la résilience via des redémarrgaes ciblés.
• Readiness : indispensable pour orchestrer des déploiements progressifs ou gérer des dépendances externes (bases de données, API tierces). Elle permet de retarder l’entrée en service jusqu’à ce que toutes les conditions soient remplies.
• Startup : recommandée pour les conteneurs dont le temps de démarrage dépasse largement le initialDelaySeconds typique d’une livenessProbe. Elle évite les redémarrages intempestifs pendant l’initialisation.

Mise en œuvre pratique

Exemples de configuration

Vérification par comamnde shell (Exec)

apiVersion: v1
kind: Pod
metadata:
  name: app-health-check
spec:
  containers:
  - name: web-server
    image: nginx:alpine
    livenessProbe:
      exec:
        command: ["/bin/sh", "-c", "test -f /var/run/app.ready"]
      initialDelaySeconds: 25
      periodSeconds: 5
      timeoutSeconds: 3
      failureThreshold: 2

Vérification TCP sur un port

readinessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
  timeoutSeconds: 2

Vérification HTTP avec personnalisation avancée

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
    - name: X-Health-Check
      value: "true"
  initialDelaySeconds: 40
  periodSeconds: 15
  timeoutSeconds: 4
  successThreshold: 1
  failureThreshold: 3

Paramètres clés expliqués

Scénario concret : Application monolithique avec dépendances

Pour une application Java nécessitant une base PostgreSQL, on peut combiner les sondes ainsi :

startupProbe:
  httpGet:
    path: /actuator/info
    port: 8080
  periodSeconds: 10
  failureThreshold: 30 # Permet jusqu'à 5 minutes de démarrage

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  periodSeconds: 20

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  periodSeconds: 10

Ici, /actuator/health/readiness vérifie à la fois la disponibilité de l’application et celle de sa base de données, tandis que liveness se concentre uniquement sur la santé du processus JVM.

Comportements opérationnels clés

• Une livenessProbe en échec déclenche la destruction du conteneur et son remplacement — sans attendre la fin du cycle de vie normal.
• Une readinessProbe en échec retire immédiatement le Pod des pools de load balancing, mais ne le redémarre pas.
• Lors d’une suppression de Pod (ex. : kubectl delete pod), le statut Ready=False est appliqué immédiatement, même sans readinessProbe définie.