Passer au contenu principal

Workloads (Kubernetes)

Health checks et probes

Les probes permettent à Kubernetes de connaître l'état réel d'un conteneur. Sans probes, un conteneur est considéré prêt dès qu'il démarre — même si l'application n'a pas fini de s'initialiser, même si elle est en deadlock. Trois types de probes couvrent des besoins distincts.

Trois types de probes

Liveness Probe

Détermine si le conteneur est vivant. En cas d'échec : le conteneur est redémarré (selon restartPolicy). Utilisé pour détecter les deadlocks, les leaks mémoire qui bloquent l'application, les states corrompus.

Readiness Probe

Détermine si le conteneur est prêt à recevoir du trafic. En cas d'échec : le pod est retiré des endpoints du Service (trafic coupé), mais pas redémarré. Utilisé pendant le démarrage et pour les périodes de forte charge temporaire.

Startup Probe

Utilisé uniquement pendant le démarrage initial pour les applications qui mettent longtemps à démarrer. Tant que la startup probe n'a pas réussi, liveness et readiness sont désactivées. Évite les faux redémarrages pendant l'initialisation.

Méthodes de probe

spec:
  containers:
  - name: app
    image: myapp:1.0

    # HTTP GET (le plus courant pour les services web)
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Accept
          value: application/json
      initialDelaySeconds: 10   # Attendre 10s avant la première probe
      periodSeconds: 10         # Vérifier toutes les 10s
      failureThreshold: 3       # 3 échecs = redémarrage
      successThreshold: 1       # 1 succès = vivant
      timeoutSeconds: 5         # Timeout de chaque probe

    # TCP Socket (pour les services non-HTTP)
    readinessProbe:
      tcpSocket:
        port: 5432
      initialDelaySeconds: 5
      periodSeconds: 5

    # Exec command (flexible, mais overhead CPU)
    startupProbe:
      exec:
        command:
        - cat
        - /tmp/ready
      failureThreshold: 30      # 30 * 10s = 5min max pour démarrer
      periodSeconds: 10

    # GRPC (natif depuis v1.24)
    readinessProbe:
      grpc:
        port: 9090
      periodSeconds: 5

Dimensionner les probes

Les paramètres par défaut sont souvent mal adaptés. Règles pratiques :

  • initialDelaySeconds : mesurer le temps de démarrage réel de l'application et ajouter une marge. Une valeur trop courte tue le pod avant qu'il soit prêt.
  • failureThreshold * periodSeconds : la durée avant redémarrage. Un service sous forte charge peut mettre quelques secondes à répondre — ne pas redémarrer trop vite.
  • timeoutSeconds : le timeout de probe doit être inférieur à periodSeconds.

Diagnostiquer les échecs de probe

kubectl describe pod web-xxx
# Chercher dans Events :
# Liveness probe failed: ...
# Readiness probe failed: ...

# Tester la probe manuellement depuis l'intérieur du pod
kubectl exec web-xxx -- curl -s http://localhost:8080/healthz

# Logs autour du redémarrage
kubectl logs web-xxx --previous   # Logs avant le dernier redémarrage

Bonnes pratiques

  • La liveness probe ne doit pas dépendre de services externes (base de données, cache) : si la DB est down, ce n'est pas une raison de tuer le pod
  • La readiness probe peut vérifier les dépendances externes : si la DB est inaccessible, ne pas recevoir de trafic est correct
  • Utiliser la startup probe pour les applications JVM, Node.js avec builds lents, ou tout ce qui prend plus de 30 secondes à démarrer
  • Exposer un endpoint /healthz dédié, léger, qui ne déclenche pas de traitements lourds

Sources