Samba NAS в K3s «тормозил» только для части подов. Поверхностный мониторинг показывал нормальные IOPS, CPU и latency сети. Причина была в гибридном доступе: один PVC ходил к тем же файлам через SMB, другой — через NFS. POSIX fcntl/flock, SMB oplock или durable handle и NFS lockd не являются единой таблицей блокировок. Клиент мог видеть файл свободным, приложение — занятым, а второй протокол — вообще не знать о конфликте. Результат: зависшие writer'ы, stale handles и повреждение логики очереди, хотя NAS был доступен. На узле проверяйте реальные блокировки и состояние NFS: cat /proc/locks, smbstatus --locks, nfsstat -m, nfsstat -c, grep -E 'file-nr|dentry-state' /proc/sys/fs/. Для подтверждения трафика: tcpdump -ni any 'port 445 or port 2049'. В Kubernetes отдельно сверяйте mount, mountinfo и фактический backend каждого PV. Практическое ограничение жёсткое: один набор файлов обслуживается одним протоколом и одной моделью блокировок. Для SMB выдавайте SMB-only share, для NFS — отдельный ...