Remarque perev. : Nous avons d'abord parlé des plug-ins de stockage appelés Kubernetes (Out-of-Tree CSI Volume Plugins) dans notre revue de la version K8s 1.9 , où cette fonctionnalité apparaissait en version alpha. L'auteur du nouveau matériel, Anoop Vijayan Maniankara (principal ingénieur DevOps de la société finlandaise Tuxera), a rassemblé des informations clés sur les idées et le dispositif CSI, ce qui permet de se familiariser rapidement avec le nouveau concept qui, selon certains de nos employés, «sera la prochaine grande chose». Pour une étude plus détaillée et technique de CSI, des liens utiles sont donnés à la fin de l'article, parmi lesquels je souligne notamment la présentation de l'un des auteurs de cette spécification (Jie Yu). Mais ça vaut quand même le coup d’avoir une vue d’ensemble…
L'interface de stockage de conteneurs (CSI) est une initiative visant à unifier l'interface des stockages, tels que Ceph, Portworx, NetApp, etc., dans les systèmes d'orchestration de conteneurs: Kubernetes, Mesos, Docker Swarm, Cloud Foundry et autres. L'idée est que la mise en œuvre d'un CSI par le fabricant de stockage est garantie pour fonctionner avec tous ces systèmes.
Source de l'image: rapport Jie Yu CSI à CloudNativeCon EU 2018Remarque : cet article ne parlera que de l'approvisionnement dynamique. Les volumes préconfigurés et les volumes flexibles dépassent sa portée. Si vous voulez mieux comprendre ce qui sera discuté, vous devez d'abord lire la documentation de Kubernetes . De plus, l'article n'entre pas dans les détails de l'implémentation de CSI. Je fournirai un aperçu de haut niveau de CSI et jetterai les bases de la création d'un volume CSI. Enfin, les informations Kubernetes sont utilisées pour des exemples et des liens vers des détails.Avant de plonger dans le sujet, il est également important de savoir ce que sont les conteneurs side-car dans Kubernetes. Ils étendent les capacités du conteneur principal (
principal ), existant dans le même foyer, partageant le stockage et le réseau.
Au moment d'écrire ces lignes
(13 août 2018), les composants CSI avaient les versions suivantes:

Avant CSI
La première version de CSI - v0.1 - a eu lieu en décembre 2017. Bien entendu, le provisionnement peut être effectué pour le stockage externe dans les systèmes d'orchestration avant même qu'il n'apparaisse. Dans le cas de Kubernetes, les plugins de volume - les plugins de volume étaient responsables des besoins de stockage:

Comme vous pouvez le voir sur l'image ci-dessus, ces plugins font partie du cœur du système d'orchestration. Pour cette raison, les problèmes suivants se sont produits et ont été mentionnés dans le
document d'architecture CSI :
- Le développement du plugin de volume est étroitement lié et dépend des versions de Kubernetes.
- Les développeurs / communauté Kubernetes sont responsables de tester et de prendre en charge tous les plugins au lieu de simplement tester et maintenir une API de plugin stable;
- les bogues dans les plugins de volume peuvent supprimer non seulement le plugin lui-même, mais aussi les composants critiques de Kubernetes;
- les plugins obtiennent tous les privilèges des composants Kubernetes (kubelet et kube-controller-manager);
- les développeurs de plugins sont obligés de publier le code source du plugin et ne peuvent pas choisir le chemin des binaires.
Comprendre CSI
En présentant CSI, l'équipe Kubernetes a publié des composants externes qui ne font pas partie du noyau et sont conçus pour interagir avec d'autres composants externes fournis par les fabricants. Ils communiquent
entre eux via des sockets de domaine
(sockets de domaine UNIX - environ. Transl.) À l'aide de
gRPC .

Composants externes de Kubernetes
Ils sont entièrement mis en œuvre et soutenus par l'équipe de Kubernetes et étendent les activités de Kubernetes en dehors de Kubernetes. Les fabricants ne peuvent pas du tout s'inquiéter des caractéristiques de leur mise en œuvre. Composé de trois parties:
- Le registraire de pilote est un conteneur de sidecar qui enregistre le pilote CSI dans kubelet et ajoute le pilote
NodeId
à l'étiquette d'objet de nœud dans l'API Kubernetes. Pour ce faire, il interagit avec le service de pilote Identity CSI (pour plus de détails, voir ci-dessous - environ Transl.) Et appelle GetNodeId
sur CSI; - Provisionneur externe - un conteneur sidecar qui surveille les objets PersistentVolumeClaim dans l'API Kubernetes et appelle les
DeleteVolume
CreateVolume
et DeleteVolume
pour le pilote de point de terminaison; - L'attacheur externe est un conteneur de sidecar qui surveille les objets VolumeAttachment dans l'API Kubernetes et appelle les
ControllerPublish
et ControllerUnpublish
pour le pilote de point de terminaison.
Composant externe du fabricant de stockage / tiers
Implémentation spécifique au fournisseur. Chaque fabricant implémente les API nécessaires dans le cadre des fonctions de service gRPC. Par exemple, une implémentation de
GCE PD ou
Ceph , etc. Ils se composent également de trois éléments:
- Identité CSI - principalement pour identifier un plug-in: assurez-vous qu'il fonctionne, renvoyez des informations de base sur le plug-in;
service Identity { // rpc GetPluginInfo(GetPluginInfoRequest) returns (GetPluginInfoResponse) {} // , Controller rpc GetPluginCapabilities(GetPluginCapabilitiesRequest) returns (GetPluginCapabilitiesResponse) {} // , , rpc Probe (ProbeRequest) returns (ProbeResponse) {} }
( kubernetes-csi-identity.proto ) - Le contrôleur CSI est responsable du contrôle et de la gestion des volumes: création, suppression, connexion / déconnexion, instantanés, etc.;
service Controller { // provisioning rpc CreateVolume (CreateVolumeRequest) returns (CreateVolumeResponse) {} // rpc DeleteVolume (DeleteVolumeRequest) returns (DeleteVolumeResponse) {} // rpc ControllerPublishVolume (ControllerPublishVolumeRequest) returns (ControllerPublishVolumeResponse) {} // rpc ControllerUnpublishVolume (ControllerUnpublishVolumeRequest) returns (ControllerUnpublishVolumeResponse) {} // , / rpc ValidateVolumeCapabilities (ValidateVolumeCapabilitiesRequest) returns (ValidateVolumeCapabilitiesResponse) {} // rpc ListVolumes (ListVolumesRequest) returns (ListVolumesResponse) {} // rpc GetCapacity (GetCapacityRequest) returns (GetCapacityResponse) {} // , GetCapacity Snapshotting rpc ControllerGetCapabilities (ControllerGetCapabilitiesRequest) returns (ControllerGetCapabilitiesResponse) {} // rpc CreateSnapshot (CreateSnapshotRequest) returns (CreateSnapshotResponse) {} // rpc DeleteSnapshot (DeleteSnapshotRequest) returns (DeleteSnapshotResponse) {} // rpc ListSnapshots (ListSnapshotsRequest) returns (ListSnapshotsResponse) {} }
( kubernetes-csi-controller.proto ) - Le nœud CSI est responsable de la surveillance de l'activité du volume sur l'hôte Kubernetes.
service Node { // staging- rpc NodeStageVolume (NodeStageVolumeRequest) returns (NodeStageVolumeResponse) {} // staging- rpc NodeUnstageVolume (NodeUnstageVolumeRequest) returns (NodeUnstageVolumeResponse) {} // staging rpc NodePublishVolume (NodePublishVolumeRequest) returns (NodePublishVolumeResponse) {} // rpc NodeUnpublishVolume (NodeUnpublishVolumeRequest) returns (NodeUnpublishVolumeResponse) {} // rpc NodeGetVolumeStats (NodeGetVolumeStatsRequest) returns (NodeGetVolumeStatsResponse) {} // ID rpc NodeGetId (NodeGetIdRequest) returns (NodeGetIdResponse) { option deprecated = true; } // (capabilities) rpc NodeGetCapabilities (NodeGetCapabilitiesRequest) returns (NodeGetCapabilitiesResponse) {} // NodeGetId rpc NodeGetInfo (NodeGetInfoRequest) returns (NodeGetInfoResponse) {} }
( kubernetes-csi-node.proto )
Conclusion
L'avènement de CSI a apporté un avantage évident aux systèmes d'orchestration et aux fabricants de stockage. De plus, des interfaces bien définies aident à l'implémentation et aux tests simples de CSI pour les développeurs et les futurs systèmes d'orchestration. Si vous décidez de commencer à implémenter votre CSI après avoir lu cet article,
comment écrire un plugin CSI (Container Storage Interface) de Fatih Arslan
est un bon point de départ.
Les références
- Spécification CSI ;
- Conteneurs Sidecar à Kubernetes ;
- Jie Yu CSI report à KubeCon EU: CloudNativeCon EU 2018 (et voici la vidéo de cette présentation - environ trad.) ;
- Document d'architecture CSI
- Documentation actuelle sur CSI de Kubernetes ;
- Documentation CSI Kubernetes obsolète .
PS du traducteur
Lisez aussi dans notre blog: