## 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 : ```bash 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 : ```bash kubectl api-versions | grep policy ``` La sortie attendue inclut `policy/v1`. ### Inspecter les PDB existants Listez les PDB dans tous les espaces de noms : ```bash 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 -n ` pour voir le sélecteur et l'état : ```bash 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 : ```bash 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` : ```yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: my-app-pdb spec: minAvailable: 2 selector: matchLabels: app: my-app ``` Exemple utilisant `maxUnavailable` : ```yaml 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 : ```bash kubectl apply -f pdb.yaml --dry-run=client ``` 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 : ```bash kubectl apply -f pdb.yaml ``` Vérifiez que le PDB est actif et contrôlez son état actuel : ```bash kubectl get pdb my-app-pdb -o yaml ``` Recherchez les champs `status` : ```yaml 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` : ```bash 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 : ```bash 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 : ```bash 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 : ```bash 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 ` 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 : ```bash 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 : ```bash kubectl logs my-app- --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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash kubectl delete pod --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. | # | Opération | Commande | Résultat attendu | |---|-----------|---------|-----------------| | 1 | Vérifier la version de Kubernetes | `kubectl version --short` | Serveur >=1.21 pour policy/v1beta1, >=1.25 pour policy/v1 | | 2 | Lister tous les PDB | `kubectl get pdb --all-namespaces` | PDB présents avec des perturbations autorisées correctes | | 3 | Vérifier la version de l'API PDB | `kubectl api-versions | grep policy` | Contient `policy/v1` (pour les clusters modernes) | | 4 | Inspecter les détails du PDB | `kubectl describe pdb -n ` | Le sélecteur correspond aux pods, l'état est sain | | 5 | Confirmer que les étiquettes des pods correspondent au sélecteur du PDB | `kubectl get pods -l --show-labels` | Tous les pods prévus sont listés | | 6 | Test à blanc des modifications du PDB | `kubectl apply -f pdb.yaml --dry-run=client` | Aucune erreur, manifeste accepté | | 7 | Appliquer le PDB | `kubectl apply -f pdb.yaml` | PDB créé/configuré | | 8 | Vérifier l'état du PDB après application | `kubectl get pdb -o yaml` | `disruptionsAllowed` > 0 si souhaité | | 9 | Simuler le drainage du nœud | `kubectl drain --dry-run=server` | Éviction bloquée pour les pods comme prévu | | 10 | Surveiller les événements pour les blocages de PDB | `kubectl get events -n | grep -i pdb` | Avertissements EvictionBlocked comme prévu pendant la maintenance | | 11 | Vérifier la préparation des pods | `kubectl get pods -l ` | Tous les pods sont Ready | | 12 | Vérifier l'état du contrôleur | `kubectl rollout status deployment/` | Déploiement réussi | | 13 | Valider le PDB après un incident | `kubectl get pdb -o yaml` et comparer avec la sauvegarde | La configuration correspond aux attentes | | 14 | Documenter les étapes de récupération | Mettre à jour le runbook | Plan de retour en arrière clair en place | 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.