Information in this document may be out of date

This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: Configure a Pod to Use a Volume for Storage

Configurando um Pod Para Usar um Volume Para Armazenamento

Esta página mostra como configurar um Pod para usar um Volume para armazenamento.

O sistema de arquivos de um contêiner apenas existe enquanto o contêiner existir. Então, quando um contêiner termina e reinicia, as alterações do sistema de arquivos são perdidas. Para um armazenamento mais consistente, independente do contêiner, você pode usar um Volume. Isso é especialmente importante para aplicações stateful, tal como armazenamentos chave-valor (tal como Redis) e bancos de dados.

Antes de você começar

Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:

Para verificar a versão, digite kubectl version.

Configure um volume para um Pod

Neste exercício, você cria um Pod que executa um contêiner. Este Pod tem um Volume do tipo emptyDir que persiste durante a existência do Pod, mesmo que o contêiner termine e reinicie. Aqui está o arquivo de configuração para o 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. Crie o Pod:

    kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
    
  2. Verifique se o contêiner do pod está funcionando, e então procure por mudanças no Pod:

    kubectl get pod redis --watch
    

    A saída se parece com isso:

    NAME      READY     STATUS    RESTARTS   AGE
    redis     1/1       Running   0          13s
    
  3. Em outro terminal, pegue um shell para o contêiner em execução:

    kubectl exec -it redis -- /bin/bash
    
  4. No seu shell, vá para /data/redis, e então crie um arquivo:

    root@redis:/data# cd /data/redis/
    root@redis:/data/redis# echo Hello > test-file
    
  5. No seu shell, liste os processos em execução:

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

    A saída é semelhante a esta:

    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. Em seu shell, encerre o processo do Redis:

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

    Onde <pid> é o process ID (PID) do Redis.

  7. No seu terminal original, preste atenção nas mudanças no Pod do Redis. Eventualmente, você vai ver algo assim:

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

Neste ponto, o Contêiner terminou e reiniciou. Isso porque o Pod do Redis tem uma restartPolicy de Always.

  1. Abra um shell dentro do Contêiner reiniciado:

    kubectl exec -it redis -- /bin/bash
    
  2. No seu shell, vá para /data/redis, e verifique se test-file ainda está lá.

    root@redis:/data/redis# cd /data/redis/
    root@redis:/data/redis# ls
    test-file
    
  3. Exclua o pod que você criou para este exercício:

    kubectl delete pod redis
    

Próximos passos

  • Veja Volume.

  • Veja Pod.

  • Além do armazenamento de disco local fornecido por emptyDir, o Kubernetes suporta muitas soluções de armazenamento diferentes, conectadas via rede, incluindo PD na GCE e EBS na EC2, que são preferidos para dados críticos e vão lidar com os detalhes, como montar e desmontar os dispositivos nos Nós. Veja Volumes para mais detalhes.