Probes Kubernetes : liveness, readiness, startup sans faux positifs

Une probe mal configurée peut provoquer plus d’indisponibilité que l’absence de probe. Ce guide vous apprend à choisir la bonne probe, à dimensionner ses paramètres, et à éviter les pièges qui transforment un healthcheck en source de pannes.

Ce que vous allez apprendre

• La différence réelle entre liveness, readiness et startup
• Quand utiliser (et quand éviter) chaque type de probe
• Comment dimensionner les paramètres sans faux positifs
• Les anti-patterns qui causent des redémarrages en boucle
• Comment diagnostiquer une probe qui échoue

Ce que sont les probes Kubernetes

Les probes (sondes) permettent à Kubernetes de surveiller l’état de vos conteneurs et d’agir en conséquence. Par défaut, Kubernetes considère qu’un conteneur est “en marche” tant que son processus principal tourne, même si l’application est bloquée ou incapable de traiter des requêtes.

Les probes comblent ce manque de signal applicatif en donnant au kubelet des indicateurs concrets sur l’état réel de l’application.

Probes = conteneurs

Les probes sont configurées sur les conteneurs, pas sur les Pods. Les effets (redémarrage, retrait du trafic) remontent ensuite au niveau du Pod et du routage par Service.

Les trois types de probes

Kubernetes propose trois types de probes, chacune avec un objectif distinct :

Probe	Question posée	Action si échec
startupProbe	”Le conteneur a-t-il fini de démarrer ?”	Redémarrage du conteneur
livenessProbe	”Le conteneur est-il bloqué et irrécupérable ?”	Redémarrage du conteneur
readinessProbe	”Le conteneur peut-il recevoir du trafic maintenant ?”	Retrait des endpoints du Service

Glissez pour voir

Startup Probe : gérer les démarrages lents

La startupProbe est conçue pour les applications qui ont besoin d’un temps de démarrage important. Tant qu’elle n’a pas réussi, Kubernetes n’exécute pas les autres probes.

Cas d’usage :

• Application Java chargeant de nombreuses dépendances
• Base de données qui charge des données volumineuses en mémoire
• Application legacy avec initialisation complexe

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 30  # 30 × 5s = 150s max pour démarrer

Liveness Probe : détecter un conteneur bloqué

La livenessProbe vérifie si le conteneur est irrémédiablement bloqué et doit être redémarré. Elle répond à la question : “faut-il tuer ce conteneur ?”

Cas d’usage :

• Deadlock applicatif
• Boucle infinie
• Thread principal suspendu

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20
  timeoutSeconds: 5
  failureThreshold: 3

Attention

Une livenessProbe trop agressive peut provoquer des redémarrages en boucle (CrashLoopBackOff). Elle doit être plus tolérante que la readinessProbe.

Readiness Probe : contrôler le trafic

La readinessProbe indique si le conteneur peut traiter des requêtes maintenant. Tant qu’elle échoue, le Pod est retiré des endpoints des Services et ne reçoit plus de trafic.

Cas d’usage :

• API qui doit établir une connexion à une base de données
• Application qui charge des fichiers de configuration
• Service qui attend une dépendance externe

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 3

Ordre d’exécution des probes

L’ordre d’exécution n’est pas linéaire. Voici comment Kubernetes les orchestre :

1. Au démarrage du conteneur

   Si une startupProbe est définie, elle prend le contrôle. Les autres probes sont désactivées jusqu’à sa réussite.

2. Après réussite de la startup probe

   La livenessProbe et la readinessProbe s’exécutent en parallèle, chacune selon sa propre logique et ses propres paramètres.

3. En fonctionnement normal

   • La readinessProbe contrôle l’inclusion dans les endpoints
   • La livenessProbe surveille les blocages irréversibles

Indépendance

La readinessProbe n’attend pas le succès de la livenessProbe pour fonctionner. Ce sont deux mécanismes indépendants avec des objectifs différents.

Quand éviter une liveness probe

