Réglage des performances des sondes Kubernetes avec exemples pratiques : un guide de terrain

Introduction

Les sondes Kubernetes sont essentielles pour contrôler le cycle de vie des conteneurs, mais des sondes mal configurées peuvent provoquer des défaillances en cascade, une latence accrue et des interruptions de service. Cet article fournit un guide pratique de terrain pour le réglage des performances des sondes Kubernetes, couvrant le diagnostic, l'optimisation et la vérification. Il se concentre sur les trois types de sondes – liveness, readiness et startup – et montre comment identifier les goulots d'étranglement, ajuster les paramètres et valider les changements en toute sécurité.

Destiné aux développeurs, ingénieurs DevOps et SRE (Site Reliability Engineering), ce guide comble le fossé entre la théorie et la pratique. Vous apprendrez des techniques concrètes pour améliorer la latence des sondes, réduire les faux positifs et garantir que vos déploiements restent stables sous charge. Nous utiliserons des exemples réels, des commandes et des sorties attendues pour illustrer chaque concept.

Notre approche met l'accent sur la sécurité opérationnelle : toujours observer avant de modifier, limiter la portée des changements, utiliser des espaces réservés pour les valeurs sensibles et vérifier les résultats avec des critères d'acceptation clairs. En suivant ce guide, vous pourrez régler les sondes en toute confiance et minimiser les risques.

Comprendre les sondes Kubernetes

Les sondes Kubernetes sont des contrôles de santé effectués par le kubelet au nom de vos conteneurs. Il en existe trois types :

Les sondes liveness déterminent si un conteneur est vivant. En cas d'échec, le kubelet tue le conteneur et le redémarre conformément à votre politique de redémarrage.
Les sondes readiness déterminent si un conteneur est prêt à servir le trafic. En cas d'échec, les points de terminaison du conteneur sont retirés du service, de sorte qu'aucun trafic ne lui est envoyé.
Les sondes startup sont utilisées pour les conteneurs qui ont besoin de temps supplémentaire pour démarrer. Elles réussissent lorsque l'application est prête, puis les sondes liveness/readiness prennent le relais.

Chaque sonde est configurée avec quatre paramètres :

initialDelaySeconds : combien de temps attendre après le démarrage du conteneur avant de sonder.
periodSeconds : la fréquence des sondes.
timeoutSeconds : combien de temps attendre une réponse avant de considérer la sonde en échec.
failureThreshold : combien d'échecs consécutifs déclenchent un redémarrage (pour liveness) ou un retrait du service (pour readiness).
successThreshold : combien de succès consécutifs sont nécessaires pour considérer la sonde comme réussie après un échec (readiness uniquement).

Les gestionnaires de sondes courants incluent :

exec : exécute une commande dans le conteneur ; succès si le code de sortie est 0.
httpGet : effectue une requête HTTP GET ; succès si le code de réponse est 200-399.
tcpSocket : tente d'ouvrir une connexion TCP ; succès si le port accepte une connexion.

Un réglage approprié implique de choisir le bon gestionnaire, de définir des seuils appropriés et de s'assurer que les points de terminaison de votre application répondent rapidement.

Inventaire de version et d'environnement

Avant de régler une sonde, vous devez comprendre votre environnement. Cela implique d'identifier :

La version de Kubernetes : la version détermine les fonctionnalités de sonde disponibles (par exemple, les sondes startup sont en bêta en 1.16 et en disponibilité générale en 1.20).
Le runtime de conteneur : par exemple, containerd, CRI-O, Docker (déprécié).
Le plugin réseau : par exemple, Calico, Flannel, Cilium, qui peut affecter les temps de réponse des sondes.
La pile d'application : langage de programmation, framework et dépendances qui affectent le temps de démarrage et l'utilisation des ressources.

Observation en lecture seule : Commencez par recueillir l'état actuel de vos pods et leurs configurations de sondes. Utilisez kubectl get pods -o wide pour voir la liste des pods et leurs adresses IP. Ensuite, pour un pod spécifique, exécutez kubectl describe pod <nom-du-pod> pour afficher ses paramètres de sonde actuels et les événements récents. Vérifiez également les journaux avec kubectl logs <nom-du-pod> --previous pour comprendre pourquoi un conteneur précédent a planté.

