Volumes

Cette page présente les volumes dans Kubernetes et leur utilisation avec Google Kubernetes Engine (GKE).

Présentation

Les fichiers sur disque dans un conteneur sont l'endroit le plus simple où un application peut écrire des données, mais cette approche présente des inconvénients. Les fichiers sont perdus lorsque le conteneur se bloque ou s'arrête pour toute autre raison. De plus, les fichiers d'un conteneur sont inaccessibles pour les autres conteneurs s'exécutant dans le même pod. L'abstraction du volume Kubernetes répond à ces deux problèmes.

Conceptuellement, un volume est un annuaire accessible à tous les conteneurs d'un pod. La source du volume déclaré dans la spécification du pod détermine le mode de création du répertoire, le support de stockage utilisé et le contenu initial du répertoire. Un pod spécifie les volumes qu'il contient et le chemin d'accès où les conteneurs installent le volume.

Les types de volumes éphémères ont la même durée de vie que les pods qui les entourent. Ces volumes sont créés lors de la création du pod et ils persistent lors des redémarrages du conteneur. Lorsque le pod s'arrête ou s'il est supprimé, il en va de même pour ses volumes.

Les autres types de volumes sont des interfaces conçues pour le stockage durable qui existent indépendamment d'un pod. Contrairement aux volumes éphémères, les données d'un volume sauvegardé à l'aide d'un stockage durable sont préservées lorsque le pod est supprimé. Le volume est simplement démonté et les données peuvent être transférées à un autre pod. Vous devez utiliser les ressources PersistentVolume pour gérer le cycle de vie des types de stockage durable, plutôt que de les spécifier directement.

Types de volumes

Les volumes diffèrent par leur mise en œuvre de stockage et leur contenu initial. Vous pouvez choisir la source de volume qui convient le mieux à votre cas d'utilisation. Plusieurs sources de volume courantes sont décrites dans les sections suivantes. Pour obtenir la liste complète des types de volumes, reportez-vous à la documentation sur les volumes Kubernetes.

emptyDir

Un volume emptyDir fournit un répertoire vide depuis lequel les conteneurs du pod peuvent lire et écrire. Lorsque le pod est supprimé d'un nœud pour une raison quelconque, les données du volume emptyDir sont définitivement supprimées. Un volume emptyDir est stocké sur le support qui sauvegarde le nœud, quel qu'il soit : un disque, un SSD ou un stockage réseau, en fonction de votre environnement. Les volumes emptyDir sont utiles pour l'espace de travail et le partage de données entre plusieurs conteneurs d'un pod.

Tous les montages emptyDir font partie du stockage éphémère du nœud, qui inclut également la couche et les journaux accessibles en écriture du conteneur. Par défaut, GKE Autopilot définit le stockage éphémère sur 1 Gio pour donner à votre application la possibilité de créer certains fichiers. Si vous avez besoin de plus ou moins d'espace, vous pouvez régler votre espace de stockage éphémère dans votre Déploiement en définissant une demande de ressource pour ephemeral-storage.

Si vous utilisez des conteneurs avec des pools de nœuds Linux, vous pouvez définir le champ emptyDir.medium sur Memory pour indiquer à Kubernetes d'installer un tmpfs (système de fichiers sauvegardé sur la RAM). Cette mise en œuvre n'est cependant pas compatible avec les conteneurs Windows Server.

ConfigMap

Une ressource ConfigMap permet d'injecter des données de configuration dans des pods. Les données stockées dans un objet ConfigMap peuvent être référencées dans un volume de type ConfigMap, puis consommées via des fichiers exécutés dans un pod. Les fichiers d'un volume ConfigMap sont spécifiés par une ressource ConfigMap.

Secret

Un volume Secret permet de rendre des données sensibles, telles que des mots de passe, des jetons OAuth et des clés SSH, disponibles pour les applications. Les données stockées dans un objet Secret peuvent être référencées dans un volume de type Secret, puis consommées via des fichiers exécutés dans un pod.

downwardAPI

Un volume downwardAPI met les données de l'API Downward à la disposition des applications. Ces données incluent des informations sur le pod et le conteneur dans lesquels une application s'exécute. Par exemple, un pod peut être configuré pour exposer un DownwardAPIVolumeFile à des applications comprenant l'espace de noms et l'adresse IP du pod. Pour obtenir la liste complète des types de données que vous pouvez ajouter, consultez la section Fonctionnalités de l'API Downward.

PersistentVolumeClaim

Les opérateurs de cluster peuvent utiliser un volume PersistentVolumeClaim pour provisionner le stockage durable à utiliser par les applications. Un pod utilise un volume PersistentVolumeClaim pour installer un volume sauvegardé par ce stockage durable.