Um globalmount CIFS num share SMB do TrueNAS ficou obsoleto em todo node k3s ao mesmo tempo, e o csi-driver-smb continuou fazendo bind-mount do handle morto em todo pod novo — corrigido com noserverino, um liveness probe que checa o mount de verdade e um DaemonSet que força umount de globalmounts CIFS obsoletos.
kubelet calculava a capacidade de ephemeral-storage a partir da partição pequena /var em vez do disco de dados de 838G, evictando pods do Jellyfin que usavam 1.1MB. Corrigido com bind mount do disco grande em /var/lib/kubelet, em vez de mover root-dir, o que quebra o CSI do Longhorn.
Stalls de iSCSI do Longhorn e pressão de memória travavam nós k3s e exigiam reinicializações físicas pelo botão de energia. Como o kdump revelou o que o journald não conseguia.
Três modos de falha de storage sem relação entre si, no mesmo cluster k3s, todos se apresentam como um nó que não responde — stalls de iSCSI do Longhorn sob pressão de memória, mounts CIFS entrando em estado D, e kubelet medindo ephemeral-storage no disco errado. Como diferenciá-los antes de apertar o botão de energia.
Mounts CIFS no Kubernetes não têm opção de timeout confiável na maioria dos kernels. Cada correção óbvia falha. Isso documenta o que foi tentado, o que o kernel realmente suporta e o padrão sidecar que funciona.