Menu

A tradução automática foi usada para esta página. Algum conteúdo pode não ser perfeito.

Compartilhar Feedback

Reivindicações de volumes persistentes do Kubernetes explicadas

Conteúdo

Compartilhe esta página

Yifat Perry
Yifat Perry

O que são volumes persistentes do Kubernetes e reivindicações de volumes persistentes?

Um Kubernetes volume persistente (PV) é um objeto que permite que os pods acessem storage persistente em um dispositivo de storage, definido via um Kubernetes StorageClass. Ao contrário dos volumes regulares, que são transitórios por natureza, os PVs são persistentes, suportando casos de uso de aplicações com estado. Um PV é um objeto de recurso em um cluster Kubernetes que continua a existir mesmo após os pods que o utilizam terem sido destruídos.

Os PVs devem ser solicitados por meio de persistent volume claims (PVCs), que são solicitações de storage. Uma PVC é essencialmente uma solicitação para montar um PV que atenda a determinados requisitos em um pod. As PVCs não especificam um PV específico — em vez disso, especificam qual StorageClass o pod requer. Os administradores podem definir StorageClasses que indicam propriedades dos dispositivos de storage, como desempenho, níveis de serviço e políticas de back-end.

Uma das principais vantagens do padrão PVC no Kubernetes é que ele permite que os desenvolvedores solicitem recursos de storage dinamicamente, sem precisar conhecer a implementação dos dispositivos de storage subjacentes.

Conteúdo relacionado: Leia nosso guia sobre Kubernetes StorageClass

Neste artigo:

Reivindicações de Volume Persistente: provisionamento estático vs. dinâmico

Para vincular um pod a um PV, o pod deve conter um volume mount e um PVC. Essas declarações permitem que os usuários montem PVs em pods sem conhecer os detalhes do storage subjacente.

Existem duas opções para montar PVs em um pod:

  • A configuração estática envolve administradores criando manualmente PVs e definindo um StorageClass que corresponda aos critérios desses PVs. Quando um pod usa um PVC que especifica o StorageClass, ele obtém acesso a um desses PVs estáticos.
  • A configuração dinâmica ocorre quando não existe um PV estático que corresponda ao PVC. Nesse caso, o cluster Kubernetes provisiona um novo PV com base nas definições de StorageClass.

Conteúdo relacionado: Leia nosso guia sobre Kubernetes shared storage

Criando uma reivindicação de volume persistente e vinculando-a a um volume persistente

Este tutorial demonstra como funcionam os PVs e PVCs. É um resumo do tutorial disponível na documentação do Kubernetes.

1. Configurando um nó
Configure um cluster Kubernetes com um único nó e certifique-se de que o comando kubectl na linha de comando tenha uma conexão com o plano de controle. Crie um diretório no nó da seguinte forma:

sudo mkdir /mnt/data

Crie um arquivo index.html no diretório.

2. Criando um volume persistente
Crie um arquivo YAML como o seguinte para definir um PV.

k8s pvc 1

Execute este comando para criar o PV no seu nó:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml

3. Criando uma solicitação de volume persistente e vinculando-a a um volume persistente
Crie uma solicitação de volume persistente (PVC) que exija um volume persistente (PV), sujeita às seguintes condições para corresponder ao PV que você criou anteriormente:

  • 3 GB ou mais de capacidade de storage
  • Habilitar acesso de leitura/gravação
k8s pvc 2

Execute este comando para aplicar o PVC:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml

Ao criar uma solicitação de volume persistente (PVC), o plano de controle do Kubernetes localiza o PV correto. Se encontrado, ele vincula o PVC ao PV.

Verifique o status do PV criado anteriormente executando:

kubectl get pv task-pv-volume

Se a vinculação for bem-sucedida, a saída deve ser semelhante a esta:

k8s pvc 3

4. Criando um pod e montando a declaração de volume persistente
Por fim, crie um pod que utilize a PVC. Execute o pod com a imagem do NGINX, especificando a PVC que você criou previamente na seção relevante da especificação do pod:

k8s pvc 4

Use um comando bash para instalar o curl no seu pod e execute este comando:

curl http://localhost/

