Оптимизация etcd на медленных дисках в Kubernetes

В Kubernetes etcd — это база данных, в которой хранится всё состояние кластера.
Если etcd работает на медленных дисках, начинаются проблемы: kubectl отвечает дольше, поды остаются в Pending, а API-сервер «тормозит».

Почему etcd тяжело на медленных дисках

etcd очень зависим от дисковой подсистемы. Каждая запись фиксируется на диск для консистентности.
На HDD или дешёвых облачных дисках с низкими IOPS etcd быстро превращается в узкое место.

Типичные признаки:

  • Долгие ответы на kubectl
  • Подов много в Pending
  • Повышенная задержка API
  • Директория /var/lib/etcd быстро разрастается

Запуск дефрагментации

etcd хранит историю изменений (MVCC). Даже если ключи удаляются, база продолжает расти.
Поэтому используется команда defrag, которая освобождает место.

Пример:

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  defrag

Эту операцию можно запускать регулярно через CronJob или systemd timer.

Лучшие практики для медленных дисков

  • Регулярная дефрагментация — предотвращает разрастание БД.
  • Ограничение размера — параметр –quota-backend-bytes.
  • По возможности перенести etcd на SSD/NVMe.
  • Мониторить задержки — метрики (etcd_disk_wal_fsync_duration_seconds).
  • Выделенные ресурсы — не запускать etcd рядом с «шумными соседями».

Итог

Работа etcd на медленных дисках рискованна, но с правильной настройкой — дефрагментация, квоты и мониторинг — кластер будет работать стабильнее. Для критичных сред лучше всегда использовать SSD.