Кластер K3s с SQLite backend выглядит стабильно до тех пор, пока количество объектов в etcd-альтернативе не превысит порог, при котором WAL-логи начинают доминировать в I/O. Внезапно API-сервер перестаёт отвечать, но systemd и livenessProbe этого не видят — процесс жив, просто ждёт fsync(). Диагностика: проверьте iostat -x 1 на узле control-plane — высокий await и %util при низком throughput. Затем выполните: lsof +L1 /var/lib/rancher/k3s/server/db/ # покажет открытые -wal/-shm strace -p $(pgrep k3s) -e trace=fsync # поймает зависшие синхронизации Решение — либо переход на внешний etcd, либо гарантия быстрого storage с гарантированной latency fsync() < 1ms. Подробнее: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=sqlite-wal-rezhim-v-k3s-control-plan