E-NO
Kubernetes 8 min de lecture

Gestion de la mémoire d'échange Kubernetes : surveillance, métriques, alertes et récupération

calendar_today Publié : 2026-08-25
update Dernière mise à jour : 2026-08-25
analytics Efficacité SEO : 100%
Illustration du guide technique pour « Gestion de la mémoire d'échange Kubernetes : surveillance, métriques, alertes et récupération ».

Introduction

Les clusters Kubernetes désactivent souvent le swap sur les nœuds, mais certains environnements l'activent pour le développement, les déploiements en périphérie ou lorsque les politiques locales l'exigent. Que le swap soit activé ou désactivé, une gestion efficace de la mémoire d'échange nécessite une surveillance, des alertes, des tableaux de bord et des procédures de réponse aux incidents fondés sur des signaux concrets plutôt que sur des suppositions.

Ce guide fournit des instructions pratiques et orientées opérateur pour la gestion de la mémoire d'échange Kubernetes. Il couvre l'inventaire des versions et de l'environnement, les modifications de configuration sécurisées, la vérification et le diagnostic, les modes de défaillance et la récupération, ainsi qu'une liste de contrôle opérationnelle. Chaque section comprend des commandes réelles, les sorties attendues et les signaux de défaillance. Le public cible comprend les développeurs, les consultants DevOps et les équipes techniques de startups gérant des clusters Kubernetes auto-hébergés ou cloud.

La philosophie opérationnelle est la sécurité dès la conception : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier les résultats et documenter les chemins de récupération avant qu'un incident ne force une décision.

Inventaire des versions et de l'environnement

Avant toute modification de configuration, documentez les composants Kubernetes impliqués, leurs plages de versions prises en charge, les prérequis, une approche d'observation en lecture seule, la plus petite modification justifiée et la commande ou le signal qui vérifie le résultat. Pour la gestion de la mémoire d'échange, les principaux composants sont la kubelet, le système d'exploitation du nœud, le moteur d'exécution de conteneurs, et éventuellement les unités systemd ou les scripts cloud-init.

Séparez l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification et le matériel privé, puis modifiez un seul élément ciblé uniquement lorsque son rayon d'impact et son chemin de récupération sont compris.

Les concepts clés de cette section recoupent la surveillance Kubernetes, les alertes, les métriques, les tableaux de bord et la réponse aux incidents. Des domaines tels que Node, Kubelet et Resource Requests and Limits ne sont inclus que lorsqu'ils affectent directement le comportement du swap ou le dépannage.

Commandes pratiques d'inventaire

Commencez par des commandes en lecture seule pour établir la base de référence :

# Version de Kubernetes
kubectl version --short

# Liste des nœuds avec la version de kubelet
kubectl get nodes -o wide

# Informations détaillées sur le nœud, y compris la version de kubelet et l'image du système d'exploitation
kubectl describe node <node-name>

Exemple de sortie attendue pour kubectl get nodes -o wide :

NAME           STATUS   ROLES           AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
node-1         Ready    control-plane   10d   v1.28.5   10.0.0.10      <none>        Ubuntu 22.04.3 LTS   5.15.0-91-generic   containerd://1.7.13
node-2         Ready    <none>          10d   v1.28.5   10.0.0.20      <none>        Ubuntu 22.04.3 LTS   5.15.0-91-generic   containerd://1.7.13

Vérifiez l'état du swap sur chaque nœud via SSH ou un pod de débogage :

# Sur le nœud
swapon --show
free -h
cat /proc/swaps

Si le swap est actif, vous verrez une sortie similaire à :

NAME      TYPE      SIZE   USED PRIO
/dev/sda3 partition 4G     0B   -2

Pour la configuration de la kubelet, inspectez les drapeaux actifs :

# Sur le nœud
ps aux | grep kubelet
# Ou inspectez le fichier de configuration
cat /var/lib/kubelet/config.yaml | grep -i swap

Dans Kubernetes 1.28 avec la fonctionnalité NodeSwap activée, une configuration kubelet typique comprend :

memorySwap:
  swapBehavior: LimitedSwap

Si swapBehavior est vide, la valeur par défaut est NoSwap, ce qui signifie que la kubelet échouera si le swap est détecté, à moins que --fail-swap-on=false ne soit défini.

