Automatiser les flux de travail d'éviction sous pression des nœuds Kubernetes avec CI/CD : un guide pratique

Introduction

L'éviction sous pression des nœuds Kubernetes est un mécanisme essentiel qui protège la stabilité du cluster lorsque les nœuds manquent de ressources comme la mémoire, le disque ou les inodes. Lorsque les seuils sont franchis, le kubelet évince de manière proactive les pods pour récupérer des ressources et éviter une défaillance du nœud. Pour les équipes plateforme, réagir manuellement aux évictions est lent et source d'erreurs. Automatiser les flux de détection, de réponse et de récupération avec des pipelines CI/CD transforme un incident chaotique en un processus contrôlé et reproductible.

Ce guide s'adresse aux développeurs, aux ingénieurs DevOps et aux équipes techniques de startups qui exploitent des clusters Kubernetes et souhaitent intégrer la gestion des évictions dans leur automatisation. Vous apprendrez à identifier les risques d'éviction, à configurer des seuils sûrs, à construire des pipelines qui détectent et répondent à la pression, et à vérifier que votre automatisation fonctionne sans causer plus de dégâts. Chaque section inclut des commandes concrètes, des sorties attendues et des signaux d'échec afin que vous puissiez appliquer les modèles immédiatement.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des variables d'environnement plutôt que des secrets en clair, vérifier le résultat et documenter les étapes de récupération avant qu'un incident ne force une décision.

Inventaire des versions et de l'environnement

Avant d'automatiser les flux d'éviction, vous devez connaître la version de votre cluster, le système d'exploitation des nœuds, la configuration du kubelet et les outils CI/CD disponibles. Le comportement d'éviction sous pression des nœuds a évolué au fil des versions de Kubernetes, notamment avec l'introduction des seuils d'éviction doux (soft eviction) et des paramètres evictionHard et evictionSoft.

Prérequis :

• Version de cluster Kubernetes 1.20 ou ultérieure (vérifiez avec kubectl version)
• Accès aux métriques des nœuds (metrics-server ou Prometheus)
• Un système CI/CD (GitHub Actions, GitLab CI, Jenkins, etc.)
• Permissions de visualiser les nœuds et les pods (kubectl get nodes, kubectl get pods)
• Accès en lecture à la configuration du kubelet sur les nœuds (généralement /var/lib/kubelet/config.yaml)

Commencez par un inventaire en lecture seule de l'état de votre cluster. Exécutez ces commandes et capturez la sortie :

# Vérifier la version de Kubernetes
kubectl version --short

# Lister les nœuds et leurs conditions
kubectl get nodes -o wide

# Afficher les conditions des nœuds, y compris MemoryPressure et DiskPressure
kubectl describe node <nom-du-nœud> | grep -A 5 Conditions

Exemple de sortie attendue :

Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Thu, 12 Oct 2023 10:15:32 +0000   Thu, 12 Oct 2023 09:45:11 +0000   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Thu, 12 Oct 2023 10:15:32 +0000   Thu, 12 Oct 2023 09:45:11 +0000   KubeletHasNoDiskPressure     kubelet has sufficient disk available
  PIDPressure      False   Thu, 12 Oct 2023 10:15:32 +0000   Thu, 12 Oct 2023 09:45:11 +0000   KubeletHasSufficientPID      kubelet has sufficient PID available

Si une condition est à True, notez la raison et le message. Par exemple, MemoryPressure peut indiquer KubeletHasInsufficientMemory avec un message concernant la mémoire disponible tombant sous le seuil.

Ensuite, inspectez la configuration du kubelet sur un nœud pour voir les seuils d'éviction actuels. Connectez-vous en SSH à un nœud (ou utilisez un pod privilégié) et exécutez :

cat /var/lib/kubelet/config.yaml | grep -A 10 eviction

Exemple de sortie :

evictionHard:
  memory.available: "200Mi"
  nodefs.available: "10%"
  nodefs.inodesFree: "5%"
  imagefs.available: "15%"
