Volumes e recuperação por camada

Contrato do claim e capacidade real

Um PVC exprime uma necessidade: classe, tamanho, modo de volume e acesso. O provisioner, o driver e o armazenamento têm de a satisfazer. storageClassName omitido pode receber a classe por omissão; a string vazia pede explicitamente ausência de classe.

Distingue Filesystem de Block: no segundo caso a aplicação recebe um dispositivo, não uma diretoria já formatada. O fragmento pede 12 GiB na classe fast para um consumidor; não cria essa classe nem demonstra suporte do driver. Confirma o provisioner, a topologia e as condições de binding antes de concluir que falta apenas capacidade.

Ciclo de vida e dados que devem permanecer

O acesso RWO limita o mount read-write a um nó, não necessariamente a um Pod. Retain mantém o recurso para recuperação administrativa quando o claim é removido; Delete pode eliminar também o armazenamento associado, conforme o driver. Nenhuma destas políticas é uma estratégia de backup.

Antes de eliminar ou reutilizar um volume, identifica o proprietário e a evidência de recuperação dos dados. Um PVC maior não prova que o filesystem e a aplicação já reconhecem a nova capacidade. Lê condições e eventos do PVC e confirma o suporte de expansão da classe e do driver.

Distinguir binding, attachment e mount

Um claim Bound identifica uma relação com um PV. Não demonstra que o nó anexou o volume, que o mount terminou ou que a aplicação leu os dados. Organiza a investigação pela primeira fase sem evidência: eventos de scheduling e topologia; estado de attachment e driver; mensagens de mount; identidade e permissões vistas pelo processo.

Um erro de attach num novo nó após falha do anterior exige confirmar o estado do consumidor antigo e a política de exclusividade antes de forçar alterações. Para cada intervenção, regista o recurso exato e observa uma leitura ou operação representativa sem usar os dados reais como material público.

Quando a API não é o ponto de observação disponível

Se o API server está indisponível, kubectl logs pode não ser uma via útil. Num nó autorizado, correlaciona o serviço kubelet, runtime e containers locais. crictl precisa de um endpoint CRI correto; a lista vazia consultada no socket errado não prova ausência de containers.

Em instalações kubeadm com control plane em static Pods, examina também os manifestos locais e os containers correspondentes. Recolhe logs e timestamps antes de reiniciar componentes, para não perder a sequência da falha. Se a API funciona mas kubectl top falha, investiga a cadeia Metrics API; isso não demonstra que os Pods deixaram de consumir recursos.

Armadilhas comuns

Apagar o claim para qualquer falha; equiparar Bound a dados acessíveis; confundir modo Block com filesystem; concluir ausência de containers a partir do endpoint errado.