Surveillance et alertes d'éviction sous pression des nœuds Kubernetes : guide pratique

Introduction

Les nœuds Kubernetes peuvent subir une pression sur les ressources lorsque les pods consomment plus de CPU, de mémoire ou de disque que le nœud ne peut en fournir. Dans ce cas, le kubelet peut évincer des pods pour récupérer des ressources et maintenir la stabilité du nœud. L'éviction sous pression des nœuds est un mécanisme essentiel pour préserver la santé du cluster, mais elle peut aussi entraîner des interruptions de service inattendues si elle n'est pas correctement surveillée.

Ce guide porte sur la surveillance et les alertes liées à l'éviction sous pression des nœuds. Nous aborderons les métriques clés à surveiller, la configuration d'alertes qui se déclenchent avant les évictions, les signaux de journaux indiquant une pression imminente, des exemples de tableaux de bord et des flux de travail de réponse aux incidents. À la fin, vous disposerez d'une configuration de surveillance pratique qui vous aidera à détecter et à répondre à la pression sur les ressources avant qu'elle n'impacte vos charges de travail.

Inventaire des versions et de l'environnement

Avant de mettre en place la surveillance, établissez les versions et la topologie de votre cluster. Le comportement d'éviction du kubelet peut varier selon les versions de Kubernetes ; il est donc important de connaître votre environnement.

Prérequis :

• Un cluster Kubernetes en cours d'exécution (version 1.20 ou ultérieure recommandée pour des fonctionnalités d'éviction stables).
• L'outil en ligne de commande kubectl configuré pour accéder au cluster.
• Une pile de surveillance capable de collecter les métriques du kubelet et de l'API Kubernetes. Prometheus est couramment utilisé, mais d'autres systèmes comme Datadog ou Grafana Cloud peuvent également fonctionner.
• Accès aux journaux des nœuds, généralement via journalctl ou un système d'agrégation de journaux.

Considérations de topologie :

• Identifiez les nœuds les plus susceptibles de subir une pression (par exemple, les nœuds avec une forte densité de pods ou des ressources limitées).
• Déterminez si vous utilisez l'auto-scaling des nœuds ; le cas échéant, les seuils d'éviction peuvent interagir avec les décisions de mise à l'échelle.

Exécutez la commande suivante pour obtenir la version de Kubernetes :

kubectl version --short

Sortie attendue (exemple) :

Client Version: v1.25.0
Server Version: v1.25.0

Pour la capacité en ressources des nœuds, utilisez :

kubectl describe nodes | grep -A 5 "Capacity:"

Exemple de sortie :

Capacity:
  cpu:                4
  ephemeral-storage:  100Gi
  memory:             16Gi
  pods:               110

Cet inventaire vous aidera à définir les seuils de vos alertes. Par exemple, si vos nœuds disposent de 16 Gio de mémoire, vous pouvez définir une alerte d'avertissement lorsque la mémoire disponible tombe en dessous de 2 Gio.

Chemin de configuration sûr

Lors de la surveillance de l'éviction sous pression des nœuds, vous devez collecter les bonnes métriques et configurer des alertes basées sur celles-ci. Le kubelet expose les métriques liées à l'éviction sur son endpoint /metrics, généralement collecté par Prometheus.

Métriques clés à surveiller :

• kubelet_evictions : compteur d'évictions par raison (par exemple, mémoire, disque). C'est le signal principal qu'une éviction a eu lieu.
• node_memory_MemAvailable_bytes : mémoire disponible sur le nœud, utile pour prédire la pression mémoire.
• node_filesystem_avail_bytes : espace de système de fichiers disponible, pour la pression disque.
• kube_node_status_condition : condition du nœud, y compris MemoryPressure, DiskPressure et PIDPressure. Cette métrique possède des libellés pour la condition et le statut.

Exemple de règles d'alerte : Voici des règles d'alerte Prometheus d'exemple. Ajustez les seuils en fonction de la capacité de vos nœuds et des modèles de charge de travail.

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"
  - alert: NodeDiskPressure
    expr: kube_node_status_condition{condition="DiskPressure",status="true"} == 1
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Node {{ $labels.node }} is under disk pressure"
  - alert: HighEvictionRate
    expr: increase(kubelet_evictions[1h]) > 3
    labels:
      severity: critical
    annotations:
      summary: "High eviction rate on node {{ $labels.node }}"

Important : La métrique kube_node_status_condition rapporte la condition du nœud sous forme de série temporelle avec la valeur 1 lorsque la condition est vraie. Elle est fiable pour alerter sur les conditions de pression. Cependant, certains clusters peuvent ne pas exposer cette métrique si le service kube-state-metrics n'est pas installé. Assurez-vous que kube-state-metrics est déployé.

Implémentation ciblée : Commencez avec un seul nœud ou un petit ensemble de nœuds pour valider vos métriques et alertes. Testez les règles d'alerte dans un environnement de préproduction si possible. Cela suit le principe selon lequel un pilote restreint est plus facile à inspecter et à ajuster localement.

En outre, envisagez de créer une alerte préemptive basée sur la mémoire disponible pour détecter la pression avant que la condition du nœud ne passe à vrai. Par exemple :

- alert: NodeMemoryLow
  expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.10
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Node {{ $labels.node }} has less than 10% memory available"

Cette alerte peut vous avertir plus tôt que d'attendre que le kubelet définisse la condition MemoryPressure.

Vérification et diagnostics

Une fois la collecte des métriques et les alertes configurées, vérifiez que tout fonctionne comme prévu. Cela implique de contrôler que les métriques sont bien collectées, que les alertes se déclenchent lorsque les conditions sont remplies et que vous pouvez diagnostiquer les problèmes à partir des journaux.

