PersistentVolumeClaim (PVC)
Por que o PVC é necessário?
Os containers são efêmeros, o que significa que, quando um container é reiniciado ou excluído, todos os dados armazenados dentro dele são perdidos. Para aplicações que precisam persistir dados (como bancos de dados, uploads de usuários, etc.), precisamos de uma maneira de armazenar dados fora do container, em um local que sobreviva ao ciclo de vida do container.
É aqui que entram os PersistentVolumeClaims (PVCs). Um PVC é uma solicitação de armazenamento que um Pod pode usar para montar um volume persistente. Isso permite que os dados sejam armazenados em um local duradouro, independentemente do que aconteça com o Pod.
O que é um PVC?
Um PersistentVolumeClaim (PVC) é uma solicitação de armazenamento por um usuário. É semelhante a um Pod. Os pods consomem recursos de nó e os PVCs consomem recursos de PersistentVolume (PV). Os pods podem solicitar níveis específicos de recursos (CPU e memória). As solicitações podem solicitar tamanho e modos de acesso específicos (por exemplo, podem ser montados uma vez para leitura/gravação ou muitas para somente leitura).
Ciclo de Vida
-
Provisionamento: O armazenamento pode ser provisionado estaticamente ou dinamicamente.
- Estático: Um administrador de cluster cria vários PVs. Eles carregam os detalhes do armazenamento real que está disponível para uso pelos usuários do cluster. Eles existem na API do Kubernetes e estão disponíveis para consumo.
- Dinâmico: Quando nenhum dos PVs estáticos criados pelo administrador corresponde a um
PersistentVolumeClaimde um usuário, o cluster pode tentar provisionar dinamicamente um volume especialmente para o PVC. Este provisionamento é baseado emStorageClasses.
-
Binding: Um usuário cria, ou no caso de provisionamento dinâmico, já criou, um
PersistentVolumeClaimcom uma quantidade específica de armazenamento solicitada e com certos modos de acesso. Um loop de controle no mestre observa os novos PVCs, encontra um PV correspondente (se possível) e os vincula. Se um PV foi provisionado dinamicamente para um novo PVC, o loop sempre vinculará esse PV ao PVC. -
Uso: Os pods usam as solicitações como volumes. O cluster inspeciona o PVC para encontrar o volume vinculado e monta esse volume para um Pod. Para volumes que suportam vários modos de acesso, o usuário especifica qual modo é desejado ao usar sua solicitação como um volume em um Pod.
Exemplos
Minikube
O Minikube vem com um provisionador de armazenamento padrão que provisiona dinamicamente PersistentVolumes.
-
Crie um
PersistentVolumeClaim:pvc.yamlapiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi -
Crie o PVC:
kubectl apply -f pvc.yaml -
Use o PVC em um Pod:
pod.yamlapiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: nginx volumeMounts: - mountPath: "/usr/share/nginx/html" name: my-volume volumes: - name: my-volume persistentVolumeClaim: claimName: my-pvc -
Crie o Pod:
kubectl apply -f pod.yaml
Longhorn
Longhorn é uma solução de armazenamento em bloco distribuído para Kubernetes. É a solução de armazenamento padrão para o SomosBR KaaS.
Para usar o Longhorn, você precisa ter um StorageClass do Longhorn. A StorageClass padrão do Longhorn é longhorn.
-
Crie um
PersistentVolumeClaimcom aStorageClassdo Longhorn:pvc-longhorn.yamlapiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-longhorn-pvc spec: accessModes: - ReadWriteOnce storageClassName: longhorn resources: requests: storage: 1Gi -
Crie o PVC:
kubectl apply -f pvc-longhorn.yaml -
Use o PVC em um Pod (o mesmo
pod.yamldo exemplo do Minikube, mas com oclaimNamealterado paramy-longhorn-pvc):pod-longhorn.yamlapiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: nginx volumeMounts: - mountPath: "/usr/share/nginx/html" name: my-volume volumes: - name: my-volume persistentVolumeClaim: claimName: my-longhorn-pvc -
Crie o Pod:
kubectl apply -f pod-longhorn.yaml