Matrice des versions et des fonctionnalités

Utilisez la référence concrète suivante pour les versions courantes de Kubernetes :

Version de KubernetesFonctionnalité NodeSwapComportement de swap par défautAction recommandée
1.22 et antérieuresDésactivéeLa kubelet échoue si le swap est activé, sauf si --fail-swap-on=falseGarder le swap désactivé en production
1.22 - 1.27Alpha (désactivée par défaut)Identique à ci-dessusActiver uniquement pour les tests avec une fonctionnalité explicite
1.28 et ultérieuresBêta (activée par défaut)La kubelet tolère le swap si memorySwap.swapBehavior est définiDéfinir LimitedSwap pour une utilisation contrôlée
1.30 et ultérieuresStable (activée par défaut)Par défaut NoSwap, configurable en LimitedSwapUtiliser LimitedSwap pour une capacité de pointe si nécessaire

Vérifiez toujours votre version exacte en exécutant kubectl version et en lisant les notes de version.

Question rapide 1 sur 2

Quel est le comportement de swap par défaut pour les nœuds Kubernetes ?

La documentation indique que NoSwap est le comportement de swap par défaut.

Chemin de configuration sécurisé

La modification des paramètres de swap sur un nœud peut perturber les pods en cours d'exécution si elle n'est pas effectuée correctement. Suivez toujours un chemin de configuration sécurisé : identifiez le composant, la version prise en charge, les prérequis, l'observation en lecture seule, la plus petite modification justifiée et la commande de vérification.

Prérequis

  • Accès au nœud (SSH ou pod privilégié) avec les droits sudo.
  • Sauvegarde de la configuration actuelle de la kubelet et de l'état du système.
  • Une fenêtre de maintenance ou la possibilité de cordonner et drainer le nœud.
  • Connaissance du rôle du nœud et de la sensibilité de la charge de travail.

Observation en lecture seule avant modification

Avant de modifier le swap, enregistrez l'état actuel :

# Cordonner et drainer le nœud (si possible dans un environnement de test)
kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

# Sauvegarder la configuration de la kubelet
sudo cp /var/lib/kubelet/config.yaml /var/lib/kubelet/config.yaml.bak

# Vérifier l'utilisation actuelle du swap
free -h
swapon --show

Plus petite modification justifiée : activation du swap sur un nœud

Supposons que vous deviez activer un fichier d'échange de 2 Go sur un nœud Ubuntu pour une prise en charge limitée du swap dans Kubernetes 1.28.

Étapes :

  1. Créez un fichier d'échange :
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
  1. Rendez-le persistant (facultatif, mais recommandé pour les environnements contrôlés) :
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
  1. Configurez la kubelet pour utiliser LimitedSwap :

Modifiez /var/lib/kubelet/config.yaml et ajoutez :

memorySwap:
  swapBehavior: LimitedSwap
  1. Redémarrez la kubelet :
sudo systemctl restart kubelet
  1. Vérifiez que la kubelet fonctionne et que le swap est reconnu :
sudo systemctl status kubelet
kubectl describe node <node-name> | grep -A5 "Conditions"

La sortie attendue doit montrer la condition MemoryPressure comme False dans un premier temps.

Plus petite modification justifiée : désactivation du swap pour conformité

Si vous devez désactiver le swap de manière permanente :

sudo swapoff -a
# Supprimer l'entrée de swap de /etc/fstab
sudo sed -i '/swap/d' /etc/fstab
sudo systemctl restart kubelet

Vérifiez ensuite avec swapon --show (ne devrait rien afficher) et kubectl get nodes pour confirmer que le nœud est Ready.

Vérification et diagnostics

Après toute modification de configuration, vérifiez que le système se comporte comme prévu. Utilisez d'abord des diagnostics en lecture seule, puis procédez à des tests spécifiques.

Surveillance de l'utilisation du swap sur un nœud

Utilisez kubectl top si metrics-server est installé, mais pour les données spécifiques au swap, utilisez des commandes au niveau du nœud ou l'exportateur de nœud Prometheus.

Si vous avez un pod de débogage privilégié, exécutez :

kubectl debug node/<node-name> -it --image=ubuntu -- /bin/bash
# À l'intérieur du pod de débogage
chroot /host
swapon --show
free -h
cat /proc/meminfo | grep -i swap

