Comment garder son calme quand votre cluster Kubernetes plante, ou pourquoi vous avez besoin de Velero

Imaginez la scène : c'est vendredi soir, vous prévoyez de vous détendre, quand soudain une notification Slack apparaît — l'un de vos clusters Kubernetes de production a rendu l'âme. Une mauvaise configuration, une panne de fournisseur cloud, ou simplement une erreur humaine — la cause n'a plus d'importance. Ce qui compte, c'est la rapidité avec laquelle vous pouvez tout remettre en marche. Si vous n'avez que des fichiers YAML dans Git, bonne chance pour récupérer les applications avec état et leurs données.

C'est là qu'intervient Velero. C'est un projet de VMware (à l'origine créé par Heptio) qui est devenu la norme de facto pour la sauvegarde dans le monde K8s.

Ce que c'est et pourquoi GitOps seul ne suffit pas

De nombreux développeurs pensent que si leur infrastructure entière est définie en code (IaC) et déployée via ArgoCD ou Flux, les sauvegardes sont inutiles. C'est une dangereuse misconception. Git stocke les manifests, mais il ne sait rien de l'état de vos Persistent Volumes (PV), des certificats émis dynamiquement, ou des secrets qui n'ont jamais été intégrés au dépôt.

Velero fait deux choses : il sauvegarde les objets de l'API Kubernetes (deployments, configmaps, secrets) et prend des instantanés de disque avec les données. Il fonctionne dans les clouds publics (AWS, GCP, Azure) ainsi que dans les centres de données on-premises sur bare metal.

Trois scénarios où Velero sauve la mise

Je vois souvent Velero utilisé non seulement pour la protection contre les catastrophes. Voici les cas d'usage principaux :

1. Récupération après sinistre classique. C'est simple : le cluster est mort, vous en lancez un nouveau, et vous restaurez tout depuis le stockage S3 avec une seule commande.
2. Migration inter-cloud. Passer d'AWS à Google Cloud ou d'une région à une autre devient une tâche triviale. Velero empaquète les ressources et les déploie au nouvel emplacement.
3. Clonage d'environnement. Besoin de créer rapidement une copie exacte de la production pour les tests ? Vous faites une sauvegarde prod, vous la restaurez dans le namespace staging. Les données de la base seront à jour, pas celles d'un dump d'il y a un mois.

Comment ça fonctionne en interne

L'architecture du projet est assez transparente. Il y a un composant serveur qui s'exécute à l'intérieur du cluster en tant qu'opérateur, et un client CLI pour gérer le processus.

Quand vous déclenchez une sauvegarde, voici ce qui se passe :

1. Le client envoie une requête à l'API Velero.
2. Le contrôleur de Backup trouve tous les objets que vous avez spécifiés (vous pouvez filtrer par labels ou namespaces).
3. Velero fait des requêtes à l'API Kubernetes pour collecter les descriptions JSON des ressources.
4. En parallèle, les plugins de gestion des disques sont invoqués (ex. EBS sur AWS ou les drivers CSI) pour créer des instantanés de données.
5. Tout cela est archivé et envoyé vers le stockage objet (compatible S3).

Au fait, Velero supporte Restic et Kopia. Cela signifie que vous pouvez faire des sauvegardes incrémentielles du système de fichiers même là où les instantanés cloud ne sont pas disponibles.

Exemple pratique

Disons que nous devons sauvegarder une application entière dans le namespace app-production. La commande terminal ressemblerait à ceci :

velero backup create production-backup --include-namespaces app-production

Et si quelqu'un supprime accidentellement ce namespace une semaine plus tard, la récupération ne prend que quelques minutes :

velero restore create --from-backup production-backup

Il est intéressant de noter que Velero peut modifier les paramètres des ressources à la volée pendant la restauration. Par exemple, vous pouvez changer le StorageClass des disques si l'ancienne classe n'est pas disponible dans le nouveau cluster.

Nuances de compatibilité

Les développeurs de Velero maintiennent une matrice de compatibilité assez stricte. Actuellement, la version 1.18 est testée contre les dernières versions de Kubernetes (jusqu'à 1.35). C'est important car l'API Kubernetes évolue rapidement, et les anciens outils cassent souvent quand le cluster est mis à niveau.

Le projet est sous l'égide de la Cloud Native Computing Foundation (CNCF), ce qui offre certaines garanties : il ne disparaîtra pas demain, et sa sécurité est surveillée.

Faut-il l'implémenter

Si vous utilisez Kubernetes en production et avez des données sur des disques (bases de données, queues, config stores), Velero est indispensable.

Qui bénéficiera certainement de cet outil :

• Les ingénieurs SRE qui ont besoin de dormir tranquilles la nuit.
• Les équipes qui migrent fréquemment entre clusters.
• Les développeurs qui ont besoin de données de production fraîches pour déboguer des bugs complexes.

Commencez par la documentation officielle sur velero.io. Elle est assez détaillée, bien qu'elle puisse sembler écrasante parfois. L'essentiel à retenir est qu'une sauvegarde n'existe que quand vous l'avez restaurée avec succès au moins une fois. Essayez de le faire dans un cluster de test avant de faire confiance à l'outil avec de vraies données.