Kubernetes : comment fonctionnent les pilotes de stockage CSI ?

Les pilotes CSI permettent aux administrateurs de déployer du stockage persistant sur les clusters Kubernetes, en réintégrant dans ce dernier toutes les fonctions d’une baie de disques ou d’un service en ligne.

La mise en production des applications au format container présente de nombreux avantages, notamment la possibilité de segmenter ces applications en microservices indépendants pour obtenir des cycles de développement plus rapides. Néanmoins, ce format peut également ajouter de la complexité aux applications plus traditionnelles, notamment celles qui ont besoin de sauvegarder des fichiers. Les pilotes CSI – pour interface de stockage des containers – offrent aux administrateurs la flexibilité dont ils ont besoin pour conjuguer stockage et environnements de containers.

Les containers accélèrent et rationalisent le processus de développement, en offrant une approche légère pour virtualiser les ressources et établir des environnements aux performances stables. Kubernetes et les orchestrateurs de containers similaires peuvent étendre à volonté de tels déploiements applicatifs selon l’activité, équilibrer la charge entre les instances et automatiser les mises à jour comme les retours à une version précédente.

Quand ils administrent des environnements en containers, les équipes DevOps et les administrateurs s’appuient sur les pilotes CSI pour les interconnecter de manière transparente avec diverses infrastructures de stockage. Aujourd’hui, plus de 60 pilotes CSI sont disponibles pour une variété de solutions dédiées au stockage de fichiers, au stockage bloc ou au stockage objet et, ce, qu’il s’agisse d’équipements sur site comme de services en ligne. En utilisant un pilote CSI, les administrateurs peuvent déployer le type de stockage persistant qu’ils préfèrent, indépendamment de l’orchestrateur, des entrées-sorties et des fonctionnalités connexes (snapshots, réplication…).

Stockage persistant avancé, Kubernetes et CSI

Kubernetes est un descendant de Borg, un orchestrateur de containers développé par les ingénieurs de Google et qui a ouvert la voie à la mise en Open source de Kubernetes en 2014. Cette plateforme portable et extensible suit une architecture client-serveur qui se compose, d’une part, d’un plan de contrôle et, d’autre part, de clusters de nœuds qui exécutent des tâches containerisées. Kubernetes orchestre les charges de travail en plaçant les containers dans des pods et en les exécutant sur des serveurs virtuels ou physiques.

Pour les fournisseurs de solutions de stockage, l’intégration de Kubernetes a nécessité des efforts considérables. Initialement, la plateforme utilisait une arborescence de plug-ins pour gérer les volumes et ceux-ci étaient intégrés directement dans le binaire de Kubernetes. Cette approche a posé quantité d’obstacles. Par exemple, l’ajout d’une nouvelle application de stockage nécessitait de certifier son code dans le dépôt central de Kubernetes. Cela complexifiait l’intégration et limitait le stockage.

En plus de ces obstacles pratiques à l’intégration des plug-ins, l’approche en arborescence limitait les corrections de bugs ou leurs solutions palliatives. Elle a également augmenté la possibilité d’introduire des failles dans le code, qui étaient susceptibles de déstabiliser la plateforme Kubernetes tout entière.

Bref, cela n’allait pas. Les utilisateurs devaient pouvoir concevoir des plug-ins basés sur des spécifications simplifiées qui ne dépendaient pas du cycle de vie de Kubernetes. En conséquence, Google a introduit CSI pour permettre aux utilisateurs d’exposer de nouveaux systèmes de stockage sans jamais avoir à toucher au code central de Kubernetes.

Évaluation des implémentations de pilotes CSI pour Kubernetes

Aujourd’hui, les fournisseurs de stockage utilisent le modèle CSI pour écrire leurs plug-ins. Grâce à des spécifications simples, ils peuvent éliminer la dépendance au cycle de publication de Kubernetes et mettre à jour leurs pilotes à tout moment. Ces pilotes CSI fournissent trois services principaux :

  • identifier les plug-ins et leurs capacités spécifiques ;
  • contrôler les opérations au niveau du cluster pour les processus externes
  • définir les opérations des serveurs et des containers.

La principale utilisation de CSI est l’abstraction de la solution de stockage, de sorte que les administrateurs peuvent utiliser cette solution lorsqu’ils administrent des PersistentVolumeClaims (PVC), des PersistentVolumes (PV) et des classes de stockage de Kubernetes.

Le framework PVC désigne les demandes de stockage des utilisateurs et définit les exigences de stockage spécifiques à un pod, telles que la capacité ou le partage des données. Pour exécuter un pod, les développeurs installent sur le serveur sous-jacent un agent appelé kubelet qui peut lancer et maintenir des pods sur ce serveur.

Les administrateurs attribuent ensuite une classe de stockage qui indique le stockage externe et utilisent les pilotes CSI pour approvisionner cette classe. Une fois qu’une classe de stockage est spécifiée, le PVC déclenche le provisionnement dynamique. Le stockage externe s’appuie sur le pilote CSI pour invoquer la création de volumes. Ce PV spécifique est alors lié au PVC.

Le protocole de communication entre l’orchestrateur et les plug-ins, qui exécute tous ces processus, est gRPC. Il s’agit d’un framwork Open source d’appel de procédures à distance. Le contrôleur CSI contrôle les fonctions de bas niveau, telles que le provisionnement du stockage sur un matériel donné (une baie de disques…) ou encore la création de snapshots pour les volumes.

Comment déployer un pilote CSI pour Kubernetes ?

Les développeurs peuvent monter le plug-in du contrôleur sur n’importe quel nœud d’un cluster et, ce, de deux manières. Soit en le déployant avec le système de gestion des versions de Kubernetes, celui qui sert à déployer automatiquement les mises à jour ou les retours en arrière. Soit en tant que StatefulSet, c’est-à-dire qui fait partie intégrante de l’attirail de fonctions à déployer lorsque l’on étend des pods.

Le plug-in interagit avec les objets Kubernetes comme un container latéral. Il lance des appels au service de contrôleur CSI, puis exécute toutes les opérations via l’API Kubernetes et le plan de contrôle externe du cluster spécifié. Ces types d’échanges automatiques aident les développeurs à se concentrer sur la programmation plutôt que sur la résolution de la complexité du stockage.

Schéma de la relation entre un client et un microservice.
Relation entre un client et un microservice.

Pour les équipes informatiques, la plateforme Kubernetes propose des recommandations pour simplifier les déploiements de pilotes CSI. Cependant, il faut garder à l’esprit que l’installation des pilotes est différente pour chaque fournisseur, en particulier pour les déploiements en cloud utilisant Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) ou Google Kubernetes Engine (GKE). Une fois qu’une équipe a choisi une approche, il est essentiel de bien comprendre la composition de l’environnement d’hébergement.

En général, la façon dont les équipes de développement utilisent les pilotes CSI reste uniforme dans tous les déploiements. Par exemple, il est courant de créer à l’intérieur d’un cluster Kubernetes un StorageClass qui pointe vers le CSI.

Pour approfondir sur Administration du stockage

Close