Sauvegarde Kubernetes : protection des charges de travail natives du cloud

Le client qui avait sauvegardé tous ses nœuds

La première fois que j’ai vu un client tenter de restaurer un cluster Kubernetes à partir de la sauvegarde de sa machine virtuelle, j’ai compris que les discussions de l’année à venir consisteraient à expliquer pourquoi les conteneurs ne fonctionnent pas de la même manière que les machines virtuelles. Nous avons dû passer en revue le contenu réel de la sauvegarde, ce qui manquait et ce que cela impliquait pour leur RTO.

Le client pensait être protégé. Il disposait de sauvegardes de chaque nœud du cluster. Il n’avait pourtant aucun moyen de restaurer la charge de travail. La sauvegarde avait capturé les machines virtuelles sous-jacentes exécutant Kubernetes. Elle n’avait pas capturé la configuration des espaces de noms, les manifestes YAML, les ConfigMaps et les Secrets, ni l’état d’etcd qui enregistrait ce qui devait exister. Ils disposaient de l’infrastructure de base. Il leur manquait l’application. 

Voici ce que je dirais à cette équipe si je pouvais revenir en arrière et avoir cette conversation avant l’incident.

Ce qu’est réellement la sauvegarde Kubernetes

La sauvegarde Kubernetes consiste à capturer et à restaurer les applications conteneurisées, leur état persistant, ainsi que de la configuration Kubernetes qui définit leur mode de fonctionnement, de manière à permettre la restauration complète de la charge de travail sur le même cluster, un autre cluster ou un autre cloud.

Cette distinction est importante, car la charge de travail dans Kubernetes ne se limite pas aux conteneurs en cours d’exécution. Elle inclut les volumes persistants (PV) dans lesquels les applications avec état stockent leurs données, l’espace de noms où réside la charge de travail, les manifestes YAML qui définissent les Deployments et les StatefulSets, les ConfigMaps et les Secrets qui contiennent la configuration spécifique à l’environnement, les définitions de ressources personnalisées (CRD) qui étendent l’API, ainsi que l’état etcd qui consigne ce que le cluster considère comme devant exister. Une sauvegarde qui ne capture que les volumes persistants peut restaurer les données, mais ne peut pas restaurer l’application en cours d’exécution. Une sauvegarde qui ne capture que les manifestes YAML peut restaurer la structure, mais pas l’état. Ces deux cas de figure sont courants. Les deux sont insuffisants.

L’adoption de charges de travail de production conteneurisées n’est plus une hypothèse. Google lance des milliards de conteneurs par semaine sur sa propre infrastructure. Pour la plupart des équipes chargées des plateformes d’entreprise, la question n’est plus de savoir si les charges de travail Kubernetes ont besoin d’une sauvegarde, mais comment l’architecturer correctement. 

Pourquoi les conteneurs nécessitent-ils une sauvegarde différente de celle des machines virtuelles ?

Les machines virtuelles et les conteneurs présentent suffisamment de points communs pour que certains principes de sauvegarde soient transposables. Les deux sont des abstractions virtualisées. Les deux exposent des API pour les opérations de snapshot. Les données de sauvegarde restent des données de sauvegarde, quelle que soit leur source. Une plateforme de sauvegarde peut raisonnablement stocker les sauvegardes des deux dans le même coffre-fort.

Le modèle opérationnel diffère sur trois points importants pour la conception de la protection des données :

1. Le stockage des machines virtuelles persiste après les arrêts. Le stockage des conteneurs n’est souvent pas persistant. Lorsqu’une machine virtuelle s’arrête, l’espace de stockage qui lui a été alloué est conservé. Lorsqu’un pod Kubernetes s’arrête, le kubelet peut récupérer ses volumes emptyDir ainsi que tout stockage non persistant.
2. Les machines virtuelles sont relativement stables. Les pods sont, par conception, éphémères. Kubernetes est conçu pour démarrer, arrêter et replanifier les pods dans le cadre d’un fonctionnement normal. Une solution de sauvegarde qui repose sur l’hypothèse de charges de travail de longue durée avec des plannings prévisibles n’est pas adaptée.
3. Les machines virtuelles exécutent une seule application. Les pods exécutent des parties d’applications. Dans Kubernetes, la limite significative d’une application est l’espace de noms ou la version Helm, et non le pod individuel. Une sauvegarde au niveau du pod fragmente l’application. 

