Gestion de la mémoire d'échange Kubernetes : guide de sauvegarde, restauration et reprise après sinistre

Introduction

Kubernetes a longtemps déconseillé l'utilisation du swap sur les nœuds, mais les versions plus récentes le prennent en charge avec une configuration soignée pour des charges de travail spécifiques. Gérer efficacement la mémoire d'échange nécessite une stratégie claire de sauvegarde et de restauration pour protéger la configuration des nœuds, l'état des charges de travail et la stabilité du cluster. Ce guide fournit des méthodes pratiques, étape par étape, pour sauvegarder, restaurer et valider les configurations de mémoire d'échange Kubernetes, permettant aux opérateurs de récupérer rapidement après des erreurs de configuration ou des pannes.

Nous couvrons l'ensemble du cycle de vie opérationnel : inventorier votre environnement, appliquer des modifications de configuration en toute sécurité, vérifier les résultats, gérer les modes de défaillance et suivre une liste de contrôle opérationnelle. Chaque section comprend des commandes concrètes, des sorties attendues et des décisions de récupération adaptées aux développeurs, ingénieurs DevOps et équipes techniques de startups qui ont besoin de procédures fiables et reproductibles.

Inventaire de la version et de l'environnement

Avant de modifier les paramètres de swap, établissez une référence précise. Identifiez votre version de Kubernetes, le système d'exploitation du nœud, la configuration du kubelet et l'état actuel du swap. Cet inventaire évite les modifications accidentelles sur les nœuds de production et garantit que chaque étape ultérieure est compatible avec la version.

Observation en lecture seule d'abord

Exécutez les commandes suivantes pour capturer l'état actuel sans rien modifier :

# Version de Kubernetes
kubectl version --short

# Statut et détails des nœuds
kubectl get nodes -o wide

# Version du kubelet sur un nœud spécifique (remplacez NODE_NAME)
kubectl get node NODE_NAME -o jsonpath='{.status.nodeInfo.kubeletVersion}{"\n"}'

# Vérifier l'utilisation du swap sur le nœud (nécessite un accès SSH ou au nœud)
ssh NODE_NAME 'free -h && swapon --show'

La sortie attendue inclut la version du serveur Kubernetes, la liste des nœuds avec leurs rôles et statuts, la version du kubelet et un résumé du swap. Si swapon --show ne renvoie rien, le swap est désactivé. S'il renvoie un chemin comme /swapfile, le swap est actif.

Documenter les détails de l'environnement

Créez un fichier d'inventaire avec des valeurs concrètes. Exemple :

Version du cluster : v1.28.5
Système d'exploitation du nœud : Ubuntu 22.04 LTS
Version du kubelet : v1.28.5
Statut du swap : activé, fichier d'échange de 2 Go à /swapfile
Pilote cgroup : systemd
Runtime de conteneurs : containerd 1.7.11

Vérifier la configuration du swap du kubelet

Le comportement du swap du kubelet est contrôlé par les champs failSwapOn ou memorySwap dans sa configuration. Récupérez le paramètre actuel :

ssh NODE_NAME 'cat /var/lib/kubelet/config.yaml | grep -A5 swap'

La sortie attendue peut montrer :

memorySwap:
  swapBehavior: LimitedSwap
failSwapOn: false

Si ces champs sont absents, le kubelet utilise les valeurs par défaut (swap désactivé). Notez cela dans votre inventaire.

Vérifier la pression sur le nœud et les demandes de ressources

Comprenez comment le swap interagit avec la gestion des ressources. Vérifiez les demandes et limites de ressources actuelles sur un nœud :

kubectl describe node NODE_NAME | grep -A10 "Allocated resources"

Cela montre les allocations de CPU, mémoire et stockage éphémère. Notez si les demandes de mémoire approchent de la capacité, car le swap peut fournir un dépassement sous le comportement LimitedSwap.

Limiter le rayon d'impact