Une liveness probe n’est pas toujours nécessaire. Kubernetes rappelle que si votre application sait déjà crasher proprement en cas d’erreur, le kubelet appliquera la politique de redémarrage (restartPolicy) sans avoir besoin d’une liveness probe.

Situations où la liveness est inutile ou dangereuse

Situation	Pourquoi éviter la liveness
L’application crashe d’elle-même en cas de panne	Le restartPolicy suffit
Le check est coûteux ou instable	Risque de faux positifs
Le check dépend d’un service externe	Un problème externe provoquera des redémarrages
L’application est stateful et sensible aux redémarrages	Perte de données ou d’état

Glissez pour voir

Règle de base

La liveness probe doit tester l’état interne du conteneur, pas ses dépendances externes. Pour les dépendances, utilisez une readinessProbe.

Différencier liveness et readiness

C’est l’erreur la plus fréquente : utiliser le même endpoint pour les deux probes sans réflexion.

Ce que chaque probe doit vérifier

Probe	Question	Ce qu’elle doit tester
readinessProbe	”Puis-je traiter une requête maintenant ?”	État fonctionnel complet (base de données connectée, cache chargé, dépendances OK)
livenessProbe	”Suis-je irrémédiablement bloqué ?”	État interne minimal (processus vivant, pas de deadlock)

Glissez pour voir

Exemple concret

# Readiness : vérifie que l'API peut vraiment répondre
readinessProbe:
  httpGet:
    path: /ready  # Teste la connexion DB, le cache, etc.
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

# Liveness : vérifie seulement que le processus n'est pas bloqué
livenessProbe:
  httpGet:
    path: /healthz  # Check léger, local, rapide
    port: 8080
  periodSeconds: 20
  failureThreshold: 5  # Plus tolérant que readiness

Anti-pattern

Ne testez jamais une dépendance externe (base de données, API tierce) dans une livenessProbe. Si cette dépendance devient indisponible, tous vos Pods redémarreront en boucle.

Méthodes de vérification

Kubernetes propose quatre méthodes pour vérifier l’état d’un conteneur :

HTTPGet

Effectue une requête HTTP sur un chemin spécifié. Réussit si le code de réponse est entre 200 et 399.

livenessProbe:
  httpGet:
    path: /healthz
    port: http  # Utilise un port nommé
  periodSeconds: 10

Cas d’usage : Applications web, API REST.

TCPSocket

Tente d’établir une connexion TCP sur le port spécifié. Réussit si le port est ouvert.

readinessProbe:
  tcpSocket:
    port: 3306
  periodSeconds: 10

Cas d’usage : Bases de données, services TCP (MySQL, Redis, PostgreSQL).

Exec (Commande)

Exécute une commande dans le conteneur. Réussit si le code de retour est 0.

startupProbe:
  exec:
    command:
    - cat
    - /app/ready
  periodSeconds: 5

Cas d’usage : Vérifications personnalisées, présence d’un fichier.

Coût d'une probe exec

Une commande exec est plus coûteuse qu’un check HTTP en termes de CPU et mémoire. Évitez les scripts complexes ou les appels à des outils lourds.

gRPC

Teste directement un service gRPC via le protocole standard de health checking. Disponible nativement depuis Kubernetes v1.23.

readinessProbe:
  grpc:
    port: 50051
    service: myapp.v1.Health
  periodSeconds: 10

Cas d’usage : Services exposant une interface gRPC.

Prérequis gRPC

Les probes gRPC nécessitent que votre service implémente le protocole standard de health checking gRPC. Elles ne remplacent pas automatiquement un endpoint HTTP si ce protocole n’est pas implémenté.

Headers HTTP personnalisés

Pour les probes HTTP, vous pouvez ajouter des en-têtes personnalisés :

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
    httpHeaders:
    - name: X-Probe-Type
      value: readiness

Cas d’usage :

• Distinguer les types de checks côté application
• Satisfaire un reverse proxy interne
• Ajouter des métadonnées pour l’observabilité

