Sauvegarde et restauration du cluster (etcd, Velero)

L'importance cruciale de la sauvegarde dans Kubernetes

Un cluster Kubernetes contient l'état désiré de toutes vos applications, configurations, secrets et politiques. Cet état est principalement stocké dans la base de données distribuée etcd, qui agit comme le "cerveau" du cluster. La perte de ces données, que ce soit à cause d'une défaillance matérielle, d'une erreur humaine, d'une corruption de données ou d'une attaque, peut être catastrophique, entraînant potentiellement l'arrêt complet de vos services et une perte de configuration irréversible.

Mettre en place une stratégie de sauvegarde robuste et tester régulièrement les procédures de restauration est donc non négociable pour toute infrastructure Kubernetes de production. Sans cela, vous naviguez sans filet de sécurité. Ce chapitre explore les deux approches principales pour sauvegarder et restaurer un cluster : la sauvegarde directe d'etcd et l'utilisation de l'outil spécialisé Velero.

Méthode 1 : Sauvegarde directe d'etcd

Comme etcd contient l'état complet du cluster (à l'exception potentielle des données dans les volumes persistants), sauvegarder etcd est fondamental pour la reprise après sinistre. Cette méthode consiste à créer un instantané (snapshot) de la base de données etcd.

La commande standard pour cela utilise l'outil etcdctl, qui doit généralement être exécuté directement sur un des noeuds maîtres où etcd est en cours d'exécution. La syntaxe typique pour créer un snapshot est la suivante (peut varier légèrement selon la version d'etcd et la configuration de l'authentification) :

# Assurez-vous que ETCDCTL_API=3 est défini
export ETCDCTL_API=3

# Commande de sauvegarde (adaptez les chemins et endpoints)
etcdctl snapshot save /chemin/vers/backup/etcd-snapshot.db \
  --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

Il est essentiel de copier ce fichier de snapshot (etcd-snapshot.db) vers un emplacement de stockage sécurisé et externe au cluster (par exemple, un bucket S3, un serveur de fichiers distant, etc.).

Considérations pour la sauvegarde etcd :

• Accès : Nécessite un accès direct (SSH) aux noeuds maîtres.
• Fréquence : Doit être effectuée régulièrement (la fréquence dépend de la criticité et de la volatilité du cluster).
• Sécurité : Le fichier de snapshot contient toutes les configurations, y compris les Secrets. Il doit être stocké de manière très sécurisée.
• Restauration : La restauration à partir d'un snapshot etcd (etcdctl snapshot restore) est une opération délicate. Elle implique généralement d'arrêter l'API Server et les autres membres etcd, de restaurer les données sur chaque membre (dans un cluster HA), puis de redémarrer les composants. Cela entraîne une interruption de service du Control Plane et doit être testé rigoureusement.
• Limites : Cette méthode ne sauvegarde que l'état de l'API Kubernetes stocké dans etcd. Elle ne sauvegarde pas les données contenues dans les PersistentVolumes.

Méthode 2 : Sauvegarde et restauration avec Velero

Velero (anciennement Heptio Ark) est un outil open-source populaire, soutenu par la CNCF, conçu spécifiquement pour la sauvegarde et la restauration d'objets Kubernetes et, facultativement, de PersistentVolumes. Il fonctionne de manière native avec l'API Kubernetes.

Architecture de Velero :

• Serveur Velero : S'exécute comme un Deployment dans votre cluster Kubernetes. Il interagit avec l'API Server pour récupérer les objets à sauvegarder et avec le fournisseur de stockage pour stocker les sauvegardes.
• Fournisseur de Stockage : Velero stocke ses sauvegardes (archives tar compressées des objets Kubernetes et métadonnées) dans un stockage objet (comme AWS S3, Azure Blob Storage, Google Cloud Storage, ou S3-compatible comme MinIO).
• Snapshot de Volumes (Optionnel) : Velero peut s'intégrer aux API des fournisseurs de cloud ou utiliser un outil comme Restic (pour une sauvegarde au niveau fichier) afin de créer des snapshots des données des PersistentVolumes.
• Client CLI (velero) : Utilisé pour déclencher des sauvegardes, des restaurations, vérifier l'état, etc.

Processus de Sauvegarde avec Velero :