Sortie attendue pour un nœud sain avec swap :

SwapTotal:        2097148 kB
SwapFree:         2097148 kB

Métriques Prometheus pour le swap

Si vous utilisez Prometheus avec node_exporter, interrogez ces métriques :

  • node_memory_SwapTotal_bytes
  • node_memory_SwapFree_bytes
  • node_memory_SwapCached_bytes
  • node_vmstat_pswpin
  • node_vmstat_pswpout

Exemple de PromQL pour le pourcentage d'utilisation du swap :

(node_memory_SwapTotal_bytes - node_memory_SwapFree_bytes) / node_memory_SwapTotal_bytes * 100

Pour les métriques de swap spécifiques à la kubelet (Kubernetes 1.28+), utilisez le point de terminaison des métriques de la kubelet :

curl -s http://localhost:10255/metrics | grep swap

(Remarque : le port en lecture seule de la kubelet peut être désactivé ; utilisez --kubelet-insecure-tls si nécessaire.)

Diagnostics au niveau du pod

Vérifiez si un pod est affecté par la pression mémoire :

kubectl describe pod <pod-name>

Recherchez des événements tels que :

Warning  Evicted    10m   kubelet  The node was low on resource: memory.

Si le swap est actif et swapBehavior: LimitedSwap, les pods peuvent utiliser le swap jusqu'à la limite. Surveillez l'utilisation de la mémoire des pods avec :

kubectl top pod <pod-name>

Exemple :

NAME        CPU(cores)   MEMORY(bytes)
pod-name    100m         512Mi

Si la mémoire dépasse les demandes et les limites, le pod peut être limité ou tué. Examinez la classe QoS et les limites du pod :

kubectl get pod <pod-name> -o yaml | grep -A5 resources

Question rapide 2 sur 2

Selon l'article, quelle version de Kubernetes a la feature gate NodeSwap stable (activée par défaut) ?

Le tableau des versions de l'article montre que pour 1.30 et versions ultérieures, la feature gate NodeSwap est stable (activée par défaut).

Modes de défaillance et récupération

Même avec une planification minutieuse, des défaillances surviennent. Voici les modes de défaillance courants liés à la gestion du swap, leurs symptômes et les étapes de récupération.

Mode de défaillance 1 : La kubelet ne démarre pas lorsque le swap est activé et que NoSwap est la valeur par défaut

Symptôme : Le nœud devient NotReady et les journaux de la kubelet affichent :

F0128 10:00:00.000000   12345 server.go:275] failed to run Kubelet: running with swap on is not supported, please disable swap! or set --fail-swap-on=false

Récupération :

Option A : Désactiver immédiatement le swap :

sudo swapoff -a
sudo systemctl restart kubelet

Option B : Configurer la kubelet pour autoriser le swap (développement uniquement) :

Modifiez /var/lib/kubelet/config.yaml :

failSwapOn: false

Ou ajoutez --fail-swap-on=false à la ligne de commande de la kubelet.

Redémarrez ensuite la kubelet.

Mode de défaillance 2 : Les pods sont évincés malgré la disponibilité du swap

Symptôme : kubectl get pods affiche des pods dans l'état Evicted et les journaux du nœud indiquent une pression mémoire.

Cause racine : Avec LimitedSwap, la kubelet applique toujours les limites de mémoire. Le swap n'affecte que le seuil de pression mémoire au niveau du nœud, pas les limites des pods. Ainsi, un pod dépassant sa limite est tué quel que soit le swap.

Récupération :

  • Augmentez la limite de mémoire du pod si possible : kubectl set resources deployment/<name> --limits=memory=1Gi
  • Réduisez l'utilisation de la mémoire dans l'application.
  • Vérifiez la pression mémoire du nœud : kubectl describe node <node-name> | grep -A5 Conditions

Mode de défaillance 3 : Le fichier d'échange se remplit et le nœud devient insensible

Symptôme : Utilisation élevée du swap, nœud lent et node_memory_SwapFree_bytes approche de zéro.

Récupération :

  • Identifiez les gros consommateurs de swap à l'aide de smem ou top trié par swap :
sudo smem -s swap -r
  • Ajoutez temporairement plus de swap si l'espace disque le permet :
