Optimisation des sondes Kubernetes : exemples pratiques et étapes sécurisées

Intro

Le réglage des sondes transforme une instabilité floue en un comportement prévisible. Ce guide montre comment observer la latence des sondes, identifier les goulots d’étranglement, apporter le plus petit changement justifié et le vérifier en sécurité. Il se concentre sur readinessProbe, livenessProbe et startupProbe pour les développeurs, SRE et équipes DevOps qui veulent des déploiements fiables sans pods qui basculent ni boucles de redémarrage.

Principes à appliquer :

Observer avant de changer : consigner les versions, la topologie et le comportement actuel des sondes.
Limiter le rayon d’impact : tester d’abord sur un seul pod ou un déploiement canari.
Protéger les secrets : utiliser des valeurs fictives et des commandes en lecture seule jusqu’à être prêt à modifier.
Vérifier et documenter : définir les résultats attendus et les signaux d’échec, et prévoir un retour arrière clair.

Les exemples utilisent kubectl et du YAML standard de Deployment. Adaptez selon votre environnement.

Inventaire des versions et de l’environnement

Objectif : identifier ce que vous avez, comment cela se comporte maintenant, et à quoi ressemble un succès.

Composant : sondes Kubernetes pour Pods et Deployments (Kubernetes 1.20+ recommandé afin de disposer de startupProbe).
Topologie : noter si les cibles sont derrière un Service, utilisent des sidecars, ou dépendent de systèmes externes (DB, cache, API tierce).
Observation en lecture seule : capturer les versions, les spécifications actuelles des sondes et les événements liés aux sondes.

Étapes suggérées :

Identifier les versions du cluster et des nœuds

kubectl version --short
kubectl get nodes -o wide

Recenser les workloads et les réglages actuels des sondes

kubectl get deploy -n NAMESPACE
kubectl get deploy DEPLOYMENT_NAME -n NAMESPACE -o yaml | sed -n '/readinessProbe:/,/^[^ ]/p'
kubectl get deploy DEPLOYMENT_NAME -n NAMESPACE -o yaml | sed -n '/livenessProbe:/,/^[^ ]/p'
kubectl get deploy DEPLOYMENT_NAME -n NAMESPACE -o yaml | sed -n '/startupProbe:/,/^[^ ]/p'

Capturer le comportement live et les horodatages

POD=$(kubectl get pods -n NAMESPACE -l app=APP_LABEL -o jsonpath='{.items[0].metadata.name}')
kubectl describe pod $POD -n NAMESPACE | sed -n '/Events:/,$p'
kubectl get pod $POD -n NAMESPACE -o json | jq '.status.conditions[] | select(.type=="Ready")'

Définir le succès et l’échec avant tout changement :

Attendu : le pod passe à Ready en moins de STARTUP_SLO secondes et reste Ready sans basculer sur une fenêtre de 15 à 30 minutes.
Signal d’échec : événements répétés « Readiness probe failed » ou « Liveness probe failed », hausse des redémarrages du conteneur, ou latence des sondes dépassant systématiquement TIMEOUT.

Chemin de configuration sécurisé

Ajuster un champ à la fois et vérifier l’impact. Réglages courants et effets :

initialDelaySeconds : délai avant la première sonde. Couvre les démarrages à froid prévisibles.
periodSeconds : fréquence des sondes. Plus élevé = moins de charge ; plus bas = détection plus rapide.
timeoutSeconds : durée d’attente d’une réponse avant de compter un échec.
failureThreshold : échecs consécutifs avant de marquer Unready (readiness) ou de redémarrer (liveness).
successThreshold (readiness seulement) : succès consécutifs requis pour passer à Ready.
startupProbe : bloque les autres sondes jusqu’à ce que l’app soit initialisée. Évite les redémarrages liveness pendant le boot.

Chronométrie approximative (cas typique où timeoutSeconds <= periodSeconds) :

Temps jusqu’au premier succès readiness : initialDelaySeconds + successThreshold × periodSeconds (si chaque vérification réussit).
Temps pour marquer Unready en cas d’échec : failureThreshold × periodSeconds.
Temps jusqu’au premier redémarrage liveness en cas d’échec : initialDelaySeconds + failureThreshold × periodSeconds.

Commencer par des changements prudents à faible risque :