evictionSoft:
  memory.available: "500Mi"
  nodefs.available: "15%"
evictionSoftGracePeriod:
  memory.available: "1m30s"
  nodefs.available: "2m"

Enregistrez ces valeurs. Elles définissent quand l'éviction démarre et son agressivité. Les modifications de ces paramètres doivent être versionnées et déployées via votre pipeline CI/CD, pas par édition manuelle sur les nœuds.

Enfin, vérifiez si vous avez une surveillance en place. Interrogez Prometheus pour l'utilisation de la mémoire et du disque des nœuds :

# Pourcentage d'utilisation de la mémoire par nœud
100 * (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes))

# Pourcentage d'utilisation du disque pour /var/lib/kubelet
100 * (1 - (node_filesystem_avail_bytes{mountpoint="/var/lib/kubelet"} / node_filesystem_size_bytes{mountpoint="/var/lib/kubelet"}))

Sans métriques, vous ne pouvez pas détecter la pression suffisamment tôt pour réagir de manière proactive.

Chemin de configuration sûr

L'automatisation de la réponse aux évictions commence par une gestion de configuration sûre. Ne modifiez jamais les drapeaux du kubelet directement sur un nœud ; utilisez plutôt un outil de gestion de configuration (Ansible, Puppet ou un pool de nœuds géré) ou un DaemonSet qui met à jour le fichier de configuration du kubelet et redémarre le kubelet de manière contrôlée.

Principes pour une configuration sûre :

• Séparer l'observation de l'intervention : collectez d'abord les métriques et les journaux, puis décidez s'il faut modifier les seuils.
• Limiter le rayon d'impact : appliquez les modifications à un nœud ou à un petit pool de nœuds d'abord, vérifiez, puis déployez.
• Utiliser des variables d'environnement pour les secrets : si votre automatisation a besoin d'informations d'identification (par exemple, pour drainer un nœud), stockez-les dans un gestionnaire de secrets et injectez-les comme variables d'environnement, jamais en texte brut.
• Vérifier le résultat : après une modification, vérifiez les conditions des nœuds et l'état des pods pour confirmer l'effet souhaité.

Un exemple concret : supposons que vous vouliez augmenter le seuil d'éviction de mémoire dure de 200Mi à 500Mi pour réduire les évictions lors de pics transitoires. La modification doit être effectuée dans un dépôt Git qui contient vos modèles de configuration du kubelet. Un pipeline pourrait appliquer la modification à un nœud de test et vérifier l'impact.

Flux de travail de configuration sûr étape par étape :

1. Créez une modification de configuration dans Git. Par exemple, mettez à jour un fichier YAML utilisé par votre gestion de configuration :

# kubelet-config.yaml
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "10%"
  nodefs.inodesFree: "5%"
  imagefs.available: "15%"

1. Ouvrez une demande d'extraction (pull request). Le pipeline CI exécute une vérification de style et un essai à vide (dry-run) contre un cluster de test. Par exemple, en utilisant kubectl dry-run sur une ConfigMap qui imite la configuration du kubelet :

kubectl create configmap kubelet-config-test --from-file=kubelet-config.yaml --dry-run=client -o yaml

1. Fusionnez la PR et déployez sur un nœud canari. Utilisez un travail qui copie le fichier et redémarre le kubelet sur ce nœud uniquement :

# Exemple avec Ansible
ansible-playbook -i inventory.ini update-kubelet.yml --limit node-canary-1

1. Vérifiez le nœud après le redémarrage. Vérifiez que le kubelet est revenu et que le nouveau seuil est en vigueur :

kubectl get node node-canary-1
kubectl describe node node-canary-1 | grep -A 5 Conditions

Inspectez également les journaux du kubelet :

journalctl -u kubelet -n 50 --no-pager

Recherchez des erreurs comme failed to parse eviction thresholds ou invalid eviction threshold.

1. Si la vérification réussit, déployez sur les nœuds restants par lots, pas tous en même temps. Surveillez la stabilité du cluster après chaque lot.

