Les probes Kubernetes sont le mécanisme qui permet au cluster de savoir si un pod est vivant, prêt à recevoir du trafic, ou en train de démarrer. Mal configurées, elles causent des redémarrages intempestifs ou du trafic envoyé vers des pods non prêts.
Les trois probes et leurs rôles
Liveness probe — le pod est-il vivant ? Si elle échoue, Kubernetes redémarre le conteneur.
Readiness probe — le pod est-il prêt à recevoir du trafic ? Si elle échoue, le pod est retiré du Service sans être redémarré.
Startup probe — l’application a-t-elle terminé son démarrage ? Utile pour les applications lentes à démarrer.
spec:
containers:
- name: api
image: myapp:1.0
startupProbe: # Attend que l'app démarre (max 5min)
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10
livenessProbe: # Redémarre si l'app est bloquée
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 0
periodSeconds: 15
failureThreshold: 3
readinessProbe: # Retire du Service si pas prêt
httpGet:
path: /ready
port: 8080
periodSeconds: 5
failureThreshold: 2Erreurs classiques à éviter
Utiliser la même route pour liveness et readiness — la liveness doit retourner 200 dès que le process tourne. La readiness doit vérifier que les dépendances (DB, cache) sont accessibles.
# ✅ Deux endpoints distincts
@app.get("/healthz") # liveness — retourne toujours 200 si le process tourne
async def liveness():
return {"status": "alive"}
@app.get("/ready") # readiness — vérifie les dépendances
async def readiness():
await db.ping()
await redis.ping()
return {"status": "ready"}Liveness trop agressive — une liveness avec failureThreshold: 1 et periodSeconds: 5 redémarre le pod à la moindre lenteur passagère. Préférez failureThreshold: 3 et periodSeconds: 15.
Notre formation Kubernetes couvre la configuration des probes avec des scénarios de panne réels.