Ne pas utiliser pour l'authentification

N’utilisez pas les headers HTTP pour transporter des secrets (clés API, tokens). Préférez un endpoint de santé interne, simple et non authentifié.

Récapitulatif des méthodes

Méthode	Protocole	Cas d’usage	Coût
HTTPGet	HTTP(S)	Applications web, API	Faible
TCPSocket	TCP	Bases de données, services TCP	Très faible
Exec	Commande	Vérifications personnalisées	Élevé
gRPC	gRPC	Services gRPC	Faible

Glissez pour voir

Paramètres de configuration

Tous les paramètres disponibles

Paramètre	Défaut	Description
initialDelaySeconds	0	Délai avant la première exécution
periodSeconds	10	Intervalle entre chaque check
timeoutSeconds	1	Durée maximale d’un check
failureThreshold	3	Nombre d’échecs avant action
successThreshold	1	Nombre de succès pour revenir OK (readiness uniquement)
terminationGracePeriodSeconds	—	Délai de grâce spécifique à la probe

Glissez pour voir

Utiliser des ports nommés

Pour une meilleure lisibilité, référencez les ports par leur nom :

spec:
  containers:
  - name: app
    image: myapp:1.0
    ports:
    - name: http
      containerPort: 8080
    - name: metrics
      containerPort: 9090
    livenessProbe:
      httpGet:
        path: /healthz
        port: http  # Référence le port nommé
    readinessProbe:
      httpGet:
        path: /ready
        port: http

Dimensionner ses probes

Méthodologie

1. Mesurer le temps de démarrage réel

   Lancez votre application et mesurez le temps jusqu’à ce qu’elle soit prête. Ajoutez une marge de 20-30%.

2. Définir la startup probe

   failureThreshold × periodSeconds doit être supérieur au temps de démarrage maximal.

3. Configurer la readiness probe

   Plus réactive que la liveness. periodSeconds court (5-10s), failureThreshold modéré (3).

4. Configurer la liveness probe

   Plus tolérante que la readiness. periodSeconds plus long (15-30s), failureThreshold plus élevé (5+).

Tableau de dimensionnement

Situation	Probe recommandée	Configuration suggérée
Démarrage en 45s	startupProbe	periodSeconds: 5, failureThreshold: 12
API rapide, dépendante d’une DB	readinessProbe	periodSeconds: 10, failureThreshold: 3
Process susceptible de deadlock	livenessProbe	periodSeconds: 20, failureThreshold: 5
Service sensible aux pics de charge	Toutes	timeoutSeconds: 5, failureThreshold: 5

Glissez pour voir

Exemple complet

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: myapi:1.0
        ports:
        - name: http
          containerPort: 8080
        # Startup : pour les démarrages lents
        startupProbe:
          httpGet:
            path: /healthz
            port: http
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 30  # 150s max pour démarrer
        # Liveness : détection des blocages
        livenessProbe:
          httpGet:
            path: /healthz
            port: http
          periodSeconds: 20
          timeoutSeconds: 5
          failureThreshold: 5
        # Readiness : contrôle du trafic
        readinessProbe:
          httpGet:
            path: /ready
            port: http
          periodSeconds: 10
          timeoutSeconds: 3
          failureThreshold: 3
          successThreshold: 1

Anti-patterns à éviter

Les erreurs qui provoquent des pannes

Anti-pattern	Conséquence	Solution
Liveness qui teste une DB externe	Cascade de redémarrages si la DB est lente	Tester uniquement l’état interne
periodSeconds trop court	Charge CPU, faux positifs	Minimum 10s pour liveness
timeoutSeconds de 1s par défaut	Faux positifs sous charge	Augmenter à 3-5s
Probe exec avec script lourd	Consommation excessive de ressources	Préférer HTTPGet
Même endpoint pour liveness et readiness	Pas de distinction entre “bloqué” et “pas prêt”	Endpoints différents
Oublier startupProbe sur une appli lente	Redémarrages pendant le démarrage	Ajouter une startup probe
Headers HTTP avec secrets	Exposition de credentials	Endpoint non authentifié

