Sauvegarde et restauration Kubernetes avec exemples pratiques

Une stratégie fiable de sauvegarde et restauration Kubernetes protège non seulement les manifests sans état, mais aussi les données persistantes et, lorsque vous gérez le plan de contrôle, l'état d'etcd. Cet article propose un parcours concret que vous pouvez exécuter en toute sécurité : établir un inventaire précis de l'environnement pour que vos choix correspondent à votre cluster, démarrer avec un essai restreint dans un seul espace de noms, prouver que cela fonctionne, puis étendre. Sauvegardez les manifests, les volumes persistants et, si nécessaire, etcd avec des étapes testées. Restaurez dans le bon ordre, vérifiez le succès et gérez les modes de défaillance avec confiance. Utilisez une liste de contrôle courte pour en faire une opération régulière. L'objectif est des restaurations prévisibles avec un temps d'arrêt minimal et sans surprise.

Inventaire de version et d'environnement

Avant de lancer la première sauvegarde, notez vos versions, votre topologie et les capacités de stockage. Cela détermine les outils compatibles et la séquence de restauration.

• Version et distribution Kubernetes (cloud géré vs auto-géré) :

  kubectl version --short
  kubectl cluster-info

• Nœuds et architecture :

  kubectl get nodes -o wide

• Espaces de noms et empreinte globale :

  kubectl get ns
  kubectl get deploy,sts,ds,svc,ingress -A --no-headers | wc -l

• Ressources API et CRD (nécessaires pour restaurer les ressources personnalisées) :

  kubectl api-resources | sort
  kubectl get crd | wc -l
  kubectl get crd -o name | head -n 10

• Classes de stockage et prise en charge des instantanés CSI (pour les instantanés de PV) :

  kubectl get storageclass
  kubectl get volumesnapshotclass.snapshot.storage.k8s.io 2>/dev/null || echo "Aucune classe d'instantané CSI détectée"

• Si vous gérez etcd (plan de contrôle auto-géré) : notez la version d'etcd et les chemins TLS sur les nœuds du plan de contrôle :

  sudo ETCDCTL_API=3 etcdctl version
  ls /etc/kubernetes/pki/etcd

Utilisez l'inventaire compact suivant comme référence pendant la conception et la restauration.

Parcours de configuration sécurisé

Les sauvegardes doivent couvrir trois couches, choisies selon votre environnement :

1. Manifests et configuration : espaces de noms, Deployments, StatefulSets, Services, Ingress, ConfigMaps, Secrets, RBAC et ressources personnalisées.
2. Données persistantes : volumes soutenus par PVC, idéalement via des instantanés CSI ou des exports applicatifs quand les instantanés ne sont pas disponibles.
3. État du plan de contrôle (optionnel) : instantanés etcd pour les clusters auto-gérés.

Commencez par un essai dans un espace de noms étroit, mesurable et facile à inspecter. Étendez seulement après avoir prouvé que vous pouvez le restaurer de manière fiable.

Essai 1 : Export des manifests d'un espace de noms (sans données)

Cible : un seul espace de noms avec des charges sans état ou des données stockées à l'extérieur (ex. cache uniquement). Durée attendue : quelques minutes.

NS=myapp
# Définition de l'espace de noms
kubectl get namespace "$NS" -o yaml > ns-$NS.yaml

# Ressources principales de l'espace de noms
kubectl get all -n "$NS" -o yaml > $NS-manifests.yaml

# Ressources courantes non incluses dans "all"
kubectl get cm,secret,role,rolebinding,serviceaccount,ingress -n "$NS" -o yaml >> $NS-manifests.yaml

# Si votre application utilise des CRD, ajoutez-les explicitement (exemples de kinds)
# kubectl get kafka,elasticsearch,redis -n "$NS" -o yaml >> $NS-manifests.yaml || true

# Dépendances à l'échelle du cluster (seulement si vous les possédez)
kubectl get crd -o yaml > cluster-crds.yaml