Faites les modifications un nœud à la fois, idéalement dans un cluster de préproduction d'abord. Toujours cordonner et drainer un nœud avant de modifier sa configuration de swap :

kubectl cordon NODE_NAME
kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data

Après les modifications, décordonner :

kubectl uncordon NODE_NAME

Chemin de configuration sécurisé

Configurer le swap en toute sécurité nécessite de comprendre les options de comportement du swap du kubelet et d'appliquer les modifications via des fichiers versionnés, pas des éditions ad hoc.

Comprendre les modes de comportement du swap

Le kubelet offre trois comportements de swap (à partir de Kubernetes 1.28 avec la fonctionnalité NodeSwap activée et cgroup v2) :

NoSwap : par défaut, le swap est désactivé.
LimitedSwap : le swap est autorisé mais le kubelet limite son utilisation en fonction de la pression mémoire du nœud et des classes QoS des pods. Seuls les pods avec une QoS Burstable ou BestEffort peuvent utiliser le swap ; les pods Guaranteed ne le peuvent pas.
UnlimitedSwap : le swap est autorisé sans restrictions du kubelet (non recommandé en production).

Choisissez LimitedSwap pour la plupart des charges de travail afin d'équilibrer performances et sécurité.

Activer le swap sur le nœud

En supposant que le fichier d'échange existe (sinon, créez-en un) :

# Créer un fichier d'échange de 2 Go (si aucun)
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Rendre le swap permanent en l'ajoutant à /etc/fstab
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Mettre à jour la configuration du kubelet

Modifiez /var/lib/kubelet/config.yaml sur le nœud cible. Ajoutez ou modifiez la section memorySwap :

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memorySwap:
  swapBehavior: LimitedSwap
failSwapOn: false

Définissez failSwapOn: false pour empêcher le kubelet d'échouer si le swap est activé.

Redémarrer le kubelet

sudo systemctl restart kubelet
sudo systemctl status kubelet

Vérifiez que le kubelet est actif et qu'aucune erreur n'apparaît.

Vérifier que le swap est reconnu par le kubelet

Consultez les journaux du kubelet pour les messages liés au swap :

sudo journalctl -u kubelet -n 50 --no-pager | grep -i swap

La sortie attendue peut inclure :

I0214 10:00:00.123456   12345 kubelet.go:200] "Swap is enabled" swapBehavior="LimitedSwap"

Tester avec un pod d'exemple

Déployez un pod Burstable qui demande moins que sa limite, lui permettant d'utiliser le swap si nécessaire :

apiVersion: v1
kind: Pod
metadata:
  name: swap-test
spec:
  containers:
  - name: stress
    image: polinux/stress
    resources:
      requests:
        memory: "100Mi"
      limits:
        memory: "200Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

Appliquez-le :

kubectl apply -f swap-test.yaml
kubectl get pod swap-test

Vérifiez que le pod est en cours d'exécution. Ensuite, inspectez son utilisation mémoire sur le nœud :

ssh NODE_NAME 'watch -n1 free -h'

Vous pouvez voir l'utilisation du swap augmenter si le pod dépasse sa demande de mémoire. Cela valide le fonctionnement de LimitedSwap.

Plan de retour en arrière

Si la configuration cause des problèmes, revenez en arrière en définissant swapBehavior sur NoSwap et failSwapOn: true, puis redémarrez le kubelet. Conservez une sauvegarde du fichier de configuration d'origine :

sudo cp /var/lib/kubelet/config.yaml /var/lib/kubelet/config.yaml.bak

Vérification et diagnostics

Après les modifications de configuration, une vérification approfondie évite les défaillances silencieuses. Utilisez une approche systématique pour confirmer que le swap fonctionne comme prévu et que les pods se comportent correctement.

Vérifier les métriques de swap du kubelet

Le kubelet expose des métriques liées au swap sur son endpoint de métriques. Accédez-y via curl sur le nœud :

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