Vérifier la collecte des métriques : Vérifiez si Prometheus collecte les métriques du kubelet en interrogeant une métrique connue :

kubelet_evictions

Si aucune donnée n'apparaît, vérifiez la page des cibles de Prometheus pour vous assurer que les endpoints du kubelet sont accessibles.

Simuler une pression mémoire (pour les tests uniquement) : Pour tester vos alertes, vous pouvez créer temporairement un pod qui consomme une grande quantité de mémoire. Exemple :

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

Appliquez ce pod et observez si la condition du nœud passe à MemoryPressure et si votre alerte se déclenche. Soyez prudent et supprimez le pod immédiatement après le test avec kubectl delete pod memory-hog.

Commandes de diagnostic :

• Vérifier les conditions des nœuds :

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

Sortie attendue (exemple) :

NAME       MemoryPressure   DiskPressure
node-1     False            False
node-2     True             False

• Voir les événements d'éviction :

kubectl get events --all-namespaces | grep Evicted

• Inspecter les journaux du kubelet pour les décisions d'éviction :

journalctl -u kubelet | grep -i evict

Recherchez des messages comme « evicting pod » ou « pressure eviction » pour comprendre la cause.

Exemple de tableau de bord : Un tableau de bord Grafana peut visualiser les métriques d'éviction. Panneaux clés :

• Taux d'éviction dans le temps (en utilisant rate(kubelet_evictions[5m])).
• Utilisation de la mémoire du nœud par rapport au seuil d'éviction.
• Statut des conditions des nœuds.
• Nombre de pods en état Evicted.

Ce tableau de bord aide à identifier rapidement les tendances et les problèmes potentiels.

Modes de défaillance et récupération

La surveillance elle-même peut échouer, et les évictions peuvent avoir des conséquences imprévues. Il est important de comprendre les modes de défaillance potentiels et comment récupérer.

Modes de défaillance de la surveillance :

• Prometheus ne collecte pas les métriques du kubelet en raison de problèmes de réseau ou d'authentification. Corrigez en vérifiant la découverte de services et les permissions RBAC.
• Règles d'alerte mal configurées (par exemple, noms de métriques incorrects). Validez les règles avec promtool check rules.
• Alertmanager ne route pas les alertes. Testez les canaux de notification.

Modes de défaillance liés aux évictions :

• Des seuils d'éviction agressifs peuvent provoquer un churn de pods. Examinez les paramètres d'éviction du kubelet (--eviction-hard, --eviction-soft).
• Les pods évincés peuvent ne pas être replanifiés si les ressources sont toujours limitées, entraînant une interruption de service. Mettez en place des budgets de disruption de pods pour protéger les charges de travail critiques.
• La pression disque peut être causée par les journaux de conteneurs ou le stockage éphémère. Assurez-vous que la rotation des journaux est configurée.

Étapes de récupération :

• Identifiez la cause de la pression (mémoire, disque, PID).
• Si mémoire : cherchez des fuites de mémoire, ajustez les limites des pods ou réduisez l'échelle.
• Si disque : nettoyez les images ou journaux inutilisés, augmentez le stockage du nœud.
• Si PID : ajustez pidLimit ou identifiez les processus qui fuient des PID.

Retour en arrière des modifications de surveillance : Si une modification de configuration de surveillance cause des problèmes, revenez à la version précédente. Conservez la configuration dans un système de contrôle de version pour faciliter le retour en arrière. Pour les règles d'alerte, documentez les seuils de référence.

Liste de contrôle opérationnelle

Utilisez la liste de contrôle suivante pour les opérations courantes et les examens périodiques :

• Vérifiez que les métriques du kubelet sont collectées en continu.
• Revoyez les seuils d'alerte trimestriellement pour les aligner sur les changements de charge de travail.
• Testez les notifications d'alerte mensuellement pour vous assurer qu'elles parviennent aux bons canaux.
• Surveillez les tendances du taux d'éviction ; une augmentation soudaine peut indiquer des problèmes de capacité.
• Assurez-vous que les conditions des nœuds (MemoryPressure, DiskPressure, PIDPressure) sont vérifiées régulièrement.
• Maintenez kube-state-metrics et Prometheus à jour.
• Documentez les procédures de réponse aux incidents pour les événements d'éviction.
• Examinez les demandes et limites de ressources des pods pour éviter la surallocation.
• Vérifiez l'utilisation du disque sur les nœuds et nettoyez si nécessaire.
• Revoyez la configuration d'éviction du kubelet après les mises à niveau du cluster.

Cette liste de contrôle garantit que la surveillance reste efficace et que l'équipe est préparée aux événements d'éviction.

Conclusion

La surveillance de l'éviction sous pression des nœuds Kubernetes est essentielle pour maintenir la stabilité du cluster et la disponibilité des applications. En collectant les métriques clés, en configurant des alertes proactives et en disposant d'un plan de réponse aux incidents clair, vous pouvez prévenir de nombreuses interruptions liées aux évictions.

Nous avons couvert l'inventaire des versions et de l'environnement, la configuration sûre de la surveillance, les méthodes de vérification, les modes de défaillance et une liste de contrôle opérationnelle. Les prochaines étapes consistent à mettre en œuvre ces pratiques dans votre environnement, en commençant par un petit pilote, puis à itérer en fonction du comportement observé.

N'oubliez pas d'aligner votre surveillance sur la capacité de votre cluster et les modèles de charge de travail. Révisez et mettez à jour régulièrement vos seuils d'alerte et vos procédures pour garantir leur efficacité. Avec ces mesures, vous serez bien équipé pour gérer la pression sur les ressources et minimiser l'impact des évictions.