Les cinq défis qui rendent la sauvegarde Kubernetes différente sur le plan architectural

Les analystes du Data Center Intelligence Group (DCIG) ont identifié cinq défis spécifiques que les logiciels de sauvegarde doivent relever pour protéger les environnements Kubernetes. Ce cadre s’avère pertinent et clarifie ce qui différencie la protection native de Kubernetes des outils de sauvegarde issus de l’ère des machines virtuelles.

1. Stockage éphémère

Lorsqu’un pod s’arrête, Kubernetes peut récupérer son espace de stockage. Les données sont alors effectivement perdues. Cela a deux implications pour la sauvegarde : la plateforme doit tout d’abord savoir que l’application conteneurisée existe (détection automatique, et non enregistrement manuel), et la sauvegarde doit avoir lieu pendant que l’application est en cours d’exécution, ce qui peut prendre des heures, et non des jours. Les plannings de sauvegarde basés sur des fenêtres nocturnes ne conviennent pas à des charges de travail qui pourraient ne plus exister le lendemain matin.

2. Imprévisibilité

Le kube-scheduler décide de l’emplacement d’exécution des pods en fonction de la disponibilité des ressources, des règles d’affinité, des taints et des tolérances. Il ne se base pas sur les préférences de l’opérateur. Un pod peut s’exécuter sur n’importe quel nœud d’un n’importe quel cluster à tout moment. La plateforme de sauvegarde doit suivre la charge de travail plutôt que de supposer un emplacement fixe, et elle doit prendre des décisions de protection au cas par cas pour chaque charge de travail. Tous les conteneurs n’ont pas besoin d’être sauvegardés. Certains ne nécessitent une protection qu’à des moments précis de leur cycle de vie, comme avant l’arrêt.

3. Évolutivité

Un déploiement Kubernetes en production peut exécuter des milliers de pods répartis sur des centaines d’espaces de noms. Les environnements multi-clusters portent ce chiffre à plusieurs millions. Les conteneurs sont créés et supprimés à des rythmes bien plus élevés que les machines virtuelles. Une plateforme de sauvegarde dont l’évolutivité est linéaire par rapport à l’effort de l’opérateur (enregistrement manuel, attribution manuelle des politiques, vérification manuelle) devient alors un goulot d’étranglement. La sauvegarde Kubernetes nécessite une infrastructure de sauvegarde native du cloud, à évolutivité dynamique, capable de s’adapter à la charge de travail.

4. Portée : applications et plan de contrôle

Les applications conteneurisées sont importantes, mais elles sont inutiles sans l’état du plan de contrôle qui les orchestre. etcd constitue la source de vérité du cluster. Quels Déploiements existent, quels ConfigMaps et Secrets sont associés à quelles charges de travail, quelles CRD étendent l’API, quelles règles RBAC régissent l’accès. Les environnements Kubernetes matures automatisent le plan de contrôle via GitOps et peuvent le reconstruire à la demande. Les déploiements moins matures s’appuient sur la plateforme de sauvegarde pour couvrir ces deux couches.

5. Complexité de la restauration

La restauration met en évidence tous les défis précédents d’un seul coup. La plateforme doit identifier la sauvegarde à restaurer (date, cluster, espace de noms, contexte d’application), gérer les interdépendances entre les applications conteneurisées qui peuvent devoir être lancées simultanément, et, de plus en plus souvent, effectuer la restauration dans un déploiement Kubernetes différent de celui qui a été sauvegardé. Un cluster différent, un cloud différent, une version de K8s différente, voire une distribution différente (EKS vs AKS vs GKE vs sur site). La plateforme de sauvegarde doit disposer de suffisamment d’informations sur la source et la destination pour assurer la conversion entre les deux. 

Ce qu’une sauvegarde Kubernetes complète doit protéger