Ajouter startupProbe avant de toucher à livenessProbe.
Augmenter timeoutSeconds avec mesure (p. ex. +1 à +2 secondes).
Assouplir failureThreshold de 1 à 2 pour absorber le jitter mineur.
Réduire la fréquence des sondes seulement si la charge des sondes est le goulot suspecté.

Appliquer les changements d’abord sur un canari (1 réplique) :

# Mettre à l’échelle un canari séparé ou cibler un seul pod via une modification temporaire du Deployment
kubectl -n NAMESPACE scale deploy DEPLOYMENT_NAME --replicas=1

Exemples pratiques

Exemple 1 : microservice HTTP avec démarrages à froid en rafales

Symptômes : lors des déploiements, les pods redémarrent à cause d’échecs liveness. Readiness bascule aussi pendant les pics.

Avant (simplifié) :

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  timeoutSeconds: 1
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  timeoutSeconds: 1
  failureThreshold: 3
  successThreshold: 1

Après : ajouter startupProbe et augmenter les timeouts pour couvrir la latence p99 ; ajouter une petite tolérance au jitter.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 12   # jusqu’à ~60s pour le démarrage à froid
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3
  successThreshold: 1

Vérification :

Attendre zéro redémarrage liveness pendant le boot ; pod Ready en ~30 à 60 s.
Surveiller les événements pendant 15 minutes ; aucun basculement readiness.

kubectl rollout restart deploy DEPLOYMENT_NAME -n NAMESPACE
kubectl rollout status deploy DEPLOYMENT_NAME -n NAMESPACE --timeout=5m
kubectl get pods -n NAMESPACE -w

Retour arrière : réappliquer le YAML de Deployment précédent si le temps de mise à Ready ou le budget d’erreurs se dégrade.

Exemple 2 : service gRPC ou basé sur TCP

Si votre service est gRPC ou uniquement TCP, utilisez tcpSocket (ou une sonde gRPC si disponible dans votre version de cluster) pour éviter de lancer des processus shell.

readinessProbe:
  tcpSocket:
    port: 9090
  periodSeconds: 5
  timeoutSeconds: 1
  failureThreshold: 3
livenessProbe:
  tcpSocket:
    port: 9090
  periodSeconds: 10
  timeoutSeconds: 1
  failureThreshold: 3

Conseils :

Garder la liveness TCP plus simple que readiness. Readiness peut inclure des vérifications de dépendances ; liveness doit seulement confirmer que le processus répond, pas que la base de données est disponible.
Si vous ajoutez une RPC de santé gRPC côté application, rattachez-la à readiness ; laissez liveness rester superficielle.

Exemple 3 : application dépendant d’une base de données lente

Problème : l’endpoint readiness renvoie 503 pendant que la base réchauffe ses caches, ce qui maintient le pod Unready plus longtemps que nécessaire. Pire, liveness interroge aussi la DB et redémarre le pod lors d’une panne amont.

Correctif : séparer liveness (soi-même) de readiness (dépendances). Protéger avec startupProbe.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 24  # autoriser une initialisation plus longue
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 15
  timeoutSeconds: 2
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /ready?check=db,cache
    port: 8080
  periodSeconds: 5
  timeoutSeconds: 3
  failureThreshold: 6      # tolérer les hoquets transitoires de la DB
  successThreshold: 2      # exiger deux succès pour passer à Ready

Comportement attendu : démarrages fiables, passage à Ready seulement après stabilité des dépendances, et aucun redémarrage juste parce que la base est lente.

Vérification et diagnostics

Après tout changement, vérifier l’état stable et les conditions limites.

Confirmer les spécifications des sondes sur le pod en cours

POD=$(kubectl get pods -n NAMESPACE -l app=APP_LABEL -o jsonpath='{.items[0].metadata.name}')
kubectl get pod $POD -n NAMESPACE -o yaml | sed -n '/Probe:/,/^[^ ]/p'

Surveiller readiness et les redémarrages

kubectl get pods -n NAMESPACE -w
kubectl describe pod $POD -n NAMESPACE | sed -n '/Events:/,$p'
kubectl get pod $POD -n NAMESPACE -o jsonpath='{.status.containerStatuses[0].restartCount}'

Mesurer la latence des sondes depuis les logs applicatifs (recommandé)