Ou si vous utilisez le port sécurisé avec authentification, utilisez kubectl proxy et interrogez l'API du kubelet.

Exemple de sortie :

# HELP kubelet_swap_used_bytes Current swap usage in bytes.
# TYPE kubelet_swap_used_bytes gauge
kubelet_swap_used_bytes 1073741824

Cela indique environ 1 Go de swap utilisé.

Inspecter l'utilisation des ressources des pods

Utilisez kubectl top pour voir l'utilisation réelle de la mémoire :

kubectl top pod swap-test

Si kubectl top n'est pas disponible, utilisez kubectl describe pour voir les demandes et limites de ressources.

Examiner les événements du nœud

Recherchez les avertissements ou erreurs liés au swap :

kubectl describe node NODE_NAME | grep -i swap

Aucune sortie n'est bonne. Si des avertissements apparaissent, approfondissez l'enquête.

Diagnostiquer les échecs de pods dus au swap

Si un pod ne démarre pas, vérifiez ses événements et journaux :

kubectl describe pod swap-test
kubectl logs swap-test --previous

Signaux d'échec courants :

Failed to create pod sandbox peut indiquer des problèmes de cgroup.
OOMKilled suggère des contraintes de mémoire, potentiellement liées à une mauvaise configuration du swap.
Pod bloqué en ContainerCreating avec des messages liés au swap dans les journaux du kubelet.

Valider la préparation au retour en arrière

Simulez un retour en arrière dans un environnement de test. Appliquez la configuration précédente et confirmez que les pods redémarrent proprement.

Modes de défaillance et récupération

Même avec une planification soignée, des défaillances surviennent. Sachez comment détecter et récupérer des problèmes courants liés au swap.

Défaillance : le kubelet ne démarre pas avec le swap activé

Symptôme : systemctl status kubelet montre un échec, les journaux contiennent failed to run Kubelet: running with swap on is not supported, please disable swap!

Cause : failSwapOn est vrai dans la configuration du kubelet ou non défini (vrai par défaut) alors que le swap est actif.

Récupération : Définissez failSwapOn: false dans la configuration du kubelet, ou désactivez temporairement le swap (sudo swapoff -a), puis redémarrez le kubelet. Si vous utilisez failSwapOn: false, assurez-vous que memorySwap.swapBehavior est défini de manière appropriée.

Défaillance : le nœud devient NotReady après l'activation du swap

Symptôme : kubectl get nodes montre NotReady pour le nœud.

Cause : Le kubelet a peut-être redémarré et perdu la connexion, ou les ressources système sont mal configurées.

Récupération :

Vérifiez le statut et les journaux du kubelet.
Assurez-vous que le kubelet a redémarré correctement.
Vérifiez la connectivité réseau et les conditions du nœud :

   kubectl describe node NODE_NAME

Si le swap a causé des problèmes de noyau, désactivez le swap et redémarrez.

Défaillance : évictions de pods inattendues

Symptôme : Les pods sont évincés malgré la mémoire disponible, avec la condition de nœud MemoryPressure.

Cause : Le swap peut être mal pris en compte. Avec LimitedSwap, le kubelet peut calculer incorrectement la mémoire disponible, entraînant des évictions.

Récupération : Ajustez les seuils d'éviction du kubelet. Dans la configuration du kubelet, définissez :

evictionHard:
  memory.available: "200Mi"
  nodefs.available: "10%"

Redémarrez le kubelet et surveillez.

Défaillance : les pods avec QoS Guaranteed tentent d'utiliser le swap

Symptôme : Les pods avec QoS Guaranteed (demandes égales aux limites) peuvent être terminés s'ils essaient d'utiliser le swap.

Cause : En mode LimitedSwap, les pods Guaranteed ne sont pas autorisés à utiliser le swap. Si la charge de travail nécessite le swap, changez sa classe QoS en Burstable.

