5 types de volumes Kubernetes et comment les utiliser

Qu’est-ce qu’un volume Kubernetes ?

Un volume Kubernetes est un répertoire contenant des données, auquel les conteneurs dans un pod Kubernetes peuvent accéder. L’emplacement du répertoire, le support de stockage qui le prend en charge et son contenu dépendent du type spécifique de volume utilisé.

Les processus s’exécutant dans des conteneurs dans un pod voient une vue du système de fichiers composée de :

• Un système de fichiers racine qui correspond au contenu de l’image du conteneur.
• Volumes montés sur le conteneur (si défini). Chaque volume est monté sur un chemin spécifique dans le système de fichiers du conteneur.

Les volumes sont définis dans le champ .spec.containers[*].volumeMounts du modèle de pod. Pour chaque pod et chaque image de conteneur dans le pod, vous devez spécifier quels volumes il montera et sur quels chemins (les chemins peuvent être différents pour chaque conteneur).

Il existe plusieurs types de volumes dans Kubernetes. Les plus importants sont les volumes éphémères, qui sont stockés localement sur le nœud Kubernetes et supprimés au redémarrage d’un pod, et Kubernetes persistent volumes (PV), qui conservent les données même après l’arrêt d’un pod.

Dans cet article

• Types de volumes Kubernetes
  • Volumes persistants
  • Volumes éphémères
  • Volumes EmptyDir
  • Volumes hostPath Kubernetes
  • Volumes Kubernetes ConfigMap
• Plug-ins pour le stockage des volumes Kubernetes
  • NFS
  • CSI
• Qu’est-ce que les volumeMounts Kubernetes ?
• Création d’un volume Kubernetes par le déploiement de pods
• Gestion des volumes Kubernetes avec NetApp Cloud Volumes ONTAP

5 types de volumes Kubernetes

Kubernetes prend en charge différents volumes, ce qui permet à chaque pod d’utiliser plusieurs types de volumes simultanément. Les volumes éphémères sont liés à la durée de vie du pod, tandis que les volumes persistants peuvent persister au-delà de la durée de vie du pod. Cela signifie que Kubernetes détruit les volumes éphémères une fois que leur pod n’existe plus, tout en conservant les données des volumes persistants.

Volumes persistants

Kubernetes fournit un sous-système PersistentVolume avec une API qui fait abstraction du provisionnement et de la consommation du stockage. Il fonctionne avec deux ressources d’API—PersistentVolume (PV) et PersistentVolumeClaim (PVC).

PersistentVolume (PV)
Un PV est une ressource de stockage située dans le cluster. Les administrateurs peuvent provisionner manuellement les PV, et Kubernetes peut utiliser des classes de stockage pour provisionner dynamiquement les PV. Comme les volumes, les PV sont des plug-ins, mais leur cycle de vie est indépendant de tout pod utilisant le PV.

Un PV fonctionne comme un objet API qui capture les détails de l’implémentation du stockage, y compris iSCSI, NFS et les systèmes de stockage de fournisseur de cloud. Il fonctionne de la même manière qu’un nœud, mais offre des ressources de stockage plutôt que de calcul.

PersistentVolumeClaim (PVC)
Un PVC est une demande de stockage faite par un utilisateur. Il fonctionne de la même manière qu’un pod, mais consomme des ressources PV plutôt que des ressources de nœud. Un PVC peut demander des ressources de stockage spécifiques, en spécifiant des modes d’accès tels que ReadWriteOnce, ReadWriteMany et ReadOnlyMany.

Les PVC permettent aux utilisateurs de consommer des ressources de stockage abstraites, mais les utilisateurs ont généralement besoin de PV avec des propriétés variables pour différents problèmes. C’est pourquoi les administrateurs de cluster doivent souvent proposer des PV variés qui diffèrent par plus que la taille et les modes d’accès. Ils peuvent le faire sans exposer les utilisateurs aux détails de l’implémentation grâce aux ressources StorageClass.

Contenu connexe : Lisez notre guide sur Kubernetes PVC

Volumes éphémères

Les volumes éphémères ne stockent pas les données de manière persistante après les redémarrages. Ces volumes sont liés à la durée de vie du pod, ce qui signifie qu'ils sont créés et supprimés en même temps que le pod. Cela permet d’arrêter et de redémarrer les pods sans les limiter à la disponibilité d’un volume persistant.

Les volumes éphémères sont simples à déployer et à gérer. Vous pouvez les spécifier en ligne dans la spécification du pod. Les volumes éphémères sont idéaux pour les applications qui ne nécessitent pas de stockage persistant, comme les services de cache.