Vérification des prérequis : Assurez-vous que kubectl est configuré et que vous disposez des autorisations adéquates. Vérifiez votre version de cluster avec kubectl version.

Exemple de commande :

kubectl get pods -o wide
kubectl describe pod mon-app-7d8f9b5c5c-abc123

Sortie attendue : La sortie describe inclut une section comme :

Liveness:   http-get http://:8080/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
Readiness:  http-get http://:8080/readyz delay=0s timeout=1s period=10s #success=1 #failure=3

Vous avez maintenant une référence pour comparer.

Chemin de configuration sécurisé

Lorsque vous décidez de modifier une sonde, suivez un chemin sûr : effectuez un petit changement réversible à la fois, et vérifiez-le avant de passer au suivant. Cela limite la portée des conséquences si quelque chose tourne mal.

Plus petit changement justifié : Par exemple, si votre sonde readiness entraîne le retrait inutile des points de terminaison en raison de réponses lentes, vous pouvez augmenter légèrement le failureThreshold ou le timeoutSeconds. Ne modifiez pas plusieurs paramètres en même temps.

Testez d'abord localement : Utilisez un cluster de développement ou de staging pour tester les modifications. Vous pouvez également utiliser kubectl port-forward pour tester les points de terminaison de santé de votre application localement avant de déployer les changements.

Exemple de commande : D'abord, inspectez la configuration actuelle de la sonde avec :

kubectl get deployment mon-app -o jsonpath='{.spec.template.spec.containers[0].livenessProbe}'

Ensuite, appliquez un patch pour modifier le délai d'expiration :

kubectl patch deployment mon-app -p '{"spec":{"template":{"spec":{"containers":[{"name":"mon-app","livenessProbe":{"timeoutSeconds":2}}]}}}}'

Sortie attendue : Le déploiement est mis à jour et un nouveau ReplicaSet est créé. Vérifiez l'état du déploiement :

kubectl rollout status deployment/mon-app

Point clé : Vérifiez toujours l'impact sur l'application avant et après le changement. Utilisez des métriques de votre application, telles que la latence des requêtes, les taux d'erreur et les redémarrages de pods, pour déterminer si le changement a amélioré les choses.

Vérification et diagnostics

Après avoir effectué un changement, vous devez vérifier qu'il atteint l'effet souhaité sans effets secondaires. Cela implique à la fois des contrôles automatisés et une inspection manuelle.

Observer les résultats : Utilisez kubectl describe pod pour voir si les sondes passent maintenant. Consultez la section Événements pour tout nouvel échec. Surveillez également l'état du pod : par exemple, kubectl get pod -o wide pour voir si le pod est Running et Ready.

Vérifiez les journaux de l'application : Recherchez des modèles indiquant le succès ou l'échec des sondes. Par exemple, si vous avez un point de terminaison de santé qui journalise chaque requête, vous pouvez voir si les sondes l'atteignent et combien de temps elles prennent.

Exemple de commande : Pour vérifier si la sonde atteint un point de terminaison spécifique, vous pouvez suivre les journaux :

kubectl logs deployment/mon-app --tail=10

Sortie attendue : Vous devriez voir des lignes de journal comme :

Requête de sonde reçue à /healthz depuis 10.244.0.5:45922 - 200 OK (0.4 ms)

Commandes de diagnostic utiles :

kubectl get events --sort-by=.lastTimestamp pour voir les événements du cluster, y compris les échecs de sonde.
kubectl describe node <nom-du-nœud> pour vérifier la santé du nœud et de son kubelet.

Vérification de la correction : Si vous avez augmenté le délai d'expiration de la sonde parce qu'elle expirait, vous pouvez simuler une réponse lente en stressant le point de terminaison. Par exemple, avec curl et le chronométrage :

curl -o /dev/null -s -w 'time_total: %{time_total}\n' http://<ip-du-pod>:8080/healthz

Si le temps de réponse est maintenant dans le délai d'expiration, la sonde devrait réussir.

Modes de défaillance et récupération

Comprendre les modes de défaillance est crucial pour un réglage efficace. Les défaillances courantes incluent :