A saída deve exibir o conteúdo do arquivo index.html criado na etapa 1. Deve mostrar que o novo pod pode acessar os dados no PV por meio do PVC.

Erros de PVC do Kubernetes: causas comuns e resolução [C]

O PVC do Kubernetes pode ser complexo de usar, resultando em erros que podem ser difíceis de diagnosticar e corrigir. Os erros de PVC geralmente estão relacionados a três categorias principais - problemas com a criação de PVs, problemas com o provisionamento de PVs e alterações nas especificações de PV ou PVC.

Os erros mais comuns relacionados a PVCs são FailedAttachVolume, FailedMount e CrashLoopBackOff.

FailedAttachVolume e FailedMount Errors

Esses dois erros indicam que um pod não conseguiu montar um PV. A diferença é que FailedAttachVolume ocorre quando um volume não consegue se desvincular de um nó anterior, e FailedMount ocorre quando um volume não consegue ser montado no caminho necessário.

Existem inúmeras causas possíveis para esses dois erros, incluindo falha no novo nó, excesso de discos conectados ao novo nó, erro de particionamento de rede e falha de dispositivos de storage no nó anterior.

Diagnosticando o problema

Para diagnosticar a causa de problemas como FailedAttachVolume e FailedMount, execute o comando describe pod e procure na seção Events pela mensagem que indica um erro. A mensagem também deve fornecer informações sobre a causa.

Resolvendo o problema

O Kubernetes não consegue resolver os erros FailedAttachVolume e FailedMount automaticamente, então você precisará lidar com o problema manualmente:

  • Se a causa do erro for Failure to Detach- use a interface do dispositivo de storage para desanexar o volume manualmente.
  • Se o erro for Failure to Attach or Mount, verifique se há algum problema de particionamento de rede ou caminho de rede incorreto. Se esse não for o problema, tente fazer com que o Kubernetes agende o pod em outro nó ou investigue e corrija o problema no novo nó.

CrashLoopBackOff Erros resultantes do PersistentVolumeClaim

CrashLoopBackOff indica que um pod falhou, reiniciou e falhou novamente repetidamente. Em alguns casos, esse erro ocorre como resultado de PersistentVolumeClaims corrompidos.

Diagnosticando o problema

Para identificar se um erro CrashLoopBackOff é devido a um PVC, verifique os logs da instância anterior do contêiner que montou o PV, verifique os logs de implantação e, se necessário, execute um shell no contêiner para identificar por que ele está falhando.

Resolvendo o problema

Se CrashLoopBackOff for o resultado de um problema com um PVC, tente as seguintes etapas:

  1. Reduza a escala da implantação para 0 instâncias para habilitar debugging.
  2. Obtenha o identificador do PVC com falha usando esta consulta:
    kubectl get deployment -o jsonpath="{.spec.template.spec.volumes[*].persistentVolumeClaim.claimName}" failed-deployment 
    
  3. Crie um novo pod para depuração e execute um shell usando este comando:
    exec -it volume-debugger sh
    
  4. Identifique o volume atualmente montado no /datadirectory e corrija o problema que está causando a falha do pod.
  5. Saia do shell, exclua o pod de depuração e dimensione a implantação de volta para o número necessário de réplicas.

Otimização de storage do Kubernetes com Cloud Volumes ONTAP

O NetApp Cloud Volumes ONTAP, a solução de gerenciamento de storage de nível empresarial líder do setor, oferece serviços de gerenciamento de storage seguros e comprovados na AWS, Azure e Google Cloud. A capacidade do Cloud Volumes ONTAP pode escalar até petabytes, e suporta diversos casos de uso, como serviços de arquivos, bancos de dados, DevOps ou qualquer outra carga de trabalho empresarial, com um conjunto forte de recursos incluindo alta disponibilidade, proteção de dados, eficiência de armazenamento, integração com Kubernetes e mais.

Em particular, Cloud Volumes ONTAP oferece suporte ao provisionamento e gerenciamento de Volumes Persistentes do Kubernetes  para os requisitos de cargas de trabalho conteinerizadas.

Saiba mais sobre como Cloud Volumes ONTAP ajuda a enfrentar os desafios de aplicações conteinerizadas nestes Kubernetes Workloads with Cloud Volumes ONTAP Case Studies.

Drift chat loading