Stockez les fichiers avec un horodatage et un hachage d'intégrité :

tar -czf backup-$NS-$(date +%F).tgz ns-$NS.yaml $NS-manifests.yaml cluster-crds.yaml
sha256sum backup-$NS-*.tgz > backup-$NS-SHA256SUMS.txt

Essai 2 : Ajout des instantanés de volumes persistants (CSI)

Si votre StorageClass prend en charge les instantanés CSI, créez des objets VolumeSnapshot dans le même espace de noms. Adaptez les valeurs à votre environnement.

Créez un VolumeSnapshot :

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: myapp-pvc-snap-20260101
  namespace: myapp
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: myapp-data

Appliquez et vérifiez :

kubectl apply -f myapp-pvc-snapshot.yaml
kubectl -n myapp get volumesnapshot
kubectl -n myapp describe volumesnapshot myapp-pvc-snap-20260101 | sed -n '/Status/,$p'

ReadyToUse doit devenir true. Notez le handle de l'instantané si le pilote l'expose.

Restaurez depuis l'instantané dans un espace de noms de test :

apiVersion: v1
kind: Namespace
metadata:
  name: myapp-restore
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myapp-data-restore
  namespace: myapp-restore
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: gp2
  resources:
    requests:
      storage: 20Gi
  dataSource:
    name: myapp-pvc-snap-20260101
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

Appliquez et confirmez la liaison du PVC :

kubectl apply -f myapp-restore-ns-and-pvc.yaml
kubectl -n myapp-restore get pvc myapp-data-restore -w

Puis déployez un Pod ou Deployment de test qui monte le PVC restauré et exécutez une vérification de données simple.

Optionnel : Instantané etcd (plan de contrôle auto-géré)

Si vous exploitez votre propre plan de contrôle, prenez un instantané etcd depuis un nœud du plan de contrôle. Les chemins peuvent varier selon la distribution.

sudo ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-$(date +%F-%H%M%S).db

sudo ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-*.db -w table

Stockez les instantanés hors du nœud. La restauration d'etcd remplace l'état du cluster ; entraînez-vous d'abord sur un environnement non productif.

Alternative tout-en-un : Sauvegarde et restauration Velero

Velero peut orchestrer les sauvegardes de manifests et les instantanés PV avec des plugins fournisseurs. Exemple (adaptez le fournisseur, le plugin et la configuration de stockage) :

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.8.0 \
  --bucket my-velero-bucket \
  --backup-location-config region=us-east-1 \
  --snapshot-location-config region=us-east-1

# Créez une sauvegarde à l'échelle de l'espace de noms incluant les instantanés de volumes
velero backup create myapp-20260101 \
  --include-namespaces myapp \
  --ttl 168h \
  --snapshot-volumes

# Inspectez les détails
velero backup describe myapp-20260101 --details

Restaurez depuis une sauvegarde Velero :

velero restore create --from-backup myapp-20260101
velero restore get
velero restore describe <nom-restauration>

Plan d'essai construit (exemple)

Le tableau suivant est un plan illustratif avec des chiffres hypothétiques pour le dimensionnement et les durées.

Vérification et diagnostics

Prouvez les sauvegardes et restaurations avec des contrôles objectifs avant de vous y fier.

Valider les sauvegardes de manifests

• Exécution à blanc côté serveur contre un cluster de test ou le même cluster :

  kubectl apply -f ns-myapp.yaml --dry-run=server
  kubectl apply -f myapp-manifests.yaml --dry-run=server

• Compter les ressources avant et après restauration :

  # Avant (capturer les comptes attendus)
  kubectl -n myapp get deploy,sts,svc,cm,secret,pvc --no-headers | wc -l
  # Après restauration dans myapp-restore (comparer)
  kubectl -n myapp-restore get deploy,sts,svc,cm,secret,pvc --no-headers | wc -l

Valider les instantanés PV et les données

• Assurez-vous que le VolumeSnapshot ReadyToUse est true :

  kubectl -n myapp get volumesnapshot myapp-pvc-snap-20260101 -o jsonpath='{.status.readyToUse}{"\n"}'