Délai d'expiration de la sonde : La commande ou la requête HTTP prend plus de temps que timeoutSeconds. Cela peut être dû à un serveur lent ou à des problèmes réseau.
Connexion refusée : Le port n'est pas ouvert, indiquant que l'application n'écoute pas encore.
Réponse invalide : Le point de terminaison HTTP renvoie un code non-2xx. Cela peut être dû à un chemin de contrôle de santé mal configuré.
Surcharge de l'application : Le conteneur consomme trop de CPU/mémoire, ce qui ralentit les réponses aux sondes.

Chacune de ces situations nécessite une stratégie de récupération différente.

Étapes de récupération :

Immédiat : Vérifiez l'état du pod et les événements. Si le pod est en CrashLoopBackOff, inspectez les journaux pour comprendre la cause.

   kubectl logs mon-app-7d8f9b5c5c-abc123 --previous

Diagnostic : Utilisez kubectl exec pour tester le point de terminaison depuis l'intérieur du conteneur :

   kubectl exec -it mon-app-7d8f9b5c5c-abc123 -- curl localhost:8080/healthz

Atténuation : Si la sonde échoue parce que l'application est lente à démarrer, envisagez d'augmenter initialDelaySeconds ou d'ajouter une sonde startup. Si l'application est sous charge importante, augmentez la capacité ou améliorez les demandes/limites de ressources.

Exemple de scénario : Votre sonde liveness utilise un point de terminaison HTTP qui effectue une requête de base de données. Pendant un ralentissement de la base de données, la sonde expire, provoquant le redémarrage du conteneur. Pour récupérer, vous pourriez changer le point de terminaison liveness en un contrôle plus léger (par exemple, une vérification de processus simple) ou augmenter le délai d'expiration. Documentez toujours le changement et sa justification.

Vérification de la récupération : Après avoir appliqué un correctif, assurez-vous que le pod reste sain pendant une période prolongée. Utilisez kubectl get pods -w pour surveiller les redémarrages.

Liste de contrôle opérationnelle

Pour garantir la cohérence et la sécurité, suivez cette liste de contrôle lors du réglage des sondes :

[ ] Version et environnement : Confirmez la version de Kubernetes, le runtime, le réseau et la pile d'application.
[ ] Observation de référence : Enregistrez la configuration actuelle des sondes (avec kubectl describe) et les métriques de l'application.
[ ] Diagnostic en lecture seule : Vérifiez l'état des pods, les événements et les journaux.
[ ] Changement unique : Modifiez un seul paramètre de sonde à la fois.
[ ] Test en développement : Appliquez d'abord le changement dans un environnement non production.
[ ] Validez : Vérifiez les intervalles de succès/échec des sondes à l'aide de kubectl get events et des journaux d'application.
[ ] Surveillez : Surveillez les changements dans le nombre de redémarrages, la disponibilité (readiness) et le trafic.
[ ] Documentez : Enregistrez ce que vous avez changé, pourquoi et le résultat.
[ ] Plan de retour arrière : Si le changement dégrade les performances, revenez à la configuration précédente.

Astuce d'automatisation : Utilisez des pratiques de type GitOps où vos manifestes Kubernetes sont versionnés. Vous pouvez alors examiner les changements de sondes dans des pull requests et revenir en arrière facilement.

Conclusion

Régler les sondes Kubernetes est une tâche délicate qui nécessite une approche systématique. En comprenant votre environnement, en effectuant des changements progressifs et en vérifiant avec des métriques concrètes, vous pouvez optimiser les performances des sondes sans introduire d'instabilité.

Rappelez-vous : l'objectif n'est pas seulement de faire passer les sondes, mais de garantir que votre application est réellement saine et disponible. Utilisez les techniques décrites ici pour diagnostiquer les problèmes, appliquer des correctifs et confirmer qu'ils fonctionnent. Documentez toujours vos changements et conservez un plan de retour arrière.

Comme prochaine étape, auditez vos déploiements actuels : listez toutes les configurations de sondes, identifiez celles qui sont inhabituellement agressives ou laxistes, et planifiez un exercice de réglage pour un déploiement en suivant ce guide. Avec de la pratique, vous pourrez ajuster les sondes en toute confiance et maintenir vos services en bon état de fonctionnement.

Maintenant, allez-y et appliquez ces principes à vos propres clusters, et construisez un environnement Kubernetes plus résilient.