Внезапные задержки в K3s API-сервере при масштабировании кластера — не проблема сети и не CNI. Причина: SQLite в WAL-режиме, используемый как замена etcd, начинает страдать от checkpoint stalls. По умолчанию walautocheckpoint=1000 страниц, но при высокой частоте записи (например, от множества контроллеров или операторов) WAL-файл раздувается, а фоновый checkpoint не успевает сбрасывать данные на диск. Это вызывает блокировки записи до завершения checkpoint. Диагностика: - lsof +L1 /var/lib/rancher/k3s/server/db/ — покажет открытые unlinked WAL-файлы. - strace -p $(pgrep k3s-server) -e trace=fsync,syncfilerange — выявит долгие fsync. - journalctl -u k3s -f | grep -i 'slow' — логи самого сервера часто честнее дашбордов. Решение — явно установить PRAGMA walautocheckpoint=500 или меньше, либо перейти на внешний datastore. Подробнее: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=sqlite-wal-rezhim-v-k3s-control-plan

Внезапные задержки в K3s API-сервере при масштабировании кластера — не проблема сети и не CNI. Причина: SQLite в WAL-режиме, используемый как замена etcd, начинает страдать от checkpoint stalls | Сетка — социальная сеть от hh.ru