## 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 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 Ubuntu 22.04.3 LTS 5.15.0-91-generic containerd://1.7.13 node-2 Ready 10d v1.28.5 10.0.0.20 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 ? - NoSwap - LimitedSwap - UnlimitedSwap - SwapEnabled
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 kubectl drain --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 : - Créez un fichier d'échange : sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile - Rendez-le persistant (facultatif, mais recommandé pour les environnements contrôlés) : echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab - Configurez la kubelet pour utiliser LimitedSwap : Modifiez /var/lib/kubelet/config.yaml et ajoutez : memorySwap: swapBehavior: LimitedSwap - Redémarrez la kubelet : sudo systemctl restart kubelet - Vérifiez que la kubelet fonctionne et que le swap est reconnu : sudo systemctl status kubelet kubectl describe node | 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/ -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 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 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 -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) ? - 1.22 et versions antérieures - 1.22 - 1.27 - 1.28 et versions ultérieures - 1.30 et versions ultérieures
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/ --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 | 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/ -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.