Кластер на k3s молчит, но все процессы на месте. systemctl status — зеленый, логи чистые. А между тем: SQLite, используемый вместо etcd, работает в WAL-режиме по умолчанию. При активной записи (например, при частых обновлениях CustomResource или Helm-релизов) WAL-файл растет, и каждая контрольная точка требует fsync. На медленном диске или при I/O contention это блокирует весь control-plane. Диагностика: - iotop -oPa — покажет пики записи от process [k3s-server] - cat /proc/$(pgrep k3s-server)/fdinfo/ | grep pos — рост позиции в WAL - strace -p $(pgrep k3s-server) -e sync,fdatasync — частые вызовы синхронизации Решение — либо отказ от WAL (PRAGMA journal_mode=DELETE), либо вынос БД на быстрый NVMe с отключенным write-cache flush, либо переход на внешний etcd. Но последнее — уже не «lightweight». Подробнее: https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=sqlite-wal-rezhim-v-k3s-control-plan

Кластер на k3s молчит, но все процессы на месте. systemctl status — зеленый, логи чистые. А между тем: SQLite, используемый вместо etcd, работает в WAL-режиме по умолчанию | Сетка — социальная сеть от hh.ru