Responsable et fréquence de révision : Attribuez un responsable pour les modifications de configuration du kubelet, comme le responsable de l'ingénierie plateforme. Révisez les seuils trimestriellement ou après tout incident pour vous assurer qu'ils correspondent aux changements de charge de travail.

Vérification et diagnostic

Après avoir configuré ou répondu à une pression d'éviction, vous devez vérifier que votre automatisation fonctionne et que le cluster est sain. Cette section vous donne des commandes concrètes et des résultats attendus pour chaque étape.

1. Vérifier les conditions de pression des nœuds

Exécutez :

kubectl get nodes -o custom-columns=NAME:.metadata.name,MemoryPressure:.status.conditions[?(@.type=="MemoryPressure")].status,DiskPressure:.status.conditions[?(@.type=="DiskPressure")].status,PIDPressure:.status.conditions[?(@.type=="PIDPressure")].status

La sortie attendue montre tous les False pour des nœuds sains. Si l'un affiche True, enquêtez immédiatement.

2. Vérifier les pods évincés

Listez les pods qui ont été évincés :

kubectl get pods --all-namespaces --field-selector=status.phase=Failed | grep Evicted

Ou avec une requête JSON :

kubectl get pods --all-namespaces -o json | jq '.items[] | select(.status.reason=="Evicted") | .metadata.name + " in " + .metadata.namespace'

Exemple de sortie :

my-app-7d5f8b9c4-abcde in default
cache-worker-6f4b7d8c9-fghij in staging

3. Vérifier les journaux du kubelet pour les événements d'éviction

Sur un nœud, exécutez :

journalctl -u kubelet | grep -i evict

Exemple de ligne de journal :

I1012 10:20:15.123456    1234 eviction_manager.go:340] "Evicting pod" pod="default/my-app-7d5f8b9c4-abcde" reason="memory.available" message="Pod uses more memory than its request and node is under memory pressure"

Notez la raison et le message. Cela vous indique quelle ressource a déclenché l'éviction et si le pod a dépassé sa demande.

4. Vérifier les demandes et limites de ressources des pods

Souvent, l'éviction se produit parce que les pods n'ont pas de demandes de ressources appropriées. Vérifiez les demandes d'un pod :

kubectl get pod <nom-du-pod> -o jsonpath='{.spec.containers[*].resources}'

Si les demandes sont absentes ou trop faibles, le kubelet ne peut pas prendre de décisions d'éviction éclairées.

5. Simuler une pression (essai à vide) en toute sécurité

Vous pouvez simuler une pression mémoire sur un nœud de test en déployant un pod qui consomme de la mémoire, mais faites-le toujours dans un environnement hors production et avec un plan de restauration clair. Exemple :

apiVersion: v1
kind: Pod
metadata:
  name: memory-eater
spec:
  containers:
  - name: stress
    image: polinux/stress
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "2G", "--vm-hang", "1"]

Appliquez-le, surveillez les conditions du nœud et voyez si une éviction se produit. Cela aide à valider vos seuils et vos alertes.

6. Tester votre pipeline d'alerte

Si vous avez des alertes Prometheus pour la pression des nœuds, déclenchez une alerte de test et confirmez que votre canal de notification (Slack, PagerDuty, etc.) la reçoit. Par exemple, une règle d'alerte Prometheus :

groups:
- name: node-pressure
  rules:
  - alert: NodeMemoryPressure
    expr: kube_node_status_condition{condition="MemoryPressure",status="true"} == 1
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Node {{ $labels.node }} is under memory pressure"

Vérifiez que l'alerte se déclenche et atteint les destinataires prévus.

Modes de défaillance et récupération

Même avec l'automatisation, les choses peuvent mal tourner. Voici les modes de défaillance courants et comment récupérer de chacun.

Mode de défaillance 1 : Boucle d'éviction (le pod continue d'être évincé)

