APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma PersistentVolumeClaim pede armazenamento com características; um PersistentVolume representa armazenamento disponibilizado. StorageClass pode definir provisionamento dinâmico e comportamento de binding. Com WaitForFirstConsumer, a escolha pode esperar pelo contexto do Pod para respeitar topologia. Uma claim Pending sem consumidor não prova falha do driver. O mecanismo depende também de scheduling; definir nodeName diretamente pode contorná-lo e deixar o fluxo por concluir. Lê eventos e condições de claim, Pod e provisionador antes de eliminar objetos que ainda podem conter a referência aos dados necessários.
Aplicação guiada
ReadWriteOnce refere montagem de escrita por um nó, podendo vários Pods nesse nó usar o volume; não é garantia de um único Pod nem coordenação de escritas da aplicação. ReadWriteOncePod oferece outra restrição quando suportada por CSI e pelos requisitos aplicáveis. Na retirada, Retain preserva armazenamento para tratamento manual, mas não cria backup nem sanitiza conteúdo. Para expansão, verifica allowVolumeExpansion, suporte do driver e filesystem, aumenta o pedido da PVC e acompanha capacidade efetiva. O mecanismo permite crescer, não encolher. Qualquer migração de dados exige validação e uma decisão de recuperação própria.
Uma PVC 20Gi deve crescer para 40Gi. Revê StorageClass e eventos, confirma recuperação dos dados e valida o tamanho observado pela aplicação após o procedimento suportado.
Armadilhas comuns
Eliminar uma claim Pending sem diagnóstico; confundir RWO com um Pod; reutilizar Retain sem verificar dados; declarar expansão só por editar o PV.
Tópicos relacionados: Diagnosticar workloads com evidência · Nós e plano de controlo
O ciclo de vida do objeto Kubernetes e o dos dados precisam de decisões coordenadas.
Referência: Persistent volumes · CKA Kubernetes v1.35