• Créez un Pod de test montant le PVC restauré et vérifiez la présence de fichiers ou les sommes de contrôle :

  kubectl -n myapp-restore exec deploy/api -- sh -c 'ls -al /data | head -n 20'
  # Optionnellement, comparez les hachages pour un petit ensemble de fichiers
  kubectl -n myapp-restore exec deploy/api -- sh -c 'sha256sum /data/*.idx 2>/dev/null'

Santé et événements

• Prêt des Pods et redémarrages :

  kubectl -n myapp-restore get pods -o wide
  kubectl -n myapp-restore get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.containerStatuses[0].restartCount}{"\n"}{end}'

• Événements récents pour les échecs :

  kubectl -n myapp-restore get events --sort-by=.lastTimestamp | tail -n 30

Diagnostics Velero (si utilisé)

velero backup logs myapp-20260101 | tail -n 50
velero restore describe <nom-restauration> --details

Modes de défaillance et récupération

Prévoyez ce qui peut casser. Voici les problèmes courants, leurs symptômes et les récupérations.

Symptôme : erreurs d'application comme "no matches for kind X in version Y". Correctif : appliquez les CRD d'abord, puis les ressources personnalisées. Gardez un fichier de sauvegarde CRD séparé et restaurez-le avant les manifests d'espace de noms.

• CRD manquantes avant les CR

Symptôme : les ressources échouent car l'espace de noms n'existe pas encore, ou l'espace de noms existant contient des objets en conflit. Correctif : créez l'espace de noms en premier. Pour les restaurations de test, utilisez un espace de noms frais (ex. myapp-restore). Pour annuler, supprimez seulement l'espace de noms de test.

• Collisions d'espaces de noms ou mauvais ordre

Symptôme : le PVC depuis l'instantané reste en Pending ; les événements indiquent qu'aucun volume approprié n'est trouvé. Correctif : utilisez une StorageClass compatible avec le pilote d'instantané. Vérifiez le mappage VolumeSnapshotClass et StorageClass ; consultez la documentation de votre pilote CSI pour les contraintes inter-zones ou de type.

• Incompatibilité de classe d'instantané ou StorageClass

Symptôme : les pods démarrent mais échouent à se connecter aux dépendances ; les variables d'environnement ou fichiers diffèrent de la production. Correctif : assurez-vous que les secrets/config sont inclus dans la sauvegarde, ou régénérez-les dans l'espace de noms de restauration. Pour les secrets générés, sauvegardez leur source ou recréez-les de manière sécurisée.

• Dérive des Secrets et ConfigMaps

Symptôme : les contrôleurs échouent avec des erreurs Forbidden après restauration. Correctif : restaurez Role, RoleBinding, ClusterRole, ClusterRoleBinding et ServiceAccount dans le bon périmètre. Confirmez que les sujets et noms sont inchangés.

• Lacunes RBAC

Symptôme : erreurs d'application après restauration bien que le PVC soit monté ; corruption logique. Correctif : privilégiez les sauvegardes cohérentes au niveau applicatif (hooks pre/post ou exports natifs de base de données) si vos instantanés de stockage ne sont pas crash-consistent pour la charge de travail.

• Cohérence applicative sur bases de données en écriture

Symptôme : régressions à l'échelle du cluster si etcd restauré vers une configuration de cluster incompatible. Correctif : entraînez-vous d'abord sur non-production. Faites correspondre le nom, initial-cluster, peer URLs et data-dir avec vos manifests de pods statiques originaux.

• Risques de restauration etcd (auto-géré uniquement)

Patterns de retour arrière et récupération

Si un test de restauration cause des problèmes, supprimez seulement l'espace de noms de test :

• Retour arrière de restauration d'espace de noms

  kubectl delete ns myapp-restore --wait=false

Aucune modification ne fuite dans l'espace de noms original.