1. Installation du serveur Velero dans le cluster et configuration du backend de stockage et des plugins de snapshot de volume si nécessaire.
2. Utilisation de la commande velero backup create pour démarrer une sauvegarde. On peut cibler des namespaces spécifiques, utiliser des sélecteurs de labels, inclure ou exclure des types de ressources, et demander la création de snapshots de volumes.

# Sauvegarder tous les objets du namespace 'mon-app'
velero backup create sauvegarde-mon-app --include-namespaces mon-app

# Sauvegarder tous les objets sauf ceux du namespace 'kube-system', avec snapshots des PVs
velero backup create sauvegarde-prod --exclude-namespaces kube-system --snapshot-volumes=true

# Planifier une sauvegarde quotidienne à 2h du matin
velero schedule create sauvegarde-quotidienne --schedule="0 2 * * *" --snapshot-volumes=true

Processus de Restauration avec Velero :

1. Lister les sauvegardes disponibles avec velero backup get.
2. Utiliser la commande velero restore create pour lancer une restauration à partir d'une sauvegarde spécifique. On peut restaurer l'intégralité de la sauvegarde ou seulement certaines ressources, et même remapper les namespaces si nécessaire (utile pour cloner un environnement).

# Restaurer la dernière sauvegarde nommée 'sauvegarde-mon-app'
velero restore create --from-backup sauvegarde-mon-app

# Restaurer une sauvegarde spécifique en remappant le namespace
velero restore create restauration-test --from-backup sauvegarde-prod-20230115 --namespace-mappings old-ns:new-ns

Avantages de Velero :

• Kubernetes-Natif : Opère via l'API Kubernetes, sans nécessiter d'accès direct aux noeuds maîtres pour les opérations courantes.
• Granularité : Permet de sauvegarder/restaurer des namespaces ou des ressources spécifiques facilement.
• Gestion des PVs : Intégration avec les snapshots de fournisseurs de stockage ou Restic pour sauvegarder les données persistantes.
• Migration/Clonage : Facilite la migration d'applications ou le clonage d'environnements entre clusters.
• Moins Intrusif : La restauration est généralement moins perturbatrice qu'une restauration complète d'etcd.

Comparaison et stratégie recommandée

La sauvegarde etcd et Velero répondent à des besoins complémentaires. La sauvegarde etcd est essentielle pour une reprise après sinistre fondamentale du Control Plane. C'est le dernier recours si tout le reste échoue. Cependant, sa restauration est complexe et impactante.

Velero offre une solution plus flexible et opérationnelle pour la sauvegarde et la restauration au quotidien. Il est idéal pour sauvegarder des applications spécifiques, restaurer des objets supprimés accidentellement, ou migrer des charges de travail. Sa capacité à gérer les snapshots de volumes est un avantage majeur pour les applications stateful.

Stratégie Recommandée : Pour une robustesse maximale, il est souvent conseillé de combiner les deux approches :

1. Sauvegardes etcd régulières : Effectuées moins fréquemment (par exemple, quotidiennement) et stockées de manière très sécurisée pour la reprise après sinistre majeure du Control Plane.
2. Sauvegardes Velero fréquentes : Configurées pour sauvegarder les objets Kubernetes et les données des volumes persistants importants (par exemple, plusieurs fois par jour ou avant des changements majeurs), permettant des restaurations plus rapides et granulaires pour les scénarios opérationnels courants.

Bonnes pratiques générales

Quelle que soit la méthode choisie, certaines bonnes pratiques s'appliquent :

• Automatisation : Automatisez la planification et l'exécution des sauvegardes.
• Stockage Externe et Sécurisé : Stockez toujours les sauvegardes en dehors du cluster Kubernetes lui-même, dans un emplacement sécurisé et idéalement géographiquement distinct.
• Tests de Restauration : La partie la plus importante d'une stratégie de sauvegarde est de tester régulièrement la restauration. Une sauvegarde non testée n'est pas fiable. Testez différents scénarios (restauration complète, restauration partielle, restauration d'application).
• Monitoring : Surveillez l'état de vos travaux de sauvegarde. Assurez-vous qu'ils se terminent avec succès et investiguez rapidement les échecs.
• Documentation : Documentez clairement vos procédures de sauvegarde et, surtout, de restauration. En situation de crise, une documentation claire est inestimable.