You are viewing documentation for Kubernetes version: v1.27

Kubernetes v1.27 documentation non maintenue. Vous consultez une version statique. Pour une documentation à jour, veuillez consulter: dernière version.

Configurer un pod en utilisant un volume pour le stockage

Cette page montre comment configurer un Pod pour utiliser un Volume pour le stockage.

Le système de fichiers d'un conteneur ne vit que tant que le conteneur vit. Ainsi, quand un conteneur se termine et redémarre, les modifications apportées au système de fichiers sont perdues. Pour un stockage plus consistant et indépendant du conteneur, vous pouvez utiliser un Volume. C'est particulièrement important pour les applications Stateful, telles que les key-value stores (comme par exemple Redis) et les bases de données.

Pré-requis

Vous devez disposer d'un cluster Kubernetes et l'outil de ligne de commande kubectl doit être configuré pour communiquer avec votre cluster. Si vous ne possédez pas déjà de cluster, vous pouvez en créer un en utilisant Minikube, ou vous pouvez utiliser l'un de ces environnements Kubernetes:

Pour consulter la version, entrez kubectl version.

Configurer un volume pour un Pod

Dans cet exercice, vous créez un pod qui contient un seul conteneur. Ce Pod a un Volume de type emptyDir qui dure toute la vie du Pod, même si le conteneur se termine et redémarre. Voici le fichier de configuration du Pod :

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    volumeMounts:
    - name: redis-storage
      mountPath: /data/redis
  volumes:
  - name: redis-storage
    emptyDir: {}
  1. Créez le Pod :

    kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
    
  2. Vérifiez que le conteneur du pod est en cours d'exécution, puis surveillez les modifications apportées au pod :

    kubectl get pod redis --watch
    

    La sortie ressemble à ceci :

    NAME      READY     STATUS    RESTARTS   AGE
    redis     1/1       Running   0          13s
    
  3. Dans un autre terminal, accédez à la console shell du conteneur en cours d'exécution :

    kubectl exec -it redis -- /bin/bash
    
  4. Dans votre shell, allez dans /data/redis, puis créez un fichier :

    root@redis:/data# cd /data/redis/
    root@redis:/data/redis# echo Hello > test-file
    
  5. Dans votre shell, listez les processus en cours d'exécution :

    root@redis:/data/redis# apt-get update
    root@redis:/data/redis# apt-get install procps
    root@redis:/data/redis# ps aux
    

    La sortie ressemble à ceci :

    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379
    root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash
    root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux
    
  6. Dans votre shell, arrêtez le processus Redis :

    root@redis:/data/redis# kill <pid>
    

    <pid> est l'ID de processus Redis (PID).

  7. Dans votre terminal initial, surveillez les changements apportés au Pod de Redis. Éventuellement, vous verrez quelque chose comme ça :

    NAME      READY     STATUS     RESTARTS   AGE
    redis     1/1       Running    0          13s
    redis     0/1       Completed  0         6m
    redis     1/1       Running    1         6m
    

A ce stade, le conteneur est terminé et redémarré. C'est dû au fait que le Pod de Redis a une restartPolicy fixé à Always.

  1. Accédez à la console shell du conteneur redémarré :

    kubectl exec -it redis -- /bin/bash
    
  2. Dans votre shell, allez dans /data/redis, et vérifiez que test-file est toujours là.

    root@redis:/data/redis# cd /data/redis/
    root@redis:/data/redis# ls
    test-file
    
  3. Supprimez le pod que vous avez créé pour cet exercice :

    kubectl delete pod redis
    

A suivre

  • Voir Volume.

  • Voir Pod.

  • En plus du stockage sur disque local fourni par emptyDir, Kubernetes supporte de nombreuses solutions de stockage connectées au réseau, y compris PD sur GCE et EBS sur EC2, qui sont préférés pour les données critiques et qui s'occuperont des autres détails tels que le montage et le démontage sur les nœuds. Voir Volumes pour plus de détails.