A definição de um Volume no Pod é feita em dois passos:
O primeiro passo consiste em declarar o Volume utilizando o atributo spec.volumes
e, como parte da declaração, você também deve fornecer o name
e o type
do Volume.
spec:
volumes:
- name: logs-volume
emptyDir: {}
O segundo passo é a montagem do Volume em um path do container através do atributo spec.containers.volumeMounts
. O mapeamento entre os Volumes e volumeMounts é feito pela correspondência do atributo name
.
spec:
containers:
volumeMounts:
- name: logs-volume
mountPath: /var/logs
O exemplo abaixo mostra a junção dos snippets anteriores em um único manifesto. O manifesto declara um Pod chamado business-app com um Volume chamado logs-volume
do tipo emptyDir
montado no path /var/logs
do container nginx através do atributo volumeMounts
.
apiVersion: v1
kind: Pod
metadata:
name: business-app
spec:
volumes:
- name: logs-volume
emptyDir: {}
containers:
- image: nginx
name: nginx
volumeMounts:
- mountPath: /var/logs
name: logs-volume
Vamos criar o Pod para interagir com o Volume montado.
$ kubectl create -f pod-with-volume.yaml
pod/business-app created
$ kubectl get pod business-app
NAME READY STATUS RESTARTS AGE
business-app 1/1 Running 0 43s
$ kubectl exec business-app -it -- /bin/sh
# cd /var/logs
# pwd
/var/logs
# ls
# touch app-logs.txt
# ls
app-logs.txt
# exit
Documentação emptyDir:
Um Volume emptyDir
é criado assim que o Pod é atribuído ao node e existirá enquanto esse Pod estiver em execução neste node. Como o próprio nome diz, um emptyDir
estará inicialmente vazio. Todos os containers do Pod conseguem ler e escrever no mesmo emptyDir
embora ele possa ser montado em diferentes paths em cada um dos containers. Se o Pod for removido do node por qualquer motivo os dados do emptyDir
serão deletados permanentemente. Uma falha no container não faz com que o Pod seja removido do node e isso significa que os dados do emptyDir
estarão seguros neste caso.