Journaliser la durée de vos handlers /ready et /healthz.
Alerter si p95 ou p99 s’approche de timeoutSeconds.

Estimer les fenêtres de détection et comparer à vos SLO (Service-Level Objective) : objectifs de niveau de service mesurables

Passage de Ready à Unready : environ failureThreshold × periodSeconds.
Premier redémarrage liveness : initialDelaySeconds + failureThreshold × periodSeconds.
Passage à Ready : successThreshold × periodSeconds (en supposant des succès consécutifs).

Si un problème au niveau du nœud est suspecté

Rechercher des événements de pression CPU ou IO dans les événements du pod.
Réduire légèrement la fréquence des sondes et vérifier si les timeouts disparaissent.

Procédure de retour arrière :

Conserver le manifest de Deployment précédent à portée de main.
Utiliser kubectl rollout undo si vous déployez en rolling update :

kubectl rollout undo deploy DEPLOYMENT_NAME -n NAMESPACE

Modes de défaillance et remédiation

Basculement readiness (« flapping »)
Symptôme : les pods oscillent entre Ready et Unready, entraînant des pertes de trafic.
Cause : timeoutSeconds trop faible, failureThreshold trop strict, ou vérification de dépendance incluse dans readiness pendant une instabilité transitoire.
Correctif : augmenter timeoutSeconds de 1 à 2 s ; relever failureThreshold ; envisager successThreshold=2 ; garder les vérifications lourdes de dépendances dans readiness, pas dans liveness.

Boucles de redémarrage au déploiement
Symptôme : liveness redémarre à répétition pendant le démarrage.
Cause : startupProbe manquante ou trop courte ; liveness inclut des vérifications de dépendances.
Correctif : ajouter startupProbe ; rendre liveness superficielle ; désactiver temporairement liveness pour confirmer le diagnostic, puis réactiver avec des valeurs ajustées.

Les sondes surchargent l’application
Symptôme : CPU élevé sur les endpoints de santé ou checks exec coûteux.
Cause : sondes exec lançant des shells ; handlers de santé effectuant des requêtes DB lourdes.
Correctif : passer à httpGet ou tcpSocket ; rendre les handlers de santé en temps constant et légers en dépendances ; augmenter periodSeconds.

Gigue réseau dans des clusters partagés
Symptôme : timeouts sporadiques malgré une application saine.
Cause : pression sur le nœud ou voisins bruyants.
Correctif : ajouter un léger tampon dans timeoutSeconds ; relever failureThreshold ; envisager des ressources Pod (requests/limits) pour éviter le throttling.

Pour toute régression sévère, réduire l’échelle du canari ou annuler le déploiement avant d’appliquer un autre changement.

Liste de contrôle opérationnelle

Inventaire
Enregistrer la version de kubectl et les versions des nœuds.
Exporter les sections de sondes des Deployments et les événements de pod avec horodatage.
Baseline
Noter la latence p95/p99 des handlers de santé et les éventuels compteurs de redémarrage.
Définir le temps de passage à Ready attendu et la politique de redémarrage acceptable.
Plan
Choisir un seul changement (startupProbe, timeoutSeconds, failureThreshold, periodSeconds, successThreshold).
Estimer les fenêtres de détection après changement.
Exécution (canari)
Appliquer le changement à 1 réplique ou un Deployment canari.
Surveiller événements, état Ready et redémarrages pendant 15 à 30 minutes.
Vérification
Comparer les résultats observés aux attentes ; vérifier l’absence de basculement.
Confirmer l’impact au niveau service (taux d’erreur, latence) neutre ou amélioré.
Poursuivre ou revenir en arrière
Si amélioration, déployer progressivement.
Si dégradation, revenir immédiatement en arrière et réévaluer.

Conclusion

Une optimisation efficace des sondes est observable, incrémentale et réversible. Séparer l’observation de l’intervention : capturer le comportement actuel, ajuster un seul paramètre avec un rayon d’impact maîtrisé et vérifier selon des signaux clairs de succès et d’échec. Utiliser startupProbe pour protéger liveness au démarrage, garder liveness superficielle, laisser readiness refléter les dépendances, et dimensionner timeouts et seuils selon les distributions réelles de latence. Avec cette démarche, vous réduisez le basculement, évitez les tempêtes de redémarrages et rendez les contrôles de santé à la fois rapides et sûrs.