Pourquoi l’IA pousse le stockage Kubernetes au-delà des limites du CSI
À mesure que les entreprises déploient des applications intensives en données et des charges AI dans des environnements Kubernetes, l’interface standard de stockage – CSI – montre ses limites face aux exigences métier modernes. Les besoins en protection des données, conformité et continuité d’activité nécessitent des services complémentaires.
Du stateless aux applications avec état
À l’apparition de Kubernetes, la plupart des charges conteneurisées étaient sans état. Des applications comme NGINX ou Node.js pouvaient être recréées à partir de métadonnées sans stocker de données persistantes. Ce modèle favorise la fiabilité et la simplicité opérationnelle.
Cependant, comme le notent les auteurs de « Kubernetes: Up and Running », presque tout système complexe contient de l’etat quelque part – des lignes de base de données aux shards d’index. Intégrer ces données aux conteneurs et à l’orchestration reste l’une des parties les plus difficiles du développement distribué.
L’impact de l’IA et la montée des applications stateful
L’adoption rapide de l’IA en entreprise a accéléré le déploiement d’applications stateful dans Kubernetes : bases de données conteneurisées telles que Cassandra, Redis, PostgreSQL, MySQL ou Kafka sont devenues plus courantes. L’IA est, comme le résume Phil Winder, issue de la data science : la donnée est au coeur de ces initiatives.
La donnée est également essentielle pour des cas d’usage plus traditionnels : recommandations personnalisées, analytics utilisateurs, sécurité, observabilité, IoT et edge. Selon l’analyste Gartner Julia Palmer, « By 2027, 80% of Kubernetes deployments will require advanced features for persistent containers storage, compared to 30% in early 2023. »
Comprendre le CSI, fondation du stockage Kubernetes
Le Container Storage Interface (CSI) est le mécanisme standard pour la persistance dans Kubernetes. Il expose des APIs permettant aux applications d’effectuer des lectures et écritures vers le système de stockage sous-jacent. Chaque fournisseur implante son propre driver CSI – Nutanix CSI, Dell CSI, Red Hat OpenShift CSI, Portworx CSI, etc. – et propose des attributs spécifiques via le mécanisme d’extension du CSI.
Par exemple, Nutanix CSI provisionne Nutanix Unified Storage (NUS), une plateforme logicielle consolidant fichiers, objets et blocs dans une solution dense et optimisée selon les besoins clients.
Limites du CSI pour les charges d’entreprise
Le CSI convient pour fournir un stockage persistant à un cluster unique, mais il ne couvre pas certains besoins critiques : protection des données, continuité d’activite et reprise après sinistre (BCDR). Ces exigences sont particulièrement sensibles dans les secteurs régulés comme la finance ou la santé, où la localisation et la résidence des données sont contraintes par la réglementation.
Pour garantir performance et conformité, les données doivent résider au plus proche de l’emplacement d’exécution des applications, ce qui impose des mécanismes de réplication pour la BCDR, la répartition de charge et la haute disponibilité. Les architectures hétérogènes – par exemple le cloud bursting depuis un datacenter vers un cloud public pour absorber des pics – requièrent une réplication rapide et cohérente des environnements applicatifs et de leurs données.
Réplication synchrone vs asynchrone
- Réplication synchrone – les écritures sont reproduites simultanément sur le serveur principal et les réplicas. Avantage : pas de perte de données en cas de défaillance. Inconvénient : exige une bande passante importante et une faible latence.
- Réplication asynchrone – les données sont d’abord écrites sur le serveur principal puis copiées vers les réplicas selon une politique de protection définie (fréquence et rétention). Avantage : moins coûteuse en bande passante. Inconvénient : risque de perte de données entre deux réplications.
Combler les lacunes avec des services de données
Nutanix Data Services for Kubernetes (NDK) illustre l’approche visant à compléter le CSI. NDK permet de gérer VMs et applications conteneurisées depuis une plateforme unifiée, en s’appuyant sur des mécanismes Kubernetes familiers : distribution via un chart Helm et interaction via kubectl. Les services sont indépendants de la distribution Kubernetes – ils fonctionnent avec OpenShift, Amazon EKS Anywhere ou d’autres distributions.
NDK prend en charge la réplication synchrone et asynchrone. L’asynchrone peut être configuré avec une fréquence maximale d’une copie par heure, et la politique s’applique au niveau de l’application, pas du cluster – ce qui permet à des applications différentes dans un même cluster d’adopter des stratégies de protection distinctes.
La réplication asynchrone est adaptée aux scénarios BCDR, par exemple entre deux datacenters situés dans des pays différents – basculement vers le site secondaire en cas de sinistre majeur. La réplication synchrone, elle, garantit zéro perte de données mais exige une proximité physique suffisante entre sites (latence très faible), ce qui la rend inadaptée pour se protéger contre des catastrophes naturelles distantes.
Exemple client : un opérateur de croisières exploite deux salles informatiques proches, reliées par un réseau haut débit avec une latence inférieure à 10 ms. En cas de panne d’une salle (coupure de courant, inondation), les services basculent vers l’autre sans interruption.
Conclusion – vers une plateforme unifiée
La convergence des machines virtuelles et des conteneurs dans une plateforme unifiée devient une nécessité pratique pour les entreprises qui déploient des applications distribuées et gourmandes en données. Le CSI fournit la base du stockage persistant, mais pour répondre aux exigences d’entreprise en matière de protection des données, conformité et flexibilité opérationnelle, des services complémentaires comme NDK sont essentiels. NDK est intégré à la Nutanix Kubernetes Platform (NKP), qui rassemble infrastructure, orchestration Kubernetes, stockage, services de données et gestion du cycle de vie applicatif dans une même solution.