Une sauvegarde Kubernetes complète couvre quatre catégories distinctes. Les outils de sauvegarde varient considérablement quant au nombre de ces catégories qu’ils prennent réellement en charge.

Le rôle des étiquettes et des métadonnées des conteneurs

Kubernetes fournit le mécanisme de protection dont la plateforme a besoin : des étiquettes et des métadonnées associées à chaque charge de travail. Lorsqu’un conteneur démarre, le service du nœud Kubernetes lit ses métadonnées existantes, ajoute des paires clé-valeur qui identifient les ressources apparentées, puis expose ces étiquettes à tout service surveillant l’API.

Une plateforme de sauvegarde bien conçue surveille les démarrages des conteneurs et lit les métadonnées en temps réel. Les étiquettes indiquent à la plateforme ce qu’il faut sauvegarder (la charge de travail répond aux critères de la politique), quand (conformément à la politique associée à ces étiquettes) et comment (quelles ressources associées doivent faire l’objet d’une capture coordonnée). La plateforme peut alors planifier des tâches de sauvegarde grâce à l’intégration de kube-scheduler, laissant Kubernetes décider lui-même où exécuter la sauvegarde, de la même manière qu’il décide où exécuter les pods.

Ce modèle diffère du modèle piloté par un opérateur utilisé par les solutions de sauvegarde traditionnelles. Dans le modèle traditionnel, c’est une personne ou un fichier de configuration qui définit ce qu’il faut sauvegarder. Dans le modèle natif de Kubernetes, la charge de travail se déclare elle-même via ses étiquettes et la plateforme de sauvegarde y répond. Les nouvelles charges de travail bénéficient automatiquement d’une protection. Les charges de travail retirées cessent de générer de la charge de sauvegarde. Le rôle de l’opérateur consiste désormais à définir des politiques, et non plus à gérer l’inventaire.

Récupération inter-clusters et Kubernetes multicloud

La récupération au sein d’un même cluster (restauration de la charge de travail dans le même cluster d’où elle provient) constitue le cas le plus simple. La plupart des déploiements Kubernetes en entreprise ne restent pas longtemps dans ce cas simple. Voici trois scénarios concrets que les plateformes de sauvegarde doivent désormais prendre en charge.

Migration des charges de travail entre EKS, AKS, GKE et les distributions sur site. Les décisions relatives au cycle de vie des clusters (optimisation des coûts, changements de région, préférences de distribution) nécessitent régulièrement de déplacer des charges de travail. Une solution de sauvegarde prenant en charge la restauration inter-distributions transforme ces migrations, qui constituaient auparavant des projets de plusieurs semaines, en opérations de routine.

Reprise après sinistre vers une autre région. En cas de défaillance de la région principale, la charge de travail de reprise est déployée dans le cluster d’une autre région, idéalement avec les mêmes données de sauvegarde, les mêmes politiques et le même plan de gestion que ceux utilisés au quotidien par l’équipe opérationnelle.

Clonage des environnements de test et de développement. La restauration de charges de travail de production (avec des données synthétiques ou anonymisées) dans des clusters de test est une exigence courante pour des tests de pré-production précis. Le même mécanisme de restauration inter-projets et inter-régions qui prend en charge la reprise après sinistre prend également en charge le clonage d’environnements.

Erreurs courantes en matière de sauvegarde Kubernetes

Le marché de la protection des données Kubernetes regorge de produits qui semblent adéquats sur le papier, mais qui échouent face à la complexité de l’environnement de production. Trois schémas à surveiller.

Erreur n° 1 : la sauvegarde limitée au stockage persistant

De nombreux outils de « sauvegarde Kubernetes » capturent des instantanés de PV et se prétendent complets. Les instantanés de PV sont nécessaires, mais ne suffisent pas. Sans configuration des espaces de noms, des manifestes YAML, des ConfigMaps, des Secrets et des ressources personnalisées définies par les opérateurs, les volumes persistants restaurés ne sont que des données dépourvues de contexte. La sauvegarde portant uniquement sur le stockage est une fonction de base utile. Ce n’est pas une stratégie de sauvegarde Kubernetes.

Erreur n° 2 : Plug-ins « bolt-on » pour les produits de sauvegarde hérités

