Volumes dans les Pods : Partage de données et persistance (emptyDir, hostPath)

Stockage au niveau du Pod : les bases des Volumes

Avant de plonger dans le monde complexe du stockage persistant découplé (PV/PVC), il est important de comprendre le concept de Volume tel qu'il s'applique directement à l'intérieur d'un Pod. Un Volume Kubernetes, dans ce contexte, est essentiellement un répertoire (potentiellement avec des données) qui est rendu accessible aux conteneurs d'un Pod.

Pourquoi utiliser des Volumes ?

• Persistance au-delà du cycle de vie d'un conteneur : Si un conteneur dans un Pod redémarre, les données écrites dans un Volume persistent (contrairement au système de fichiers propre du conteneur qui est recréé).
• Partage de données entre conteneurs : Plusieurs conteneurs au sein du même Pod peuvent monter le même Volume et ainsi partager des fichiers.

Kubernetes supporte de nombreux types de Volumes, chacun avec des propriétés différentes. Nous allons nous concentrer ici sur deux types fondamentaux souvent rencontrés, mais qui ne fournissent PAS de persistance à long terme indépendante du Pod ou du noeud : `emptyDir` et `hostPath`.

Volume `emptyDir` : un espace de travail temporaire partagé

Le type de volume `emptyDir` est exactement ce que son nom suggère : il crée un répertoire initialement vide lorsque le Pod est assigné à un noeud.

Caractéristiques clés :

• Cycle de vie lié au Pod : Le volume `emptyDir` existe tant que le Pod s'exécute sur ce noeud. Si le Pod est supprimé (pour quelque raison que ce soit), les données dans l'`emptyDir` sont définitivement perdues. De même, si un conteneur crashe et redémarre, le contenu de l'`emptyDir` persiste.
• Partage entre conteneurs : Tous les conteneurs d'un même Pod peuvent lire et écrire dans le même volume `emptyDir` s'ils le montent. C'est un excellent moyen pour des conteneurs (par exemple, une application principale et un sidecar) de partager des fichiers ou de communiquer.
• Stockage sous-jacent : Par défaut, l'`emptyDir` est créé sur le support de stockage du noeud qui héberge le Pod (par exemple, le disque local ou un stockage réseau). Vous pouvez optionnellement demander qu'il soit stocké en mémoire (tmpfs) en spécifiant `emptyDir.medium: Memory`, ce qui est plus rapide mais consomme de la RAM et les données sont perdues même lors d'un redémarrage du noeud.

Cas d'usage :

• Espace de travail temporaire (scratch space) pour une application.
• Cache disque.
• Point de partage pour des fichiers longs à générer entre un conteneur "init" et les conteneurs principaux.
• Partage de sockets Unix ou de fichiers de communication entre des conteneurs sidecar et principaux.

Exemple YAML :

apiVersion: v1
kind: Pod
metadata:
  name: pod-avec-emptydir
spec:
  containers:
  - name: conteneur-1
    image: busybox
    command: ["/bin/sh", "-c", "while true; do echo $(date) >> /cache/fichier.txt; sleep 5; done"]
    volumeMounts:
    - name: cache-volume
      mountPath: /cache
  - name: conteneur-2
    image: busybox
    command: ["/bin/sh", "-c", "tail -f /cache/fichier.txt"]
    volumeMounts:
    - name: cache-volume
      mountPath: /cache
  volumes:
  - name: cache-volume
    emptyDir: {} # Crée un volume emptyDir nommé 'cache-volume'

Ici, `conteneur-1` écrit dans `/cache/fichier.txt` et `conteneur-2` lit ce même fichier, car ils montent tous deux le même volume `emptyDir`.

Volume `hostPath` : accéder au noeud hôte (avec d'énormes précautions !)

Le type de volume `hostPath` permet de monter un fichier ou un répertoire directement depuis le système de fichiers du noeud hôte sur lequel le Pod est exécuté, dans le conteneur.

Caractéristiques clés :

• Accès direct au noeud : Permet à un Pod de lire ou d'écrire des fichiers qui existent sur le noeud lui-même.
• Persistance liée au noeud : Les données dans un volume `hostPath` persistent si le Pod redémarre, mais elles sont perdues si le Pod est déplacé vers un autre noeud (car le chemin pointait vers le système de fichiers du noeud précédent). Les données survivent à la suppression du Pod si elles existent sur le noeud.
• Risques de sécurité majeurs : C'est le point le plus critique. Utiliser `hostPath` peut être extrêmement dangereux :
  • Un conteneur pourrait accéder à des données système sensibles du noeud.
  • Un conteneur pourrait potentiellement écrire sur des fichiers système critiques du noeud.
  • Si mal utilisé, cela peut être un vecteur pour s'échapper du conteneur et compromettre le noeud hôte.
• Dépendance au noeud : Rend le Pod dépendant de la structure du système de fichiers ou de la présence de certains fichiers/répertoires sur des noeuds spécifiques, ce qui brise la portabilité.
• Contrôle via `type` : Le champ `hostPath.type` peut être utilisé pour spécifier ce qui doit exister sur le chemin hôte (ex: `Directory`, `File`, `DirectoryOrCreate`, `FileOrCreate`, `Socket`) avant le montage, offrant un léger contrôle supplémentaire.

Cas d'usage (légitimes mais limités et souvent risqués) :

• Exécuter des agents système qui doivent lire/écrire des logs ou des configurations spécifiques au noeud (ex: un agent de monitoring comme node-exporter via un DaemonSet).
• Accéder à la socket Docker (`/var/run/docker.sock`) pour des outils qui interagissent avec Docker (extrêmement puissant et donc risqué).
• Monter des configurations spécifiques au noeud.

Règle générale : Evitez `hostPath` autant que possible en production. Si vous devez l'utiliser, comprenez parfaitement les implications de sécurité et limitez son utilisation au strict minimum nécessaire, souvent en combinaison avec des DaemonSets et des politiques de sécurité Pod (Pod Security Admission).

Exemple YAML (à utiliser avec prudence) :

apiVersion: v1
kind: Pod
metadata:
  name: pod-avec-hostpath
spec:
  containers:
  - name: test-hostpath
    image: busybox
    command: [ "/bin/sh", "-c", "sleep 3600" ]
    volumeMounts:
    - name: host-logs
      mountPath: /mnt/host-logs # Accès aux logs du noeud dans le conteneur
  volumes:
  - name: host-logs
    hostPath:
      path: /var/log # Chemin sur le noeud hôte
      type: Directory # S'assure que /var/log est un répertoire

Limitations et transition vers le stockage persistant

Bien qu'utiles dans certains contextes, `emptyDir` et `hostPath` ne répondent pas au besoin fondamental des applications stateful : un stockage persistant qui survit au cycle de vie du Pod et qui est indépendant du noeud sur lequel le Pod s'exécute.

• `emptyDir` est intrinsèquement lié au cycle de vie du Pod : si le Pod disparaît, les données disparaissent.
• `hostPath` est intrinsèquement lié au noeud : si le Pod est déplacé, il perd l'accès aux données (qui restent sur le noeud précédent) et son utilisation pose d'importants problèmes de sécurité et de portabilité.

Ces limitations nous montrent clairement la nécessité d'un mécanisme de stockage plus robuste et découplé. C'est là que les PersistentVolumes (PV), les PersistentVolumeClaims (PVC) et les StorageClasses entrent en jeu, offrant une abstraction pour l'accès à des systèmes de stockage externes et fiables, indépendamment des Pods et des noeuds. Nous allons explorer ces concepts dans les sections suivantes.