Sauvegarde et restauration des Taints et Tolérations Kubernetes : guide pratique

Introduction

Les taints et les tolérances constituent un mécanisme fondamental d’ordonnancement de Kubernetes. Un taint sur un nœud repousse les pods qui ne le tolèrent pas, tandis qu’une tolérance sur un pod lui permet d’être planifié sur des nœuds marqués par un taint. Contrairement aux sélecteurs de nœuds, les taints et les tolérances ne garantissent pas l’ordonnancement ; ils l’influencent seulement, en complément des règles d’affinité et d’anti-affinité.

Les opérateurs doivent souvent sauvegarder la configuration des taints de leurs nœuds et les tolérances définies dans les manifestes des charges de travail. Lorsqu’un nœud est remplacé, qu’un cluster est restauré après un sinistre ou qu’un déploiement est annulé, disposer d’un processus fiable de sauvegarde et de restauration évite que les pods atterrissent sur les mauvais nœuds ou deviennent impossibles à planifier. Ce guide fournit des exemples pratiques pour sauvegarder et restaurer les taints et les tolérances, valider le résultat et récupérer des échecs courants.

L’objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d’impact, utiliser des valeurs génériques au lieu de secrets, vérifier le résultat et documenter la procédure de récupération si l’état attendu n’est pas atteint.

Inventaire des versions et de l’environnement

Avant de sauvegarder les taints et les tolérances, identifiez la version de Kubernetes et la topologie du cluster. La syntaxe et le comportement des taints et des tolérances sont stables sur les versions récentes, mais certaines fonctionnalités, comme l’effet PreferNoSchedule et les taints intégrés kubernetes.io/, ont évolué. Exécutez kubectl version pour vérifier les versions du client et du serveur. Pour les clusters gérés (EKS, GKE, AKS), notez séparément la version du plan de contrôle.

Déterminez ce que vous devez sauvegarder :

• Les taints de nœuds : attachés aux objets nœuds, souvent ajoutés manuellement ou par des contrôleurs.
• Les tolérances des pods : définies dans les manifestes de pods, déploiements, statefulsets ou daemonsets.

Observation en lecture seule d’abord

Collectez l’état actuel sans rien modifier :

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints --show-labels

Exemple de sortie attendue :

NAME     TAINTS
node-1   [map[effect:NoSchedule key:dedicated value:database]]
node-2   [map[effect:NoSchedule key:dedicated value:database]]
node-3   <none>

Pour une sauvegarde JSON détaillée de tous les taints de nœuds :

kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, taints: .spec.taints}' > node-taints-backup.json

Ce fichier sert d’instantané restaurable.

Exemple d’environnement

Supposons un cluster à trois nœuds :

• node-1 et node-2 : marqués par dedicated=database:NoSchedule pour les réserver aux charges de travail de base de données.
• node-3 : sans taint, utilisé pour les charges de travail générales.

Les déploiements incluent des tolérances dans leurs spécifications de pod pour permettre la planification sur les nœuds de base de données dédiés.

Chemin de configuration sûr

Sauvegarde des taints

Pour sauvegarder les taints de tous les nœuds dans un format lisible :

kubectl get nodes -o yaml | kubectl neat > all-nodes.yaml

(Installez kubectl neat pour une sortie nettoyée ; sinon, utilisez grep -A 5 taints.)

Pour une sauvegarde ciblée, utilisez :

kubectl get node node-1 -o yaml | grep -A 5 -B 5 taints > node-1-taints.yaml

Stockez ces sauvegardes dans un système de contrôle de version. Pour des sauvegardes automatisées, exécutez un CronJob qui exporte périodiquement les taints des nœuds et les stocke dans un dépôt Git ou un stockage d’objets.

Sauvegarde des tolérances

Les tolérances se trouvent dans les manifestes des charges de travail. Exportez la configuration en direct de tous les déploiements :

kubectl get deployments --all-namespaces -o yaml > deployments-backup.yaml

Extrayez uniquement les tolérances pour la documentation :

kubectl get deployments --all-namespaces -o json | jq '.items[] | {name: .metadata.name, namespace: .metadata.namespace, tolerations: .spec.template.spec.tolerations}' > tolerations-backup.json

Cela donne une vue compacte des charges de travail qui tolèrent quels taints.

Restauration des taints sur un nouveau nœud

Après avoir remplacé un nœud, réappliquez les taints :

kubectl taint nodes node-1-new dedicated=database:NoSchedule
kubectl taint nodes node-2-new dedicated=database:NoSchedule

La commande kubectl taint utilise la syntaxe clé=valeur:effet pour les taints avec valeur, ou clé:effet pour les taints basés sur l’existence. Pour supprimer un taint, ajoutez un signe moins : kubectl taint nodes node-1 dedicated:NoSchedule-.

Restauration des tolérances

Si un déploiement a été modifié par erreur ou annulé sans tolérances, réappliquez le manifeste sauvegardé :

kubectl apply -f deployment-with-tolerations.yaml

Exemple d’extrait de déploiement avec une tolérance :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: database-app
spec:
  template:
    spec:
      tolerations:
      - key: "dedicated"
        operator: "Equal"
        value: "database"
        effect: "NoSchedule"

Vérification et diagnostics

Après la restauration des taints, vérifiez qu’ils sont présents sur les bons nœuds :

kubectl describe nodes | grep -i taint -A 2

Sortie attendue pour node-1-new :

Taints:             dedicated=database:NoSchedule

Vérifiez que les pods avec tolérances sont planifiés comme prévu :

kubectl get pods -o wide