sudo fallocate -l 2G /swapfile2
sudo chmod 600 /swapfile2
sudo mkswap /swapfile2
sudo swapon /swapfile2
  • Redémarrez les pods problématiques ou migrez les charges de travail.
  • Configurez une alerte pour détecter une utilisation élevée du swap avant qu'elle ne devienne critique (voir la liste de contrôle opérationnelle).

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle quotidienne/hebdomadaire pour maintenir la santé de la mémoire d'échange.

Contrôles quotidiens

  • [ ] Exécutez kubectl get nodes et assurez-vous que tous les nœuds sont Ready.
  • [ ] Vérifiez les conditions de pression mémoire des nœuds :
  kubectl get nodes -o custom-columns='NAME:.metadata.name,MemoryPressure:.status.conditions[?(@.type=="MemoryPressure")].status'

Sortie attendue : False pour tous les nœuds.

  • [ ] Examinez l'utilisation du swap sur les nœuds via un tableau de bord de surveillance ou une commande :
  kubectl debug node/<node-name> -it --image=ubuntu -- chroot /host swapon --show

Contrôles hebdomadaires

  • [ ] Vérifiez que la configuration de la kubelet est cohérente sur tous les nœuds :
  kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.kubeletVersion}'
  • [ ] Auditez toute modification récente des drapeaux de la kubelet ou des paramètres de swap.
  • [ ] Testez les règles d'alerte en déclenchant une alerte de test (par exemple, définissez temporairement un seuil bas dans un environnement de test).
  • [ ] Examinez les événements d'éviction des pods :
  kubectl get events --all-namespaces | grep -i evicted

Exemples de règles d'alerte (Prometheus)

Créez une alerte pour une utilisation élevée du swap sur un nœud :

groups:
- name: swap_alerts
  rules:
  - alert: NodeSwapUsageHigh
    expr: (node_memory_SwapTotal_bytes - node_memory_SwapFree_bytes) / node_memory_SwapTotal_bytes > 0.8
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Utilisation du swap supérieure à 80 % sur {{ $labels.instance }}"
      description: "L'utilisation du swap a dépassé 80 % pendant 5 minutes."
  - alert: NodeSwapUsageCritical
    expr: (node_memory_SwapTotal_bytes - node_memory_SwapFree_bytes) / node_memory_SwapTotal_bytes > 0.95
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Utilisation du swap supérieure à 95 % sur {{ $labels.instance }}"

Pour les métriques de la kubelet (si disponibles), alertez sur kubelet_swap_usage_bytes dépassant un seuil.

Recommandations de tableau de bord

Construisez un tableau de bord Grafana avec des panneaux pour :

  • Pourcentage d'utilisation du swap par nœud (série chronologique).
  • Taux d'entrée/sortie du swap par nœud (node_vmstat_pswpin, node_vmstat_pswpout).
  • Condition de pression mémoire du nœud.
  • Nombre d'évictions de pods par espace de noms.

Exemple de requête de panneau pour l'utilisation du swap :

100 * (1 - (node_memory_SwapFree_bytes / node_memory_SwapTotal_bytes))

Définissez des seuils à 50 % (jaune), 80 % (orange), 95 % (rouge).

Conclusion

La gestion de la mémoire d'échange Kubernetes est souvent négligée jusqu'à ce qu'elle provoque une instabilité des nœuds ou des évictions de pods. En suivant l'approche structurée de ce guide, vous pouvez surveiller proactivement le swap, le configurer en toute sécurité, détecter les défaillances rapidement et récupérer rapidement.

Comme prochaine étape, choisissez une vérification à faible risque de cet article, comme la vérification de l'état du swap sur un nœud, et enregistrez l'état actuel. Exécutez ensuite la commande documentée et comparez la sortie avec le signal attendu. Implémentez progressivement les règles d'alerte et les panneaux de tableau de bord pour construire une pile complète d'observabilité de la mémoire d'échange.

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. Avec ces pratiques, vous pouvez gérer la mémoire d'échange dans Kubernetes en toute confiance.

Recherches connexes

Score de qualité de l’article

Utilité pour le lecteur 100%
  • check_circle Guide prêt à lire
  • check_circle Exemples pratiques inclus
  • check_circle URL d’article optimisée pour le SEO