GUIDE TECHNIQUE · KUBERNETES
Configurer les sondes de santé Kubernetes
Configurer des sondes Kubernetes aux finalités différentes, observer les conditions Ready, puis démontrer en recette l'échec de readiness sans provoquer un redémarrage intempestif.
L’ESSENTIEL EN BREF
Comment procéder ?
Configurer des sondes Kubernetes aux finalités différentes, observer les conditions Ready, puis démontrer en recette l'échec de readiness sans provoquer un redémarrage intempestif.
Résultat à atteindre : Trois sondes aux finalités expliquées.
Avant de commencer : Cluster de test autorisé et contexte kubectl vérifié.
01 · CADRAGE
Ce que vous allez mettre en place
Configurer des sondes Kubernetes aux finalités différentes, observer les conditions Ready, puis démontrer en recette l'échec de readiness sans provoquer un redémarrage intempestif.
Pour qui : Administrateurs Kubernetes, équipes DevOps et SRE
Kubernetes stable avec kubectl compatible ; les images de laboratoire sont illustratives et doivent être validées avant usage réel.
Vérifiez la compatibilité avec votre environnement réel. Les versions ne sont jamais présumées identiques d’un tenant à l’autre.
02 · AVANT DE COMMENCER
Prérequis et points de contrôle
- Cluster de test autorisé et contexte kubectl vérifié.
- Droits de créer/supprimer un namespace de recette ; aucun workload client dans ce namespace.
- Capacité à lire Pods, événements et logs après déploiement.
03 · VUE D’ENSEMBLE
Comprendre l’architecture et les flux
04 · TUTORIEL
Procédure complète, étape par étape
Chaque étape explique l’action, sa raison, le contrôle attendu et les erreurs habituelles. Adaptez les exemples aux paramètres de votre propre environnement.
ÉTAPE 1 / 5
Choisir un endpoint de santé fiable
La readiness contrôle l'entrée dans les endpoints du Service ; liveness peut redémarrer un conteneur ; startupProbe retarde les autres pendant l'initialisation.
- Vérifier le contexte et créer un namespace isolé.
- Prévoir un Service cible pour observer la readiness.
- Ne pas utiliser un endpoint qui dépendrait d'une base externe pour liveness.
kubectl config current-context
kubectl create namespace adn-probes-labÀ vérifier : Le namespace de test existe.
Point de vigilance ADN : Un défaut de readiness ne devrait pas redémarrer le conteneur.
ÉTAPE 2 / 5
Écrire un Deployment avec les sondes
Les trois probes peuvent employer des mécanismes différents selon le comportement de l'application.
- Créer probes.yaml avec un Deployment nginx et des sondes qui interrogent une page locale.
- Définir explicitement une startupProbe.
- Limiter le scénario à une unique réplique.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-probes
namespace: adn-probes-lab
spec:
replicas: 1
selector:
matchLabels: {app: web-probes}
template:
metadata:
labels: {app: web-probes}
spec:
containers:
- name: nginx
image: nginx:stable-alpine
readinessProbe:
httpGet: {path: /, port: 80}
periodSeconds: 5
livenessProbe:
tcpSocket: {port: 80}
periodSeconds: 10
startupProbe:
tcpSocket: {port: 80}
failureThreshold: 12
periodSeconds: 5À vérifier : Le manifeste contient trois probes distinctes.
Point de vigilance ADN : Les checks HTTP / et TCP/80 sont pédagogiques, pas un contrat de santé métier suffisant.
ÉTAPE 3 / 5
Appliquer le manifeste
Le contrôleur peut accepter un YAML sans produire un Pod Ready.
- Vérifier la syntaxe côté API sans appliquer.
- Appliquer puis attendre la disponibilité.
- Lire les conditions du Pod et les événements.
kubectl apply --dry-run=server -f probes.yaml
kubectl apply -f probes.yaml
kubectl -n adn-probes-lab rollout status deployment/web-probesÀ vérifier : Le Deployment est disponible.
Point de vigilance ADN : Créer le fichier probes.yaml à partir du bloc YAML précédent.
ÉTAPE 4 / 5
Inspecter conditions et événements
Une modification de la seule readiness permet de tester l'exclusion du trafic sans déclencher liveness.
- Sur le Deployment de recette, remplacer temporairement readinessProbe.httpGet.path par /chemin-absent.
- Observer l'état Ready puis les événements.
- Rétablir ensuite le chemin /.
kubectl -n adn-probes-lab patch deployment web-probes --type=json -p='[{"op":"replace","path":"/spec/template/spec/containers/0/readinessProbe/httpGet/path","value":"/chemin-absent"}]'
kubectl -n adn-probes-lab get pods -w
# Après observation, restaurer :
kubectl -n adn-probes-lab patch deployment web-probes --type=json -p='[{"op":"replace","path":"/spec/template/spec/containers/0/readinessProbe/httpGet/path","value":"/"}]'À vérifier : Le Pod devient non Ready lors de l'échec HTTP puis redevient Ready après restauration.
Point de vigilance ADN : Le patch modifie le template et déclenche un rollout ; ne pas confondre remplacement du Pod avec redémarrage par liveness.
ÉTAPE 5 / 5
Vérifier l'effet d'une panne de recette
La recette doit se conclure par un retour à une configuration saine et la purge des objets fictifs.
- Confirmer le retour Ready.
- Inspecter les événements de probe et les redémarrages.
- Supprimer uniquement le namespace dédié.
kubectl -n adn-probes-lab rollout status deployment/web-probes
kubectl -n adn-probes-lab get pods
kubectl delete namespace adn-probes-labÀ vérifier : Le Pod était Ready après restauration et le laboratoire est supprimé.
Point de vigilance ADN : La liveness ne doit pas être rendue volontairement agressive pour simuler une panne en production.
SOURCES ET FIABILITÉ
Statut de validation du guide
Rédaction : ADN Consulting. Statut : procédure documentée, exécution en laboratoire non attestée.
Les exemples et versions indiqués doivent être vérifiés sur un environnement autorisé. Aucune validation individuelle par un consultant n’est revendiquée sans preuve.
05 · RECETTE
Comment vérifier que tout fonctionne ?
Trois sondes aux finalités expliquées.
readiness 404 démontre NotReady.
Rétablissement du Pod Ready vérifié.
Aucun test destructif sur liveness en production.
06 · DIAGNOSTIC
Problèmes fréquents et résolution
ImagePullBackOff
Cause probable : Image absente, accès registre ou tag incorrect
Que faire : Lire kubectl describe pod et les événements avant changement d'image.
CrashLoopBackOff
Cause probable : Conteneur instable ou configuration invalide
Que faire : Lire les logs --previous et livenessProbe ; corriger à la source.
Rollout bloqué
Cause probable : Pods non prêts ou capacité du cluster insuffisante
Que faire : Examiner rollout status, describe et quota du namespace.
Le conseil de l’expert ADN
Avant de généraliser cette configuration, validez-la sur un périmètre représentatif, documentez les critères de réussite et conservez une procédure de retour arrière. Une automatisation fiable se juge sur l’état final observé, les permissions maîtrisées et un retour arrière testé.
07 · QUESTIONS PRATIQUES
Questions fréquentes
Puis-je reprendre ces commandes en production ?
Non sans adaptation, revue de sécurité, approbation de changement et tests sur un environnement identique.
Pourquoi ne suffit-il pas d'appliquer le manifeste ?
Le contrôleur peut accepter l'objet alors que les Pods ne sont pas prêts ou que le service ne répond pas.
AUTRES TECHNOLOGIES
Guides complémentaires
Ce tutoriel s’inscrit dans une chaîne technique plus large. Retrouvez les méthodes associées aux technologies voisines.