Les déploiements Kubernetes présentent de nombreux avantages pour les entreprises souhaitant moderniser leur infrastructure et adopter une architecture cloud-native.
Cependant, plusieurs éléments qui rendent Kubernetes attrayant pour les développeurs et les directeurs informatiques peuvent également engendrer des problèmes potentiels en matière de sauvegarde et de récupération après sinistre (DR).
Les applications monolithiques traditionnelles et même les machines virtuelles (VM) sont relativement simples à sauvegarder et à intégrer dans un plan de récupération après sinistre, à condition que cela soit fait avec soin. En revanche, Kubernetes et les conteneurs, avec leurs microservices interconnectés, leurs applications sans état et leur stockage persistant, fonctionnent différemment. La récupération après sinistre doit en tenir compte.
Pourquoi la DR est-elle nécessaire pour Kubernetes ?
De plus en plus, les conteneurs et Kubernetes sont utilisés en production, ce qui signifie que Kubernetes est souvent responsable de données critiques et de processus commerciaux essentiels.
Les organisations doivent protéger les données ainsi que les différents microservices qui composent une application basée sur Kubernetes, tout en s’assurant qu’elles peuvent les récupérer de manière précise et rapide.
Les équipes informatiques doivent garantir que tous les éléments essentiels d’un déploiement Kubernetes sont couverts par le plan de récupération après sinistre. Il ne s’agit pas seulement de protéger le stockage persistant avec des sauvegardes standard et immuables ; il est crucial de protéger l’ensemble du cluster, ses composants et ses données pour permettre une restauration fluide. Tout cela nécessite également des tests réguliers.
Quels sont les défis de la DR pour Kubernetes ?
La DR pour les clusters Kubernetes implique l’identification et la protection des composants du cluster ainsi que de sa configuration.
Ensuite, il y a les volumes de données. De plus en plus, les données Kubernetes sont stockées sur des systèmes de stockage persistants, ce qui facilite quelque peu la tâche de l’équipe de récupération après sinistre. Cependant, les spécialistes de la DR doivent être conscients de l’emplacement de stockage des données des applications basées sur Kubernetes, car elles peuvent être réparties sur des systèmes de stockage locaux, cloud et hybrides.
La bonne nouvelle, selon l’analyste de Gartner, Tony Iams, est que les applications conteneurisées possèdent des caractéristiques qui facilitent la récupération après sinistre et la continuité des activités, même si la sauvegarde granulaire est plus complexe.
« La portabilité et l’immuabilité inhérentes aux conteneurs facilitent la réplication cohérente d’une pile d’application complète à plusieurs emplacements », explique-t-il. « Grâce aux processus d’intégration continue et de déploiement continu (CI/CD), les applications conteneurisées peuvent être facilement reconstruites et livrées là où et quand elles sont nécessaires, que ce soit sur un site secondaire ou pour reconstruire un site principal après une défaillance. »
Quels sont les risques pour les environnements Kubernetes à atténuer par la DR ?
Les risques auxquels Kubernetes est confronté sont similaires à ceux de tout autre environnement technologique d’entreprise : défaillance matérielle, problèmes logiciels – y compris ceux du système d’exploitation Linux sous-jacent –, pannes d’alimentation ou de réseau, catastrophes physiques et, bien sûr, cyberattaques, y compris les ransomwares.
Cependant, la flexibilité et la nature distribuée des conteneurs peuvent rendre les applications vulnérables à des points de défaillance uniques ; les architectures distribuées peuvent amplifier l’impact des pannes matérielles.
Une entreprise pourrait, par exemple, répliquer une machine virtuelle entière ou créer un instantané immuable, en étant raisonnablement confiante d’avoir capturé tout ce qui est nécessaire pour faire fonctionner une application ou un processus commercial. Avec Kubernetes, il existe davantage de dépendances.
Iams souligne que la manière dont les applications conteneurisées gèrent le stockage constitue un risque spécifique. Contrairement aux applications conventionnelles qui utilisent le système de fichiers de l’OS hôte, « les conteneurs persistent les données à l’aide de volumes qui écrivent des données sur un stockage externe au système de fichiers local du conteneur », dit-il.
Si les conteneurs se trouvent dans des clusters Kubernetes, les équipes informatiques doivent s’assurer que les manifestes et autres configurations de politique sont sauvegardés, et que les conteneurs peuvent se reconnecter à leur stockage après une restauration.
Quels sont les points clés d’un plan de DR pour un environnement Kubernetes ?
Une récupération après sinistre réussie pour un environnement Kubernetes sera généralement plus granulaire qu’un plan de récupération pour des applications conventionnelles.
Les entreprises peuvent réduire les temps d’arrêt et la perte de données, à condition de pouvoir récupérer des parties spécifiques du système Kubernetes plutôt que des clusters entiers. Chaque partie d’un environnement Kubernetes pourrait avoir ses propres objectifs de point de récupération et de temps de récupération (RPO/RTO).
Cela nécessite cependant que les équipes informatiques aient une vue d’ensemble complète et à jour de leurs composants Kubernetes et des processus commerciaux qu’ils soutiennent.
Comme pour un plan de DR pour des environnements traditionnels, une approche consiste à prioriser les services qui doivent être restaurés en premier.
Il est utile de poser deux questions liées :
- Quelles applications basées sur Kubernetes sont les plus critiques pour les opérations commerciales et doivent donc être remises en ligne en premier ?
- Quels services et dépendances (Kubernetes) permettront de ramener ces conteneurs le plus rapidement possible ?
Bien fait, cela pourrait permettre à une organisation de remettre ses applications en ligne, peut-être avec une fonctionnalité réduite, plus rapidement que si elle s’appuyait sur la restauration d’un cluster entier.
L’approche exacte dépendra probablement de la maturité de l’organisation et de son approche du risque.
« À ce stade, les ingénieurs d’infrastructure cloud-native et traditionnels ont des points de vue différents sur la meilleure façon d’aborder le problème », déclare Iams. « Les ingénieurs cloud-native privilégient les méthodes de redéploiement via des workflows CI/CD, tandis que les approches traditionnelles s’appuient sur des outils de sauvegarde et de récupération pour les applications Kubernetes et la protection des données. » La société d’analyse recommande une approche centrée sur l’application si l’organisation est suffisamment mature.
Quelles sont les exigences d’infrastructure pour la DR de Kubernetes ?
En ce qui concerne l’infrastructure physique, la flexibilité de Kubernetes devrait faciliter la récupération d’une application. Cela peut se faire à partir de matériel sur site vers le cloud, ou même en passant d’un fournisseur de cloud à un autre.
Les spécialistes de la DR doivent s’assurer que les ressources nécessaires sont disponibles. Cela inclut les exigences de calcul pour exécuter les clusters Kubernetes et l’espace de stockage pour récupérer les volumes persistants. Des ressources réseau appropriées sont également essentielles.
Pour la récupération des applications, si les équipes informatiques ont utilisé une approche GitOps centrée sur l’application, elles peuvent utiliser ArgoCD ou Flux CD pour la récupération.
Sinon, la meilleure approche sera probablement un outil d’un fournisseur spécialisé dans Kubernetes, tel que Kasten, Trilio, CloudCasa ou Cohesity (qui possède également l’activité de protection des données de Veritas). Des fournisseurs comme Commvault et Rubrik prennent également en charge les conteneurs et les applications cloud-native.
Ces outils « conscients de Kubernetes » se déploient sur des clusters et comprennent comment les clusters composent une application – et comment les restaurer en cas de panne.