Pourquoi cela arrive : Un pod a une demande de ressources trop élevée pour la capacité disponible du nœud, ou le nœud est surchargé de manière persistante. Le planificateur place le pod, le kubelet l'évince, et le pod est replanifié, répétant le cycle.

Comment détecter : Évictions fréquentes du même pod dans la sortie de kubectl get pods, et conditions de pression des nœuds qui fluctuent.

Récupération :

• Réduisez les demandes de ressources du pod pour tenir dans la capacité du nœud.
• Ajoutez plus de nœuds ou augmentez la capacité des nœuds.
• Utilisez l'anti-affinité de pod pour répartir les pods sur les nœuds.
• Si le pod n'est pas critique, abaissez sa classe de priorité.

Mode de défaillance 2 : Éviction agressive causant une interruption de service

Pourquoi cela arrive : Des seuils d'éviction dure réglés trop haut (ou trop bas, selon la ressource) amènent le kubelet à évincer les pods trop tôt, même lorsque le nœud aurait pu survivre avec une éviction douce.

Comment détecter : Chute soudaine des pods disponibles pour un service, augmentation des erreurs 5xx ou plaintes des utilisateurs.

Récupération :

• Ajustez les seuils d'éviction pour être moins agressifs (par exemple, augmentez le seuil de mémoire disponible).
• Implémentez une éviction douce avec des périodes de grâce pour permettre aux pods de se terminer proprement.
• Définissez des PodDisruptionBudgets pour garantir qu'un nombre minimum de pods restent disponibles.

Mode de défaillance 3 : L'automatisation applique des modifications sans vérification

Pourquoi cela arrive : Le pipeline CI/CD applique des modifications de configuration mais ne vérifie pas les conditions des nœuds ou l'état des pods ensuite. Une mauvaise modification peut se propager à tous les nœuds, provoquant une éviction généralisée.

Comment détecter : Événements d'éviction à l'échelle du cluster ou défaillances de nœuds peu après un déploiement.

Récupération :

• Annulez la modification de configuration en utilisant le mécanisme de restauration de votre pipeline (par exemple, revenez sur le commit Git et redéployez).
• Assurez-vous que votre pipeline inclut une étape de vérification avec des contrôles explicites avant de passer au lot suivant.
• Utilisez des déploiements canaris pour les modifications de configuration.

Mode de défaillance 4 : Métriques manquantes ou inexactes

Pourquoi cela arrive : Les composants de surveillance ne sont pas installés ou sont mal configurés, de sorte que vous ne pouvez pas voir la pression des nœuds avant qu'il ne soit trop tard.

Comment détecter : Pas de données dans les tableaux de bord ou alertes qui ne se déclenchent pas lorsque la pression se produit.

Récupération :

• Installez metrics-server s'il est absent : kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
• Vérifiez que metrics-server fonctionne : kubectl get deployment metrics-server -n kube-system
• Vérifiez les métriques des nœuds : kubectl top nodes

Exemple de sortie :

NAME                 CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node-1               350m         8%     1400Mi          38%
node-2               200m         5%     900Mi           25%

Mode de défaillance 5 : Pods évincés non replanifiés

Pourquoi cela arrive : Après l'éviction, le planificateur peut ne pas replanifier le pod s'il n'y a pas de nœud approprié, ou si le pod a un sélecteur de nœud qui ne correspond plus à aucun nœud.

Comment détecter : Pods bloqués à l'état Pending après l'éviction.

Récupération :

• Vérifiez les événements du pod : kubectl describe pod <nom-du-pod>
• Vérifiez la capacité et les teintures des nœuds : kubectl describe node <nom-du-nœud>
• Si nécessaire, supprimez manuellement le pod pour forcer la replanification, ou mettez à l'échelle le déploiement.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après la mise en œuvre de l'automatisation des évictions. Chaque élément doit avoir un responsable clair et être revu périodiquement.

Pièges courants et comment les éviter

Plusieurs erreurs compromettent l'automatisation des évictions. Voici les plus courantes et comment les prévenir ou s'en remettre.

