Kubernetes 1.37 e storage: teste SELinux, CSI e PVC antes do primeiro node

O sinal e os factos que mudam a decisão

Kubernetes 1.37 traz alterações relevantes para operação de volumes: evolução do SELinuxMount, capacidade de storage no scheduling, awareness de limites CSI e estado de PVC sem utilização. O impacto depende de drivers, labels, partilha de volumes e feature gates em cada distribuição.

A nota de release descreve funções de capacidade e CSI com feature gates e defaults próprios; algumas permanecem opt-in. O estado 'unused since' de PVC indica observação do controlador e não ordena eliminação nem prova que o storage backend desmontou nesse instante.

SELinux e volume sharing precisam de testes com labels e drivers reais; a compatibilidade teórica do cluster não cobre a implementação CSI. Um Pod 'Running' não prova integridade ou recuperabilidade. Problemas de label podem aparecer apenas ao remount, limites CSI em scale-from-zero e condições de PVC podem ser confundidas com autorização de eliminação automática.

Decisão, limites e condição de bloqueio

Crie uma pista de teste de storage separada do smoke test geral. Reproduza drivers, StorageClasses, access modes, labels SELinux, expansão, snapshots, attach limits, autoscaling, failover e recuperação; só depois inclua nodes com workloads stateful no canário.

Um Pod 'Running' não prova integridade ou recuperabilidade. Problemas de label podem aparecer apenas ao remount, limites CSI em scale-from-zero e condições de PVC podem ser confundidas com autorização de eliminação automática.

Execução e prova de conclusão

A execução deve começar por inventariar csi drivers, versões, storageclasses, modes, snapshots, expansão, topology, selinux e workloads com volumes partilhados. Depois, restaurar dados de teste, montar, escrever, reiniciar, mover pods, escalar de zero e forçar cenários de falha e remount. O fecho exige comparar hashes, latência, eventos, erros csi e condições pvc e manter limpeza automática desligada até política própria.

O storage gate fecha quando drivers declaram suporte, dados sobrevivem aos cenários, attach e autoscaling respeitam limites, labels não bloqueiam remount e snapshots restauram dentro do RPO e RTO definidos.

• inventariar CSI drivers, versões, StorageClasses, modes, snapshots, expansão, topology, SELinux e workloads com volumes partilhados.
• restaurar dados de teste, montar, escrever, reiniciar, mover Pods, escalar de zero e forçar cenários de falha e remount.
• comparar hashes, latência, eventos, erros CSI e condições PVC e manter limpeza automática desligada até política própria.
• O storage gate fecha quando drivers declaram suporte, dados sobrevivem aos cenários, attach e autoscaling respeitam limites, labels não bloqueiam remount e snapshots restauram dentro do RPO e RTO definidos.