Sauvegarde et restauration des classes d'exécution Kubernetes : guide pratique

Introduction

Les classes d'exécution (Runtime Classes) dans Kubernetes permettent de sélectionner un runtime de conteneur pour un pod, comme un bac à sable léger tel que gVisor, un runtime haute performance comme Kata Containers, ou un runtime personnalisé avec des fonctionnalités spécifiques. La sauvegarde et la restauration des ressources RuntimeClass sont essentielles pour la reprise après sinistre et la migration de cluster. Si une RuntimeClass est absente ou mal configurée, les pods qui y font référence échoueront à se planifier, provoquant des interruptions. Ce guide couvre les procédures pratiques de sauvegarde et de restauration avec des commandes concrètes, des étapes de validation et des stratégies de récupération.

Vous apprendrez à :

Inventorier les RuntimeClass existantes et leurs configurations.
Sauvegarder les objets RuntimeClass à l'aide des outils Kubernetes standard.
Restaurer les RuntimeClass dans un cluster nouveau ou récupéré.
Valider que les RuntimeClass restaurées fonctionnent correctement.
Gérer les modes de défaillance courants et effectuer des retours en arrière en toute sécurité.

Ce guide s'adresse aux développeurs, ingénieurs DevOps et opérateurs de plateforme qui gèrent des clusters Kubernetes et doivent garantir que les configurations de runtime survivent aux sinistres.

Inventaire de la version et de l'environnement

Avant de sauvegarder les RuntimeClass, comprenez votre environnement de cluster. Cette section montre comment vérifier la version de Kubernetes, confirmer la disponibilité de l'API et lister les RuntimeClass actuelles.

Prérequis

Un cluster Kubernetes en cours d'exécution avec kubectl configuré.
Accès pour consulter les RuntimeClass (généralement cluster-admin ou similaire).

Vérifier la version de Kubernetes

RuntimeClass est disponible en version stable v1 depuis Kubernetes 1.20. Les versions antérieures utilisaient l'API node.k8s.io/v1beta1. Exécutez :

kubectl version --short

Sortie attendue (exemple) :

Client Version: v1.27.3
Kustomize Version: v5.0.1
Server Version: v1.27.3

Si la version du serveur est inférieure à 1.20, ajustez les versions d'API en conséquence. Pour ce guide, nous supposons la version v1.

Lister les RuntimeClass existantes

Pour voir toutes les RuntimeClass :

kubectl get runtimeclass

Exemple de sortie :

NAME        HANDLER     AGE
runc        runc        10d
gvisor      runsc       10d
kata        kata        10d

La colonne HANDLER indique le nom du gestionnaire de runtime configuré dans le runtime de conteneur. Il doit correspondre au gestionnaire dans la configuration du runtime du nœud.

Inspecter une RuntimeClass spécifique

Affichez la définition complète d'une RuntimeClass :

kubectl get runtimeclass gvisor -o yaml

Exemple de sortie :

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
  annotations:
    example.com/description: "Sandboxed runtime for untrusted workloads"
handler: runsc
scheduling:
  nodeSelector:
    runtime: gvisor
  tolerations:
  - key: "sandboxed"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
overhead:
  podFixed:
    cpu: "100m"
    memory: "128Mi"

Cette RuntimeClass spécifie un gestionnaire, un sélecteur de nœud, des tolérances et des frais généraux de pod. Tous ces champs doivent être sauvegardés.

Chemin de configuration sûr

Cette section couvre la manière sûre de capturer les configurations de RuntimeClass pour la sauvegarde. Nous utilisons d'abord des opérations en lecture seule pour éviter les modifications accidentelles.

Extraire toutes les RuntimeClass en YAML