Lorsque les fournisseurs de sauvegarde existants ont ajouté la « prise en charge de Kubernetes » entre 2019 et 2021, beaucoup ont proposé des plug-ins qui adaptaient leur architecture issue de l’ère des machines virtuelles (VM) pour appeler les API Kubernetes. Il en résulte généralement que les conteneurs sont traités comme une charge de travail distincte nécessitant une infrastructure séparée, ce qui crée précisément le cloisonnement de la protection des données que le passage à Kubernetes était censé éliminer. Comme l’a souligné Krista Macomber, d’Evaluator Group, dans son guide intitulé « Containers Data Protection Fundamentals », le fait de traiter Kubernetes comme un simple module complémentaire aboutit rarement au modèle opérationnel attendu par les équipes de la plateforme. 

Erreur n° 3 : négliger le plan de contrôle

Les entreprises utilisant GitOps qui reconstruisent leur plan de contrôle à partir du contrôle de source à la demande peuvent se passer en toute sécurité de la sauvegarde du plan de contrôle. La plupart des déploiements Kubernetes ne sont pas purement GitOps. Le cluster a accumulé des configurations appliquées manuellement, des opérateurs installés via kubectl, des CRD ne figurant pas dans le contrôle de source, ainsi que des secrets qui n’ont jamais été validés (à juste titre). Si vous perdez etcd, l’historique des déploiements du cluster disparaît. Soit la sauvegarde du plan de contrôle fait partie de la stratégie de protection, soit c’est la discipline opérationnelle autour de GitOps qui en fait partie. Pas les deux à la fois.

Questions courantes sur la sauvegarde Kubernetes

Les charges de travail sans état ont-elles besoin d’une sauvegarde ? 

Les charges de travail sans état ne contiennent pas de données d’application à sauvegarder, mais elles comportent des configurations (déploiements, ConfigMaps, définitions de services, règles Ingress) qu’il convient de conserver. Si l’espace de noms est détruit, la restauration des charges de travail sans état à partir d’images de conteneurs est rapide, mais uniquement si vous disposez des manifestes de configuration. La plupart des équipes s’en rendent compte dès la deuxième fois où elles doivent recréer un Service de mémoire après un incident au niveau du cluster.

Qu’en est-il des snapshots CSI ?

Les snapshots CSI constituent un élément de base utile que la plateforme de sauvegarde devrait utiliser en arrière-plan. Ils capturent des copies à un instant donné des volumes persistants au niveau de la couche de stockage. Mais les instantanés CSI ne constituent pas à eux seuls une stratégie de sauvegarde. Ils sont liés au backend de stockage, ne capturent pas la configuration de l’espace de noms, ne peuvent pas être transférés d’un cluster à l’autre sans outils supplémentaires et partagent généralement le sort du cluster dans lequel ils résident (si vous perdez le cluster, vous perdez les instantanés). Une plateforme de sauvegarde qui orchestre les instantanés CSI et capture le reste de la charge de travail constitue la bonne approche. 

Puis-je restaurer une sauvegarde d’une distribution Kubernetes vers une autre ?

Cela dépend de la plateforme de sauvegarde. Les distributions varient en termes d’extensions d’API, de contrôleurs d’ingress par défaut, de classes de stockage et de paramètres de sécurité par défaut. Une plateforme qui capture la charge de travail au niveau des objets Kubernetes (déploiements, services, PVC) et qui traduit les configurations spécifiques à la cible lors de la restauration peut déplacer des charges de travail entre les clusters EKS, AKS, GKE et sur site avec un effort raisonnable. Une plateforme qui capture des instantanés de stockage au niveau du fournisseur de cloud ne le peut pas. Les instantanés sont liés au fournisseur.

Par où commencer

Si vous protégez déjà Kubernetes, organisez un exercice de simulation ce trimestre. Prenez votre application conteneurisée la plus critique. Simulez la procédure que vous suivriez pour la restaurer sur un autre cluster, dans une autre région, en supposant que le cluster d’origine ne soit plus disponible. Si un membre de l’équipe utilise le mot « manuellement » au cours de cette simulation, vous avez identifié votre lacune.