Les pods qui tolèrent dedicated=database:NoSchedule devraient pouvoir être planifiés sur node-1-new et node-2-new. Les pods sans tolérances ne devraient être planifiés que sur les nœuds sans taint.

Diagnostic des échecs d’ordonnancement

Si un pod reste en attente, inspectez les événements :

kubectl describe pod <nom-du-pod> | grep -A 10 Events

Recherchez des messages comme :

Warning  FailedScheduling  0/3 nodes are available: 1 node(s) had taint {dedicated: database}, that the pod didn't tolerate, 2 node(s) had taint {dedicated: database}, that the pod didn't tolerate.

Cela indique que le pod ne possède pas la tolérance requise.

Vérifiez les tolérances d’un pod :

kubectl get pod <nom-du-pod> -o jsonpath='{.spec.tolerations}'

Utilisez kubectl rollout status deployment/<nom> pour confirmer qu’un déploiement a réussi après la restauration des tolérances.

Modes d’échec et récupération

Modes d’échec courants lors de l’utilisation des taints et des tolérances :

1. Tolérance manquante sur le pod : Un pod est planifié sur un nœud avec un taint qu’il ne tolère pas. Ceci est empêché avant la planification ; le pod reste en attente.

• Récupération : Ajoutez la tolérance requise à la spécification du pod, ou supprimez le taint du nœud s’il n’est pas nécessaire.

1. Suppression accidentelle d’un taint : Si un taint est supprimé d’un nœud, des pods qui ne devraient pas s’exécuter sur ce nœud peuvent y être planifiés.

• Récupération : Réappliquez le taint avec kubectl taint nodes <nœud> <clé>=<valeur>:<effet>.

1. Effet de taint incorrect : Par exemple, utiliser NoExecute au lieu de NoSchedule peut expulser les pods existants qui ne tolèrent pas le taint.

• Récupération : Modifiez le taint avec l’effet correct, ou ajoutez les tolérances appropriées aux pods.

1. Restauration à partir d’une ancienne sauvegarde : Si la sauvegarde est obsolète, les taints ou tolérances nouvellement ajoutés peuvent être perdus.

• Récupération : Maintenez les sauvegardes à jour avec l’automatisation, et comparez l’état actuel avec la sauvegarde avant de restaurer.

1. Tolérances non appliquées en raison d’erreurs d’indentation YAML : La sensibilité YAML peut empêcher l’application des tolérances.

• Récupération : Utilisez kubectl apply --dry-run=client -f manifest.yaml pour valider la syntaxe, et vérifiez la spécification du pod en direct avec kubectl get pod <pod> -o yaml.

Liste de contrôle des opérations

Utilisez cette liste pour chaque modification impliquant des taints et des tolérances :

Chaque étape doit avoir un responsable unique clairement identifié, pas un groupe. La colonne fréquence indique à quelle fréquence la tâche ou son résultat est réexaminé.

Pièges courants

1. Supposer que les tolérances sont identiques aux sélecteurs de nœuds : Les tolérances permettent à un pod d’être planifié sur un nœud marqué par un taint, mais elles ne forcent pas la planification à cet endroit. Si vous souhaitez que les pods préfèrent certains nœuds, utilisez l’affinité de nœud en plus des tolérances.

1. Oublier de sauvegarder les tolérances des statefulsets et daemonsets : De nombreux opérateurs sauvegardent les déploiements mais oublient les autres contrôleurs. Incluez toujours tous les types de charges de travail : kubectl get statefulsets,daemonsets --all-namespaces -o yaml.

1. Utiliser kubectl taint sans --overwrite : Si un taint avec la même clé existe déjà, la commande échoue. Utilisez kubectl taint nodes <nœud> <clé>=<valeur>:<effet> --overwrite pour le mettre à jour.

1. Ne pas gérer les taints intégrés : Les nœuds peuvent avoir des taints intégrés comme node.kubernetes.io/not-ready ou node.kubernetes.io/unreachable avec l’effet NoExecute. Ils sont gérés par le plan de contrôle et ne doivent pas être sauvegardés ni restaurés manuellement.

1. Restaurer les taints avant que le nœud ne soit prêt : Les nouveaux nœuds peuvent encore être en cours de provisionnement. Appliquez les taints uniquement après que le nœud est Ready pour éviter d’interférer avec l’initialisation du nœud.

1. Dépendre uniquement des sauvegardes manuelles : L’erreur humaine est courante. Automatisez les sauvegardes avec un CronJob et vérifiez régulièrement l’intégrité des sauvegardes.

Conclusion

La sauvegarde et la restauration des taints et des tolérances Kubernetes sont essentielles pour maintenir un environnement d’ordonnancement stable. Ce guide a montré comment inventorier l’état actuel, exporter les sauvegardes, restaurer les configurations, vérifier les résultats et récupérer des échecs. La clé est de traiter les taints et les tolérances comme une configuration qui doit être versionnée et testée, tout comme le code applicatif.

Commencez par mettre en œuvre un processus de sauvegarde simple : exportez les taints des nœuds et les tolérances des charges de travail vers un dépôt Git. Ensuite, pratiquez une restauration dans un cluster hors production pour vous assurer que le processus fonctionne. Révisez et mettez à jour régulièrement vos procédures de sauvegarde et de restauration à mesure que votre cluster évolue.

N’oubliez pas : les taints et les tolérances ne remplacent pas les quotas de ressources, les sélecteurs de nœuds ou les règles d’affinité. Ils constituent un mécanisme d’ordonnancement qui nécessite une gestion rigoureuse. Avec des sauvegardes appropriées et un plan de récupération, vous pouvez éviter les temps d’arrêt coûteux et les erreurs de configuration.