Pour sauvegarder toutes les RuntimeClass de manière globale (les RuntimeClass sont de portée cluster, donc pas d'espace de noms) :

kubectl get runtimeclass -o yaml > runtimeclasses-backup.yaml

Cette commande capture les définitions complètes. Cependant, la sortie inclut des champs comme status et des métadonnées comme resourceVersion qui ne sont pas nécessaires et peuvent causer des problèmes lors de la restauration. Pour obtenir une sauvegarde plus propre, utilisez --export (obsolète dans les versions plus récentes) ou traitez le YAML. Dans Kubernetes 1.18+, --export est obsolète. À la place, utilisez un outil comme kubectl neat ou supprimez manuellement les champs indésirables. Pour simplifier, nous conserverons la sortie complète et noterons que kubectl apply ignore certains champs automatiquement, mais resourceVersion doit être supprimé avant l'application pour éviter les erreurs de conflit.

Pour supprimer par programme les champs indésirables, utilisez kubectl get -o json et redirigez vers jq pour supprimer metadata.resourceVersion, metadata.uid, metadata.creationTimestamp et status :

kubectl get runtimeclass -o json | jq 'del(.items[].metadata.resourceVersion, .items[].metadata.uid, .items[].metadata.creationTimestamp, .items[].metadata.generation, .items[].status)' > runtimeclasses-clean.json

Ce JSON peut être stocké comme sauvegarde.

Sauvegarder également les définitions de ressources personnalisées (le cas échéant)

Si vos RuntimeClass référencent des gestionnaires personnalisés définis par des extensions, assurez-vous que la configuration de ces extensions est également sauvegardée. Par exemple, si vous utilisez un runtime personnalisé installé via un DaemonSet, sauvegardez ce DaemonSet et les ConfigMaps associés. Explorez l'utilisation de kubectl get daemonset -A -o yaml pour des runtimes comme gVisor déployés en DaemonSets.

Vérifier le fichier de sauvegarde

Vérifiez que le fichier de sauvegarde existe et contient des données :

wc -l runtimeclasses-clean.json

Ouvrez-le pour confirmer qu'il n'y a pas de structures vides.

Vérification et diagnostics

Après la sauvegarde, vérifiez que la sauvegarde est complète et correcte. Testez la restauration dans un cluster non production pour vous assurer que le processus fonctionne.

Créer un pod de test utilisant la RuntimeClass

Avant qu'un sinistre ne survienne, testez que la RuntimeClass fonctionne. Créez un pod qui utilise gvisor :

# test-gvisor-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-gvisor
spec:
  runtimeClassName: gvisor
  containers:
  - name: test
    image: busybox
    command: ["sleep", "3600"]

Appliquez et vérifiez le statut :

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

Attendu : statut Running. S'il échoue avec FailedCreatePodSandBox ou CreatePodSandbox for pod failed, le gestionnaire de runtime n'est pas disponible sur le nœud.

Vérifier la disponibilité des nœuds pour le runtime

Vérifiez que les nœuds ont le runtime configuré :

kubectl get nodes -l runtime=gvisor

Si aucun nœud n'est retourné, le nodeSelector dans la RuntimeClass ne correspond à aucun nœud, et les pods ne se planifieront pas.

Tester la planification et les frais généraux

Créez un pod avec des demandes de ressources pour vérifier que les frais généraux sont appliqués :

kubectl apply -f test-gvisor-pod.yaml
kubectl describe pod test-gvisor | grep -A5 "Requests"

La sortie attendue montre les frais généraux ajoutés aux demandes du conteneur.

Modes de défaillance et récupération

Cette section décrit les scénarios de défaillance courants et comment s'en remettre.

RuntimeClass manquante lors de la restauration

Si vous tentez de restaurer un pod qui référence une RuntimeClass inexistante, le pod échouera à se planifier. Pour récupérer :

Vérifiez les événements :

   kubectl describe pod mypod | grep -A10 Events

Cherchez FailedScheduling avec le message "runtimeclass.node.k8s.io/gvisor not found".

Restaurez la RuntimeClass depuis la sauvegarde :

   kubectl apply -f runtimeclasses-backup.yaml

Recréez le pod si nécessaire.

Configuration du gestionnaire cassée

Si le gestionnaire dans la RuntimeClass ne correspond à aucun runtime configuré sur le nœud, les pods échoueront à créer le bac à sable. Corrigez en rectifiant le gestionnaire dans la RuntimeClass ou en ajoutant la configuration du runtime sur les nœuds. Par exemple, si vous avez défini par erreur le gestionnaire sur runc alors que les nœuds n'ont que runsc pour cette classe, mettez à jour la RuntimeClass :

kubectl patch runtimeclass gvisor --type='merge' -p '{"handler":"runsc"}'

Ensuite, vérifiez la création du pod.

Retour en arrière des modifications de RuntimeClass

Si vous modifiez une RuntimeClass et que cela cause des problèmes, revenez à une version précédente. Conservez des sauvegardes versionnées. Pour restaurer une version spécifique :

kubectl apply -f backups/runtimeclass-gvisor-20250301.yaml

Utilisez une convention de nommage avec horodatage.

Reprise après sinistre à l'échelle du cluster

En cas de perte totale du cluster, restaurez les RuntimeClass dans le cadre de votre processus d'amorçage de cluster. Après la création du cluster, appliquez les sauvegardes avant de restaurer les charges de travail :

kubectl apply -f runtimeclasses-clean.json

Ensuite, restaurez les autres ressources. Assurez l'ordre : RuntimeClass avant les pods/déploiements.

Liste de contrôle opérationnelle

Utilisez cette liste pour garantir un processus de sauvegarde et de restauration complet :

[ ] Version de Kubernetes enregistrée (kubectl version).
[ ] Toutes les RuntimeClass listées et exportées dans un fichier sous contrôle de version.
[ ] Fichier de sauvegarde nettoyé des champs resourceVersion et status.
[ ] Sauvegarde stockée hors cluster (par exemple, git, stockage d'objets).
[ ] Processus de restauration testé dans un cluster de préproduction.
[ ] Planification de pod testée avec chaque RuntimeClass.
[ ] Étiquettes de nœud et tolérances vérifiées.
[ ] Correspondance entre gestionnaires et runtimes réels documentée.
[ ] Plan de retour en arrière pour les modifications de RuntimeClass.
[ ] Sauvegarde de RuntimeClass incluse dans les travaux de sauvegarde réguliers du cluster.

Exemple de script de sauvegarde pour une tâche cron :

#!/bin/bash
kubectl get runtimeclass -o json | jq 'del(.items[].metadata.resourceVersion, .items[].metadata.uid, .items[].metadata.creationTimestamp, .items[].metadata.generation, .items[].status)' > /backups/runtimeclasses-$(date +%Y%m%d%H%M).json

Conclusion

La sauvegarde et la restauration des classes d'exécution Kubernetes sont une tâche simple mais critique. En suivant les étapes de ce guide, vous pouvez garantir que vos configurations de runtime survivent aux sinistres et que les pods référençant des runtimes spécialisés continuent de fonctionner. Les points clés sont : inventorier vos RuntimeClass, les sauvegarder proprement, tester minutieusement la restauration et être préparé aux modes de défaillance courants. Des sauvegardes et validations régulières doivent faire partie de votre routine opérationnelle. Commencez par implémenter la commande de sauvegarde de base, puis étendez à des sauvegardes planifiées automatisées avec stockage hors cluster.