Volumes EmptyDir

Un volume emptyDir est créé lorsque Kubernetes attribue un pod à un nœud. La durée de vie de ce volume est liée au cycle de vie d'un pod existant sur ce nœud spécifique. Un volume emptyDir est recréé lorsque les conteneurs redémarrent ou plantent. Cependant, les données de ce volume sont supprimées et perdues lorsque le pod est retiré du nœud, plante ou meurt.

Après avoir créé un volume emptyDir, vous pouvez déclarer le nom du type de volume en tant que champ dans le fichier manifeste du pod. Il s’affiche dans la section des propriétés du volume avec des accolades vides{} comme valeur. Les volumes EmptyDir sont principalement adaptés au stockage des données temporaire. Par exemple, vous pouvez l’utiliser pour un espace temporaire, comme une fusion basée sur disque.

Vous pouvez stocker des volumes emptyDir sur le support de sauvegarde du nœud. Par exemple, vous pouvez utiliser le stockage réseau ou un SSD. Vous pouvez également définir « memory » dans le champ emptyDir.medium et Kubernetes montera un système de fichiers sauvegardé par la RAM (tmpfs). Notez que Kubernetes efface tmpfs au redémarrage du nœud.

Volumes hostPath Kubernetes

Un volume hostPath monte un répertoire ou un fichier du système de fichiers du nœud hôte dans votre pod.

Voici les principaux cas d'utilisation des volumes hostPath :

• Utilisez un /var/lib/dockerhostPath—pour exécuter un conteneur qui nécessite l’accès aux éléments internes de Docker.
• Utilisez un /sys hostPath—pour exécuter cAdvisor dans un conteneur.
• Permettre à un pod de spécifier un hostPath—pour définir si un certain hostPath doit exister avant que le pod ne commence à s’exécuter et s’il doit être créé.
• Spécifiez un type pour un volume hostPath—vous pouvez le configurer en plus de la propriété path requise.

HostPath volumes sécurité
HostPath volumes présentent de nombreux risques pour la sécurité. Évitez de les utiliser dans la mesure du possible. Si vous devez utiliser un volume HostPath, vous devez le limiter uniquement au répertoire ou au fichier requis et le monter en tant que ReadOnly.

Voici les principaux risques de sécurité :

• Informations d’identification exposées—HostPaths peuvent exposer des informations d’identification système privilégiées ou des API privilégiées. Les acteurs malveillants peuvent l’utiliser pour attaquer d’autres parties du cluster ou pour s’échapper du conteneur.
• Privilèges root—tout répertoire ou fichier créé sur les hôtes sous-jacents n’est accessible en écriture que par root. Si vous souhaitez écrire sur un volume hostPath, vous devez modifier les autorisations de fichier sur l’hôte ou exécuter le processus en tant que root dans un conteneur privilégié.

Vous pouvez utiliser AdmissionPolicy pour restreindre l’accès HostPath à certains répertoires. Cependant, la stratégie n’est efficace que si vous exigez que volumeMounts utilise des montages readOnly.

Volumes Kubernetes ConfigMap

Un ConfigMap permet d’injecter des données de configuration dans des pods. Les données stockées dans un ConfigMap peuvent être référencées dans un volume de type configMap puis consommées par des applications conteneurisées qui s’exécutent dans un pod. Vous devez fournir le nom du ConfigMap dans le volume lorsque vous référencez un ConfigMap. Kubernetes vous permet de personnaliser le chemin d’accès d’une entrée spécifique dans le ConfigMap.

Plug-ins pour le stockage des volumes Kubernetes

Kubernetes fournit plusieurs plug-ins de stockage qui permettent d’accéder aux périphériques de stockage déployés dans un cluster Kubernetes. Ceux-ci sont implémentés à l’aide de l’objet StorageClass.

Certains des principaux plug-ins actuellement pris en charge par Kubernetes sont GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, Glusterfs, NFS et iSCSI. Pour plus de détails sur ces plug-ins, consultez la documentation StorageClass.

Examinons plus en détail deux plugins de stockage notables.

NFS

Network File System (NFS) est un protocole standard permettant de monter des périphériques de stockage en tant que disques locaux. Kubernetes vous permet de monter un volume NFS en tant que disque local dans un conteneur. Parce que le code hérité accède souvent aux données via NFS, ce plugin est très utile pour migrer des workloads hérités vers Kubernetes.