Si un PVC restauré est incorrect, supprimez le PVC (pas le VolumeSnapshot) et recréez-le depuis l'instantané avec la StorageClass ou la taille corrigée.

• Retour arrière PVC

Conservez le répertoire /var/lib/etcd précédent comme sauvegarde avant restauration. Si la restauration échoue, arrêtez etcd, remettez l'ancien répertoire, et redémarrez.

• Retour arrière etcd (auto-géré)

Restauration contrôlée d'etcd (aperçu)

Uniquement pour les plans de contrôle auto-gérés ; suivez les spécificités de votre distribution.

# Sur un nœud du plan de contrôle
sudo systemctl stop kube-apiserver etcd
sudo mv /var/lib/etcd /var/lib/etcd.bak.$(date +%s)

# Restaurez depuis un instantané connu bon (remplissez les placeholders pour correspondre à votre cluster)
sudo ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-YYYYMMDDHHMM.db \
  --data-dir=/var/lib/etcd \
  --name=<nom-noeud-etcd> \
  --initial-cluster=<nom-noeud-etcd>=https://127.0.0.1:2380 \
  --initial-advertise-peer-urls=https://127.0.0.1:2380

sudo systemctl start etcd kube-apiserver

Confirmez la santé de l'API après le démarrage d'etcd :

kubectl get --raw=/healthz

Liste de contrôle opérationnelle

Exécutez cette liste selon un calendrier (ex. hebdomadaire) et après les changements significatifs.

• Inventaire
• Enregistrez kubectl version, cluster-info, nœuds.
• Exportez les StorageClasses et VolumeSnapshotClasses actuelles.
• Listez les CRD dont vous dépendez.

• Sauvegarder
• Exportez les manifests d'espace de noms et ressources courantes en YAML.
• Si applicable, sauvegardez les CRD (à l'échelle du cluster) que vous possédez.
• Pour les PVC, créez des VolumeSnapshots CSI pour les volumes clés.
• Si plan de contrôle auto-géré, prenez un instantané etcd.

• Vérifier
• Exécutez kubectl apply --dry-run=server sur les YAML exportés.
• Assurez-vous que les instantanés affichent ReadyToUse=true.
• Journalisez les noms d'artefacts, hachages et emplacements.

• Stocker
• Poussez les artefacts vers un stockage durable et à accès contrôlé.
• Gardez au moins une copie hors site ou inter-région.

• Tester la restauration
• Utilisez un espace de noms frais (ex. myapp-restore).
• Appliquez les CRD, puis l'espace de noms et les manifests.
• Restaurez les PVC depuis les instantanés et montez dans des pods de test.
• Confirmez les pods Ready, peu de redémarrages et vérifications de données de base.

• Revoir et améliorer
• Capturez le temps de restauration, erreurs et dépendances manquantes.
• Étendez le périmètre à d'autres espaces de noms seulement après des tests propres.

Conclusion

Vous disposez maintenant d'un parcours pratique et à faible risque pour les sauvegardes et restaurations Kubernetes. Commencez petit avec un export de manifests d'espace de noms, prouvez que vous pouvez le restaurer, et ajoutez les données persistantes via les instantanés CSI quand disponibles. Si vous gérez votre propre plan de contrôle, incluez les instantanés etcd et entraînez-vous aux restaurations en non-production. Vérifiez avec des dry-runs, des comptages, des événements et des vérifications de données simples. Traitez les restaurations de test comme des exercices réguliers. Documentez les modes de défaillance et les étapes de retour arrière pour qu'une mauvaise restauration soit facile à annuler. Prochaines étapes : planifiez la liste de contrôle, automatisez les exports et la création d'instantanés, et étendez la couverture à d'autres espaces de noms et volumes critiques. À mesure que votre confiance grandit, documentez un plan complet de reprise après sinistre incluant le bootstrap du cluster, l'installation des CRD et la restauration ordonnée des charges de travail et des données. Avec ces étapes en place, vous pouvez atteindre vos objectifs de récupération de manière prévisible et répétable.