Kubernetes Pod Disruption Budget : liste de contrôle opérationnelle pour la production

Introduction

Les Pod Disruption Budgets (PDB) de Kubernetes sont une protection essentielle pour maintenir la disponibilité des applications lors de perturbations volontaires, telles que les drainages de nœuds, les mises à niveau de cluster ou les opérations de maintenance. Cependant, des PDB mal configurés peuvent bloquer les opérations, provoquer des interruptions inattendues ou donner un faux sentiment de sécurité. Cet article fournit une liste de contrôle opérationnelle axée sur la production, avec des exemples pratiques, des commandes et des signaux de défaillance. Il est destiné aux développeurs, aux consultants DevOps et aux équipes techniques de startups qui doivent passer de l'observation d'un problème à la vérification d'une solution.

Nous couvrirons cinq domaines opérationnels clés : l'inventaire de la version et de l'environnement, le chemin de configuration sûr, la vérification et le diagnostic, les modes de défaillance et la récupération, et une liste de contrôle des opérations. Pour chacun, nous fournissons des commandes concrètes, des sorties attendues et des décisions de récupération. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier les résultats et documenter les chemins de récupération.

Inventaire de la version et de l'environnement

Avant de toucher à un PDB, comprenez votre environnement. Cette section décrit comment inventorier votre version de Kubernetes, la topologie du cluster et les PDB existants pour éviter les surprises de compatibilité.

Vérifier la version de Kubernetes

Utilisez kubectl version pour voir les versions client et serveur :

kubectl version --short

Sortie attendue (exemple) :

Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.27.3

La version de l'API PDB a changé : policy/v1beta1 a été dépréciée dans Kubernetes 1.21 et supprimée dans 1.25. Pour les clusters 1.25+, utilisez policy/v1. Vérifiez avec :

kubectl api-versions | grep policy

La sortie attendue inclut policy/v1.

Inspecter les PDB existants

Listez les PDB dans tous les espaces de noms :

kubectl get pdb --all-namespaces

Exemple de sortie :

NAMESPACE     NAME             MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
default       my-app-pdb       N/A             1                 1                     45d
kube-system   coredns-pdb      1               N/A               0                     120d

Cela montre l'état actuel. Notez la colonne ALLOWED DISRUPTIONS : elle vous indique combien de pods peuvent être évincés volontairement simultanément sans violer le PDB.

Vérifier que les étiquettes des pods correspondent aux sélecteurs

Les PDB sélectionnent les pods via des étiquettes. Utilisez kubectl describe pdb <nom> -n <namespace> pour voir le sélecteur et l'état :

kubectl describe pdb my-app-pdb -n default

Extrait :

Selector:
  app=my-app
Status:
  Current Healthy: 3
  Desired Healthy: 2
  Disruptions Allowed: 1

Assurez-vous que tous les pods concernés ont des étiquettes correspondantes. Vérifiez avec :

kubectl get pods -l app=my-app -n default

Si des pods n'ont pas les bonnes étiquettes, le PDB peut ne pas les protéger.

Vérification des prérequis

• Assurez-vous d'avoir accès à kubectl et les autorisations RBAC appropriées : get, list, watch sur poddisruptionbudgets.
• Confirmez que le contrôleur de charge de travail (Deployment, StatefulSet, etc.) est présent et sain. Par exemple, kubectl rollout status deployment/my-app devrait afficher successfully rolled out.

Chemin de configuration sûr

Cette section détaille comment créer ou modifier un PDB en toute sécurité, en évitant les pièges courants comme des sélecteurs invalides ou des budgets impossibles.

Comprendre les paramètres du PDB

Un PDB peut spécifier soit minAvailable soit maxUnavailable, mais pas les deux. minAvailable est le nombre minimum de pods qui doivent rester disponibles après les évictions ; maxUnavailable est le nombre maximum de pods qui peuvent être indisponibles. Utilisez l'un ou l'autre, exprimé en entier ou en pourcentage (par exemple, 2 ou 30%).

Exemple de PDB YAML utilisant minAvailable :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Exemple utilisant maxUnavailable :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: my-app

Choisissez les paramètres en fonction des exigences de quorum ou de disponibilité de votre application. Pour une application sans état avec 3 réplicas, maxUnavailable: 1 est courant. Pour une application avec état nécessitant un quorum, minAvailable: 2 peut être approprié.