Glissez pour voir

La règle d’or

Une probe ne doit pas devenir elle-même la cause de l’instabilité qu’elle cherche à détecter.

Lien avec les Services

Quand une readinessProbe échoue, Kubernetes retire le Pod des endpoints du Service. Le Pod existe toujours, mais ne reçoit plus de trafic.

Observer les endpoints

# Voir les endpoints d'un Service
kubectl get endpoints mon-service

# Résultat quand un Pod n'est pas ready
NAME          ENDPOINTS                           AGE
mon-service   10.244.0.5:8080,10.244.0.6:8080    1h
# Le Pod avec IP 10.244.0.7 n'apparaît plus car il n'est pas Ready

Observer la condition Ready

kubectl get pods -o wide

NAME      READY   STATUS    RESTARTS   AGE   IP
api-1     1/1     Running   0          1h    10.244.0.5
api-2     1/1     Running   0          1h    10.244.0.6
api-3     0/1     Running   0          1h    10.244.0.7  # Pas ready

La colonne READY montre 0/1 quand la readiness probe échoue.

Diagnostiquer une probe qui échoue

Étapes de diagnostic

1. Vérifier l’état du Pod

   kubectl get pod mon-pod -o wide
   kubectl describe pod mon-pod

   Cherchez les événements Unhealthy avec le type de probe concerné.

2. Lire les logs du conteneur

   kubectl logs mon-pod
   kubectl logs mon-pod --previous  # Si le conteneur a redémarré

3. Tester la probe manuellement

   kubectl exec mon-pod -- curl -v http://localhost:8080/healthz
   kubectl exec mon-pod -- cat /app/ready

4. Vérifier les événements du cluster

   kubectl get events --sort-by=.lastTimestamp | grep mon-pod

Messages d’erreur courants

Message	Cause probable	Solution
Liveness probe failed: connection refused	Application pas encore démarrée	Ajouter startupProbe ou augmenter initialDelaySeconds
Readiness probe failed: HTTP 503	Dépendance non disponible	Vérifier les connexions externes
Liveness probe failed: context deadline exceeded	Timeout trop court	Augmenter timeoutSeconds
Back-off restarting failed container	Probe en échec répété	Vérifier les logs avec --previous

Glissez pour voir

Exemple de sortie describe

kubectl describe pod api-broken

Events:
  Type     Reason     Age   Message
  ----     ------     ----  -------
  Warning  Unhealthy  30s   Liveness probe failed: HTTP probe failed with statuscode: 503
  Warning  Unhealthy  20s   Liveness probe failed: HTTP probe failed with statuscode: 503
  Warning  Unhealthy  10s   Liveness probe failed: HTTP probe failed with statuscode: 503
  Normal   Killing    10s   Container api failed liveness probe, will be restarted

Contrôle de connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

1. startupProbe désactive les autres probes jusqu’à sa réussite
2. livenessProbe teste l’état interne, jamais les dépendances externes
3. readinessProbe contrôle l’inclusion dans les endpoints du Service
4. Une liveness trop agressive provoque des CrashLoopBackOff
5. timeoutSeconds à 1s par défaut est souvent trop court
6. Utilisez des endpoints différents pour liveness et readiness
7. Les probes sont configurées sur les conteneurs, pas les Pods
8. Sans startup probe, une appli lente redémarre pendant son init
9. Les probes exec sont plus coûteuses que HTTPGet
10. kubectl describe pod montre les événements Unhealthy

Prochaines étapes

Pods Kubernetes Comprendre le cycle de vie et les phases des Pods

Deployments Gérer les réplicas et les mises à jour progressives

Services Exposer vos applications et comprendre les endpoints

Requests et Limits Dimensionner les ressources CPU et mémoire

×

📖 Voir la documentation →