В 03:17 K3s начал отвечать с задержкой, а мониторинг обвинил «рост базы». Это не синхронизация etcd: встроенный SQLite работает с одним writer. WAL может расти, когда долгий reader удерживает snapshot и checkpoint не может вернуть страницы в state.db. API ждёт блокировку или fdatasync, поэтому CPU выглядит почти пустым. Проверка начинается с фактов: ls -lh /var/lib/rancher/k3s/server/db/state.db; затем sqlite3 /var/lib/rancher/k3s/server/db/state.db 'PRAGMA journalmode; PRAGMA walcheckpoint(PASSIVE);'. Результат checkpoint показывает, сколько страниц осталось в WAL и был ли BUSY. Не удаляйте state.db-wal вручную: это не кэш, а часть незавершённой транзакционной истории. На узле смотрим не только дисковое место: iostat -xm 1, pidstat -d -p $(pidof k3s) 1, cat /proc/pressure/io. Для короткого окна диагностики — strace -ttT -e trace=fdatasync, fsync, pwrite64 -p $(pidof k3s): длинные вызовы fsync подтверждают упор в storage, а не в сеть. Отдельно фиксируйте размер WAL, p99 API и latency устройства. SQLite в K3s не даёт распределённой отказоустойчивости etcd: это локальная база с одним писателем. Сначала обеспечьте быстрый и предсказуемый диск, контролируемый checkpoint и резервное копирование. Если нужны несколько control-plane и автоматический failover, выбирайте поддерживаемый внешний datastore, а не маскируйте пределы SQLite настройками таймаутов. Подробнее: https://ftops.space/? utmsource=telegram&utmmedium=smm&utmcampaign=ftops&utmcontent=sqlite-wal-rezhim-v-k3s-control-plane