Il existe deux façons d’accéder aux données via NFS et Kubernetes :

• Volumes NFS éphémères—peuvent être attachés au stockage NFS existant.
• PersistentVolumes avec NFS—vous permet de configurer des ressources gérées sur un cluster auxquelles on accède via NFS.

CSI

Le Container Storage Interface (CSI) est une interface standard qui permet aux orchestrateurs de conteneurs d’exposer les systèmes de stockage aux conteneurs qu’ils gèrent. CSI permet aux fournisseurs de stockage de créer des plugins qui sont « hors arborescence », c’est-à-dire qu’ils n’ont pas besoin d’être archivés dans le référentiel de code Kubernetes et ne sont pas livrés avec Kubernetes.

Il existe de nombreux plug-ins externes basés sur CSI qui sont proposés directement par les fournisseurs de stockage. L’avènement de CSI a rendu beaucoup plus facile pour les technologies de stockage de prendre en charge Kubernetes.

Contenu connexe : Lisez notre guide sur Container Storage Interface

Qu'est-ce que Kubernetes volumeMounts ?

Il y a deux étapes pour créer un volume et le rendre accessible à un pod :

• Le déclarer dans la propriété spec:volumes du modèle de pod, puis déployer le pod sur certains nœuds
• Montage du volume sur un conteneur spécifique à l’aide de la propriété spec:containers::volumeMounts

Ces étapes vont de pair. Lorsque vous créez un volume, vous devez également le monter sur un conteneur, et vous ne pouvez pas monter un volume sans le déclarer dans le modèle de pod.

Voici un exemple illustrant à la fois la création et le montage d’un volume dans une configuration YAML de modèle de pod :

spec : containers : —name : my-app image : nginx volumeMounts : —name : my-volume mountPath : /app/config volumes : —name : my-volume 

Dans ce code

• volumes (en bas) crée un volume nommé my-volume et l’attache au pod
• volumeMounts définit comment le volume est monté, y compris le chemin de fichier par lequel le volume sera disponible depuis l’intérieur du conteneur
• Il est essentiel que le même nom de volume soit utilisé aux deux endroits — la déclaration de volume et la propriété volumeMounts.

Création d’un volume Kubernetes par le déploiement de pods

Pour créer un volume Kubernetes, vous déployez un ou plusieurs pods qui déclarent le volume. Une façon courante de le faire est d'utiliser un objet Deployment. Voici un exemple de manifeste Deployment qui effectue les opérations suivantes :

• Déploie trois pods, chacun avec un conteneur NGINX
• Déclare un volume emptyDir
• Monte le volume sur chacun des trois conteneurs à la racine

apiVersion : apps/v1 kind: Deployment metadata: name: pods-with-volumes spec: replicas: 3 selector: matchLabels : app: demo template: metadata: labels: app: demo spec: containers: —name: my-container image: nginx:1.14.2 volumeMounts : —mountPath : / name: my-volume volumes: —name: my-volume emptyDir : {} 

Notez que le nom de ce Deployment est défini dans pods-with-volumes—c’est ainsi que vous y faites référence dans l’environnement Kubernetes.

Comme nous l’avons vu dans la section précédente, cet objet Deployment effectue les deux actions nécessaires à la création d’un volume :

• La propriété spec:template:volumes déclare le volume.
• La propriété spec:containers::volumeMounts monte le volume sur les conteneurs.

Supposons que ce fichier YAML soit enregistré sous le nom my-deployment.yaml. Vous pouvez créer le déploiement dans votre cluster Kubernetes en utilisant cette commande :

kubectl apply -f my-deployment.yaml

Pour vérifier que le déploiement s’exécute correctement avec les volumes attendus, exécutez cette commande :

kubectl describe pods pods-with-volumes

Si tout a fonctionné correctement, la sortie montrera que chaque pod a un conteneur nommé my-container avec le point de montage demandé :

Montages : / from my-volume (rw)

La sortie affichera également le volume en cours d’exécution sous chaque pod :

Volumes : my-volume : Type : EmptyDir (un répertoire temporaire qui partage la durée de vie d'un pod)

Gestion des volumes Kubernetes avec NetApp Cloud Volumes ONTAP

NetApp Cloud Volumes ONTAP, la solution de gestion du stockage de niveau entreprise leader, fournit 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 la façon dont Cloud Volumes ONTAP aide à relever les défis des applications conteneurisées dans ces études de cas Kubernetes Workloads avec Cloud Volumes ONTAP.