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.
Étape suivante
- Apprenez à référencer des volumes dans un pod.
- Apprenez-en plus sur PersistentVolumes, PersistentVolumeClaims et le provisionnement de stockage dynamique.
- Configurez un pod pour utiliser un volume à des fins de stockage.
- Ajoutez des données ConfigMap à un volume.