Piège 1 : Coder en dur les seuils sans comprendre les modèles de charge de travail

De nombreuses équipes copient les seuils d'éviction à partir d'articles de blog sans analyser leurs propres tailles de nœuds et l'utilisation de la mémoire/du disque de leur charge de travail. Cela conduit soit à des évictions prématurées, soit à des plantages de nœuds.

Comment éviter : Établissez une base de référence de l'utilisation des ressources de vos nœuds sur au moins deux semaines, y compris les pics et les heures creuses. Utilisez les données de surveillance pour définir des seuils qui permettent des fluctuations normales.

Piège 2 : Ne pas tenir compte du système de fichiers d'images (imagefs) séparément

Kubernetes peut avoir des systèmes de fichiers distincts pour les images de conteneurs et les couches inscriptibles des conteneurs. Si vous ne configurez que les seuils nodefs mais pas imagefs, le kubelet peut ne pas évincer les pods lorsque le système de fichiers d'images se remplit, entraînant des échecs d'extraction d'images.

Comment éviter : Vérifiez le pilote de stockage de votre runtime de conteneurs et définissez des seuils nodefs et imagefs appropriés. Utilisez df -h sur les nœuds pour identifier les points de montage.

Piège 3 : Ignorer les périodes de grâce de l'éviction douce

L'éviction douce permet aux pods de se terminer proprement pendant une période de grâce. Sauter l'éviction douce signifie que les pods sont tués immédiatement, perdant potentiellement des requêtes en cours.

Comment éviter : Définissez des seuils d'éviction douce légèrement au-dessus des seuils durs, et définissez des périodes de grâce assez longues pour que vos applications drainent les connexions (généralement 1 à 5 minutes).

Piège 4 : Automatiser la réponse sans approbation humaine pour les modifications critiques

Une remédiation entièrement automatisée peut aggraver une mauvaise situation si l'automatisation interprète mal les métriques et évince trop de pods. Par exemple, un auto-scaler qui supprime des nœuds pendant un pic de mémoire pourrait déclencher des évictions en cascade.

Comment éviter : Implémentez une étape d'approbation humaine pour les actions qui drainent les nœuds ou modifient la configuration du kubelet en production. Utilisez un outil de chat-ops où un ingénieur tape une commande pour approuver.

Piège 5 : Ne pas tester votre pipeline CI/CD lui-même

Des pipelines jamais testés peuvent échouer silencieusement ou ne pas s'exécuter du tout. Un pipeline cassé donne une fausse confiance.

Comment éviter : Planifiez des exécutions régulières de pipeline (par exemple, nocturnes) qui exécutent un sous-ensemble de vérifications contre un cluster de préproduction. Surveillez les taux de réussite du pipeline et alertez en cas d'échec.

Conclusion

Automatiser les flux de travail d'éviction sous pression des nœuds Kubernetes avec CI/CD transforme un processus réactif et stressant en un processus contrôlé et reproductible. En commençant par un inventaire approfondi de l'environnement, en implémentant des modifications de configuration sûres, en vérifiant avec des commandes concrètes et en planifiant les défaillances, vous pouvez garder vos clusters stables même sous pression de ressources.

La clé est d'observer avant de modifier, de limiter le rayon d'impact et de toujours vérifier les résultats. Utilisez la liste de contrôle opérationnelle pour attribuer les responsabilités et assurer une révision continue. Évitez les pièges courants comme coder en dur les seuils sans établir de base de référence, ignorer l'éviction douce ou automatiser sans garde-fous.

Comme prochaine étape, choisissez une vérification à faible risque de ce guide, par exemple vérifier les conditions de pression des nœuds avec une commande à colonnes personnalisées, enregistrez l'état actuel, exécutez la vérification et comparez le résultat avec la sortie attendue. Ensuite, intégrez progressivement plus d'automatisation dans votre pipeline, en gardant toujours la récupération à l'esprit.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision.