Kubernetes CSI : notions de base sur les volumes CSI et comment créer un pilote CSI
Partager cette page
Yifat Perry
Qu’est-ce que Kubernetes CSI?
Kubernetes CSI est une implémentation spécifique à Kubernetes de la Container Storage Interface (CSI). La spécification CSI fournit une norme qui permet la connectivité entre les systèmes de stockage et les plateformes d’orchestration de conteneurs (CO). Elle constitue le socle de la gestion du stockage Kubernetes.
La norme CSI détermine comment des blocs arbitraires et des systèmes de stockage de fichiers sont exposés aux workloads sur les systèmes de conteneurisation comme Kubernetes. Les fournisseurs de stockage tiers peuvent utiliser CSI pour créer des plugins et les déployer afin de permettre à Kubernetes de fonctionner avec de nouveaux systèmes de stockage, sans avoir à modifier le code de base de Kubernetes.
Dans cet article
- La nécessité de CSI
- Comment utiliser un volume CSI
- Créer votre propre pilote CSI pour Kubernetes
- Stockage Kubernetes avec NetApp Cloud Volumes ONTAP
La nécessité de CSI
Avant l’interface de stockage de conteneurs, Kubernetes ne prenait en charge que les plug-ins de volume k8s de l’arborescence, qui devaient être écrits et déployés à l’aide des binaires principaux de Kubernetes. Cela signifiait que les fournisseurs de stockage devaient intégrer dans la base de code principale leurs plug-ins k8s afin de permettre la prise en charge de nouveaux systèmes de stockage.
Flex-volume, une solution basée sur des plug-ins, a tenté de résoudre ce problème en exposant l’API basée sur des exécutables à des plug-ins tiers. Bien que cette solution fonctionnait selon un principe similaire à celui de CSI en termes de détachement avec les binaires k8s, il y avait un certain nombre de problèmes avec cette approche. Tout d’abord, il nécessitait un accès root au système de fichiers maître et hôte pour permettre le déploiement des fichiers de pilote. Deuxièmement, il s’accompagnait d’une charge importante de dépendances du système d’exploitation et de conditions préalables qui étaient supposées être disponibles à partir de l’hôte.
CSI résout ces problèmes en utilisant la conteneurisation et en exploitant les primitives de stockage k8s. CSI est devenu la solution omniprésente pour permettre l’utilisation de plug-ins de stockage hors arborescence. Il permet aux fournisseurs de stockage de déployer des plug-ins via des primitives k8s standard comme les classes de stockage, PersistentVolumes (PV) et PersistentVolumeClaims (PVC).
L’objectif principal de CSI est de standardiser le mécanisme permettant d’exposer tous les types de systèmes de stockage à travers chaque orchestrateur de conteneurs.
Contenu connexe : lisez notre guide sur Kubernetes Persistent Volumes
Comment utiliser un volume CSI ?
Un volume CSI peut être utilisé pour provisionner des ressources PersistentVolume, qui peuvent être consommées par les workloads Kubernetes. Vous pouvez provisionner PersistentVolumes dynamiquement (lorsqu'ils sont demandés par un workload) ou manuellement.
Provisionnement dynamique
Vous pouvez créer un StorageClass qui fait référence à un plugin de stockage CSI. Cela permet aux workloads Kubernetes de créer dynamiquement des PersistentVolumes. Les données enregistrées sur ces PersistentVolumes sont conservées sur l’équipement de stockage défini dans le plugin CSI.
Par exemple, le StorageClass suivant permet de provisionner des volumes de stockage de type « fast-storage », à l’aide d’un plug-in CSI appelé « csi-driver.example.com ». (Cet exemple et les autres ci-dessous ont été partagés dans l’article de blog officiel Kubernetes CSI)
Lorsqu’une entité Kubernetes crée un objet PersistentVolumeClaim qui demande cette StorageClass, un PersistentVolume appartenant à la StorageClass est provisionné dynamiquement. L’image ci-dessous contient un exemple de PVC qui fait référence à la StorageClass fast-storage.
Notez que dans la définition StorageClass ci-dessus, il y a trois paramètres : type, et deux secrets appelés mysecret et mynamespace. Lorsque le PVC est déclaré, voici ce qui se passe dans les coulisses :
- Le StorageClass effectue un appel CreateVolume sur le plugin CSI (csi-driver.example.com), en transmettant les paramètres, y compris les secrets, qui permettent d’accéder au périphérique de stockage.
- Kubernetes crée automatiquement un objet PersistentVolume, représentant un volume de stockage physiquement stocké sur le périphérique du plugin CSI.
- Kubernetes lie l’objet PersistentVolume (PV) à la PersistentVolumeClaim (PVC) correspondante.
- À partir de ce moment, les pods ou conteneurs qui ont fait la demande peuvent utiliser le volume de stockage.
Lisez notre billet de blog : Provisionnement dynamique de volumes persistants Kubernetes avec NetApp Trident et Cloud Volumes ONTAP
Provisionnement manuel
Vous pouvez provisionner manuellement un volume dans Kubernetes et le mettre à disposition des workloads sans utiliser le mécanisme PVC. L’image ci-dessous fournit un exemple d’objet PV qui permet aux workloads d’utiliser un volume de stockage appelé «existingVolumeName». Comme ci-dessus, le volume CSI fait référence au plugin de stockage csi-driver.example.com.
Attachement et montage des volumes
L’image ci-dessous fournit un exemple qui montre comment un modèle de pod Kubernetes peut référencer un PVC pour accéder à un volume CSI.
Lorsqu'un PersistenVolumeClaim apparaît dans le modèle de pod, chaque fois que le pod est planifié, Kubernetes déclenche plusieurs opérations sur le plug-in CSI, notamment ControllerPublishVolume, NodeStageVolume et NodePublishVolume. Cela crée un volume de stockage, le monte et le rend disponible pour une utilisation par les conteneurs s’exécutant dans le pod.
Créer votre propre pilote CSI pour Kubernetes
Composants du pilote CSI
Les pilotes CSI dans Kubernetes sont généralement déployés avec des composants de contrôleur et des composants par nœud.
Composant du contrôleur
Le plug-in de contrôleur est déployé en tant que Deployment ou StatefulSet et peut être monté sur n’importe quel nœud du cluster. Il se compose d’un pilote CSI qui implémente un service CSI Controller ainsi que d’un conteneur sidecar (ou de plusieurs conteneurs). Un conteneur sidecar de contrôleur interagit généralement avec les objets Kubernetes et effectue également des appels au service CSI Controller.
Le contrôleur n’a pas besoin d’un accès direct à un hôte - il peut effectuer toutes les opérations via des services de plan de contrôle externes et l’API Kubernetes. Il est possible de déployer plusieurs copies d’un composant de contrôleur pour la haute disponibilité (HA), mais vous devez implémenter l’élection du leader pour vous assurer qu’un seul contrôleur est actif à un moment donné.
Parmi les sidecars du contrôleur, on trouve un external-provisioner, un external-attacher, un external-snapshotter et un external-resizer. L’inclusion de certains sidecars dans un déploiement peut être facultative, en fonction des spécifications détaillées dans la page du sidecar.
Le contrôleur communique avec les conteneurs sidecar chargés de gérer les événements Kubernetes. Le contrôleur envoie ensuite les appels pertinents au pilote CSI. Un socket de domaine UNIX est partagé via un emptyDir volume, ce qui permet les appels entre les sidecars et le pilote.
Les sidecars de contrôleur utilisent des règles de contrôle d'accès basé sur des rôles (RBAC) pour régir leur interaction avec les objets Kubernetes. Les référentiels sidecar fournissent des exemples de configurations RBAC que vous pouvez incorporer dans vos stratégies RBAC.
Composant par nœud
Le plug-in node doit être déployé sur tous les nœuds d’un cluster, via un DaemonSet. Il comprend le pilote CSI implémentant le service de nœud CSI et le conteneur sidecar qui sert de registraire de pilote de nœud.
Le composant de nœud communique avec le kubelet, qui s’exécute sur tous les nœuds et gère les appels pour le service de nœud CSI. Les appels peuvent monter ou démonter des volumes de stockage d’un système de stockage et les rendre disponibles pour que le pod les consomme. Le kubelet utilise un socket de domaine UNIX, qui est partagé via un volume HostPath sur l’hôte, pour effectuer des appels au pilote CSI. Un socket de domaine UNIX supplémentaire est utilisé par le node-driver-registrar pour enregistrer le pilote auprès du kubelet.
Le plug-in de nœud nécessite un accès direct à un hôte pour monter les volumes de pilote. Afin de rendre les montages du système de fichiers et les périphériques de bloc disponibles pour le kubelet, le pilote CSI doit utiliser un point de montage bidirectionnel qui permet au kubelet de voir les montages créés par le conteneur du pilote.
Déploiement
Kubernetes ne détermine pas l'empaquetage d'un pilote de volume CSI, mais il fournit des recommandations pour simplifier le déploiement des pilotes CSI conteneurisés sur Kubernetes.
Il est conseillé aux fournisseurs de stockage de suivre les étapes suivantes lors du déploiement d’un pilote de volume CSI conteneurisé :
- Créez un conteneur pour implémenter le comportement du plug-in de volume et exposez une interface gRPC via un socket de domaine UNIX. Le conteneur doit être étiqueté “CSI volume driver” et configuré conformément aux spécifications CSI (avec les services de contrôleur, de nœud et d'identité).
- Regroupez le conteneur du pilote de volume avec des conteneurs supplémentaires fournis par l’équipe Kubernetes, tels que external-attacher, external-provisioner, cluster-driver-registrar, node-driver-registrar, external-resizer, external-snapshotter et livenessprobe. Ces conteneurs facilitent l’interaction du conteneur du pilote avec Kubernetes.
- Demandez aux administrateurs de cluster de déployer le DaemonSet et le StatefulSet pertinents et d’ajouter la prise en charge du système de stockage du fournisseur dans le cluster Kubernetes.
Une autre option pour un déploiement potentiellement plus simple consiste à regrouper tous les composants dans un seul DaemonSet, y compris l’external-provisioner et l’external-attacher. Cependant, cette stratégie consomme plus de ressources et nécessite l’utilisation d’un protocole d’élection du leader (tel que https://git.k8s.io/contrib/election) pour les composants external-attacher et external-provisioner.
Activation des pods privilégiés
Le cluster Kubernetes doit activer les pods privilégiés pour autoriser l’utilisation de pilotes CSI. Par exemple, vous devez définir l’indicateur --allow-privileged sur true pour le kubelet et le serveur d’API — dans certains environnements, tels que kubeadm, GCE et GKE, c’est la valeur par défaut.
Le serveur d’API doit être lancé avec les indicateurs privilégiés suivants :
$ ./kube-apiserver ... --allow-privileged=true ... $ ./kubelet ... --allow-privileged=true ...
Activation de la propagation de montage
L’interface de stockage de conteneurs requiert une fonctionnalité de propagation de montage qui permet de partager les volumes montés entre les conteneurs au sein du même nœud ou pod. Le démon Docker pour un cluster doit autoriser le partage de montage pour permettre la propagation de montage.
Kubernetes CSI avec NetApp Cloud Volumes ONTAP
NetApp Cloud Volumes ONTAP, la solution de gestion du stockage de niveau entreprise leader, offre des services de gestion du stockage sécurisés et éprouvés sur AWS, Azure et Google Cloud. La capacité de Cloud Volumes ONTAP peut évoluer jusqu'à plusieurs pétaoctets et prend en charge différents cas d’usage tels que les services de fichiers, les bases de données, DevOps ou toute autre charges de travail exigeantes, avec un ensemble solide de fonctionnalités, notamment la haute disponibilité, la protection des données, les efficacités du stockage, l’intégration Kubernetes, et plus encore.
En particulier, Cloud Volumes ONTAP prend en charge le provisionnement et la gestion des volumes persistants Kubernetes pour les workloads conteneurisés.
En savoir plus sur Kubernetes NFS Provisioning File Services avec Cloud Volumes ONTAP et Trident.
En savoir plus sur la façon dont Cloud Volumes ONTAP aide à relever les défis des applications conteneurisées dans ces Kubernetes Workloads with Cloud Volumes ONTAP Case Studies.