Test à blanc avant d'appliquer

Faites toujours un test à blanc pour valider le manifeste :

kubectl create poddisruptionbudget my-pdb --selector=app=nginx --min-available=1

Sortie attendue : poddisruptionbudget.policy/my-app-pdb created (dry run)

Vérifiez que la version de l'API est acceptée. Si vous obtenez une erreur comme no matches for kind "PodDisruptionBudget" in version "policy/v1beta1", passez à policy/v1.

Appliquer et vérifier l'état

Appliquez le PDB :

kubectl create poddisruptionbudget my-pdb --selector=app=nginx --min-available=1

Vérifiez que le PDB est actif et contrôlez son état actuel :

kubectl get pdb my-app-pdb -o yaml

Recherchez les champs status :

status:
  currentHealthy: 3
  desiredHealthy: 2
  disruptionsAllowed: 1
  expectedPods: 3
  observedGeneration: 1

Si disruptionsAllowed est 0, le PDB empêche actuellement toutes les évictions volontaires, ce qui pourrait bloquer la maintenance.

Tester avec un drainage simulé

Pour tester en toute sécurité l'effet du PDB sans affecter la production, utilisez kubectl drain avec --dry-run :

kubectl drain node-1 --dry-run=server

Cela simule le processus d'éviction et indique quels pods seraient bloqués par les PDB. Exemple de sortie :

node/node-1 cordoned
evicting pod default/my-app-1
evicting pod default/my-app-2
error when evicting pod default/my-app-3: Cannot evict pod as it would violate the pod's disruption budget.

Cela confirme que le PDB fonctionne comme prévu.

Vérification et diagnostic

Après avoir configuré un PDB, vous devez continuellement vérifier son comportement et diagnostiquer les problèmes lorsque les perturbations sont bloquées ou que des pods sont inopinément indisponibles.

Contrôles d'état de routine

Exécutez périodiquement :

kubectl get pdb --all-namespaces

Surveillez les PDB avec ALLOWED DISRUPTIONS égal à 0 pendant de longues périodes, ce qui peut entraver la maintenance des nœuds. Vérifiez également que CURRENT HEALTHY correspond aux attentes ; s'il est inférieur, les pods peuvent être en échec ou les étiquettes incorrectes.

Inspecter les événements pour les blocages de PDB

Lorsqu'un drainage ou une mise à niveau se bloque, vérifiez les événements dans l'espace de noms :

kubectl get events -n default --sort-by='.lastTimestamp' | grep -i pdb

Exemple de sortie :

Warning   EvictionBlocked    Pod/my-app-3   Cannot evict pod as it would violate the pod's disruption budget.

Cela indique que le PDB fait son travail, mais vous devrez peut-être l'ajuster temporairement ou résoudre la santé de l'application.

Vérifier la santé et la préparation des pods

Le PDB s'appuie sur l'état de préparation pour compter les pods sains. Si les pods ne sont pas prêts, ils ne sont pas comptés comme sains et peuvent réduire disruptionsAllowed. Vérifiez la préparation avec :

kubectl get pods -l app=my-app -o wide

Recherchez READY 1/1 et STATUS Running. Pour un diagnostic plus approfondi, utilisez kubectl describe pod <nom> et vérifiez les Conditions et les Events.

Vérifier l'état du contrôleur

Si des pods ne sont pas créés ou sont bloqués, vérifiez le Deployment ou StatefulSet propriétaire :

kubectl rollout status deployment/my-app

Sortie attendue : deployment "my-app" successfully rolled out

Si ce n'est pas le cas, enquêtez avec kubectl describe deployment my-app et les journaux des pods :

kubectl logs my-app-<hash> --previous

Modes de défaillance et récupération

Comprendre les modes de défaillance courants vous aide à agir rapidement. Cette section couvre les problèmes typiques et les étapes de récupération.

Mode de défaillance : le PDB bloque tous les drainages en raison de 0 perturbations autorisées

Symptôme : kubectl drain échoue avec des erreurs d'éviction pour tous les pods du PDB.

Diagnostic :

kubectl get pdb my-app-pdb -o jsonpath='{.status.disruptionsAllowed}'

Si la sortie est 0, le PDB est trop strict.

Options de récupération :

• Augmentez temporairement maxUnavailable ou diminuez minAvailable (avec contrôle des modifications).
• Augmentez temporairement le nombre de réplicas pour offrir plus de marge pour l'éviction.
• Si la charge de travail est sans état et peut tolérer une interruption, supprimez le PDB avec kubectl delete pdb my-app-pdb (assurez-vous de le recréer plus tard).

Communiquez toujours les changements et revenez en arrière après la maintenance.

Mode de défaillance : le PDB ne protège pas les pods en raison d'une non-correspondance des étiquettes

Symptôme : lors du drainage du nœud, les pods sont évincés même si le PDB existe.

Diagnostic : comparez le sélecteur du PDB avec les étiquettes des pods :

kubectl get pdb my-app-pdb -o jsonpath='{.spec.selector.matchLabels}'
kubectl get pods -l app=my-app --show-labels

Si les étiquettes ne correspondent pas, le PDB n'a aucun effet.

Récupération : corrigez le sélecteur ou les étiquettes des pods, appliquez et vérifiez avec kubectl get pdb -o yaml que expectedPods est égal au nombre de pods prévus.

Mode de défaillance : le PDB avec pourcentage provoque un blocage inattendu

Symptôme : disruptionsAllowed est calculé en pourcentage, et l'arrondi conduit à 0 lorsque les réplicas sont peu nombreux.

Exemple : minAvailable: 50% avec 3 réplicas donne desiredHealthy=2, autorisant 1 perturbation. Mais avec 1 réplica (par exemple, lors d'une réduction d'échelle), desiredHealthy=1, donc 0 perturbation autorisée, bloquant même une seule éviction de maintenance.

Diagnostic : vérifiez kubectl get pdb et currentHealthy vs desiredHealthy.

Récupération : utilisez des valeurs entières pour les petits nombres de réplicas, ou assurez-vous que le nombre minimal de réplicas permette un pourcentage sûr. Par exemple, avec 3 réplicas, utilisez minAvailable: 1 (absolu) pour garantir au moins une perturbation autorisée.

Mode de défaillance : le PDB empêche la mise à niveau du nœud parce que des pods restent bloqués en terminaison

Symptôme : le drainage se bloque avec des pods en état Terminating, et aucune erreur d'éviction.

Diagnostic : vérifiez l'état des pods :

kubectl get pods -o wide

Si des pods sont bloqués, ils peuvent avoir des finaliseurs ou des hooks preStop suspendus.

Récupération : examinez les détails du pod ; forcez la suppression si nécessaire :

kubectl delete pod <nom> --grace-period=0 --force

Puis réessayez le drainage. Assurez-vous que le PDB ne bloque pas par inadvertance en raison de pods non sains.

Liste de contrôle des opérations

Utilisez cette liste de contrôle condensée pour les opérations régulières sur les PDB. Chaque élément inclut la commande et le résultat attendu.

Examinez régulièrement les PDB par rapport aux exigences de l'application et aux changements du cluster. Automatisez les vérifications lorsque cela est possible à l'aide de scripts ou de CI/CD.

Conclusion

Une liste de contrôle opérationnelle pour les Kubernetes Pod Disruption Budgets en production n'est utile que si chaque recommandation est délimitée par version, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure opérationnelle. Cet article a fourni des commandes concrètes, des exemples de configuration et des scénarios de défaillance pour vous aider à gérer les PDB en toute sécurité.

Comme prochaine étape, choisissez une vérification à faible risque dans la liste, comme un drainage simulé ou un contrôle d'état du PDB. Enregistrez l'état actuel, exécutez la vérification documentée, comparez avec les signaux attendus et examinez les dépendances comme les Deployments, les StatefulSets et les Nodes. Gardez les défaillances visibles, protégez les valeurs sensibles, limitez les modifications aux ressources prévues et définissez la vérification de la récupération avant qu'un incident ne force la décision.

En suivant cette liste de contrôle, vous pouvez vous assurer que les Pod Disruption Budgets restent un outil fiable pour maintenir la disponibilité lors de perturbations volontaires sans devenir un goulot d'étranglement opérationnel.