APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um volume persistente pode sobreviver à substituição de um Pod, mas isso não cria uma cópia histórica dos dados. Antes de eliminar uma PVC, verifica quem a usa e qual reclaim policy se aplica ao volume. A política pode ter consequências sobre o recurso de storage; um nome temporário não demonstra que os dados deixaram de ser necessários. Um plano de recuperação deve considerar alterações lógicas, cópias, restauro e validação da aplicação. Num projeto de migração, define quem aceita a recuperação e quando a origem pode ser descomissionada. Não uses apenas um Pod novo em Running como prova de que o estado de negócio foi preservado.
Aplicação guiada
Para acesso operacional, descreve recursos, verbos e âmbito. Ler Pods e os seus logs em funds pode ser representado por uma Role e um RoleBinding nesse namespace. O subresource pods/log precisa de autorização própria; uma concessão em dev não se estende automaticamente a funds. Para segredos, base64 não é cifragem. Um manifesto exposto num repositório pode ter cópias em histórico e clones, por isso apagar o último commit não demonstra contenção. Segue o processo de rotação e acesso, e valida a configuração de proteção em repouso e a entrega ao workload. A equipa de RUN precisa de diagnosticar o serviço com os privilégios definidos, sem depender de cluster-admin.
No handover, ensaia leitura de logs com o grupo APS real e um restauro com a identidade de contingência; testes feitos só pelo administrador não provam autonomia.
Armadilhas comuns
PVC como backup; Delete sem avaliar reclaim policy; base64 como cifragem; get pods como get pods/log; cluster-admin por conveniência.
Tópicos relacionados: Entrega, GitOps e diagnóstico de releases · Observabilidade, objetivos e ecossistema
Preserva o estado necessário e concede apenas as operações que a função realmente exige.
Referência: Persistent volumes · KCNA current four-domain curriculum; edition date unconfirmed