Récupération : Modifiez les demandes/limites de ressources du pod pour le rendre Burstable, ou envisagez de changer le comportement du swap si approprié.

Reprise après sinistre : restauration complète du nœud

Si un nœud devient irrécupérable, reconstruisez-le à partir de zéro en utilisant un outil de gestion de configuration ou des étapes manuelles :

Provisionnez un nouveau nœud avec le même système d'exploitation et les mêmes spécifications.
Joignez-le au cluster (en utilisant kubeadm join ou le fournisseur cloud).
Réappliquez la configuration du swap : créez le fichier d'échange, mettez à jour la configuration du kubelet, redémarrez le kubelet.
Vérifiez l'état de préparation du nœud et la planification des pods.

Stratégie de sauvegarde pour la configuration du swap

Traitez la configuration du nœud comme du code. Stockez la configuration du kubelet, les fichiers d'unité systemd et les scripts de configuration du swap dans un contrôle de version. Utilisez des outils comme Ansible, Terraform ou cloud-init pour reconstruire les nœuds de manière cohérente. Testez périodiquement les procédures de restauration dans un environnement de préproduction.

Exemple de script de sauvegarde :

#!/bin/bash
# Sauvegarder la configuration du kubelet et les paramètres de swap
mkdir -p ~/k8s-backup/$(date +%Y%m%d)
cp /var/lib/kubelet/config.yaml ~/k8s-backup/$(date +%Y%m%d)/kubelet-config.yaml
cp /etc/fstab ~/k8s-backup/$(date +%Y%m%d)/fstab
swapon --show > ~/k8s-backup/$(date +%Y%m%d)/swap-status.txt

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour assurer la cohérence et la sécurité lors de la gestion du swap sur les nœuds Kubernetes.

Avant tout changement

Confirmez que la version de Kubernetes prend en charge le swap (>=1.28 et cgroup v2).
Vérifiez que le système d'exploitation du nœud prend en charge le swap avec cgroup v2.
Prenez une sauvegarde de la configuration du kubelet : cp /var/lib/kubelet/config.yaml /var/lib/kubelet/config.yaml.bak-$(date +%F).
Enregistrez l'état actuel du swap : swapon --show et free -h.
Cordonnez et drainez le nœud si vous effectuez des modifications perturbatrices.

Pendant la configuration

Appliquez un changement à la fois.
Utilisez la configuration memorySwap minimale requise.
Redémarrez le kubelet et vérifiez son statut.
Vérifiez les journaux du kubelet pour les erreurs.
Déployez un pod de test et observez le comportement du swap.

Vérification

Exécutez kubectl get nodes pour confirmer que le nœud est Ready.
Vérifiez kubectl describe node NODE_NAME pour les conditions MemoryPressure.
Inspectez la planification des pods et l'utilisation des ressources.
Validez que le plan de retour en arrière est exécutable.

Documentation et retour en arrière

Mettez à jour l'inventaire avec la nouvelle configuration.
Stockez les copies de sauvegarde dans un emplacement sécurisé.
Documentez toutes les étapes de dépannage entreprises.
Planifiez un examen des métriques d'utilisation du swap.

Conclusion

La gestion de la mémoire d'échange Kubernetes nécessite une stratégie bien définie de sauvegarde, restauration et reprise après sinistre. En inventoriant votre environnement, en appliquant des modifications de configuration en toute sécurité, en vérifiant les résultats et en vous préparant aux défaillances, vous pouvez tirer parti des avantages du swap sans compromettre la stabilité du cluster. Les commandes pratiques et les exemples de ce guide fournissent une base pour des opérations fiables.

Comme prochaine étape, mettez en œuvre un système de gestion de configuration versionné pour les paramètres des nœuds, y compris le swap. Testez vos procédures de sauvegarde et de restauration dans un environnement de préproduction, et documentez votre runbook de récupération. Avec ces pratiques, vos clusters Kubernetes seront résilients et maintenables.