Что это значит

etcd хранит всё состояние кластера Kubernetes и пишет каждое изменение на диск с синхронизацией. Если диск медленный или занят чем-то ещё, запись не укладывается в таймаут, API-сервер отвечает ошибками, контроллеры не успевают обновлять состояние. Снаружи это выглядит как зависшие выкладки, поды в CrashLoop без понятной причины и смены лидера etcd.

Частая история: на тех же дисках, что и etcd, запустили что-то тяжёлое по вводу-выводу, например сканер образов или бэкап, и etcd начал задыхаться.

Как проверить

  1. Журнал etcd: slow fdatasync, apply request took too long, смены лидера.
  2. Метрики etcd, если они собираются: etcd_disk_wal_fsync_duration_seconds (99-й перцентиль должен быть меньше 10 мс) и etcd_disk_backend_commit_duration_seconds.
  3. Нагрузка на диск узлов управления: iostat -x 5, кто читает и пишет: iotop -o.
  4. В облаке: не упирается ли диск в лимит операций ввода-вывода для своего типа и размера.

Что сделать

  1. Убрать с дисков etcd посторонние тяжёлые задачи или перенести их на другие узлы.
  2. Держать etcd на SSD, в облаке на дисках с гарантированной производительностью.
  3. Поставить алерты на время fsync и на смены лидера etcd: они срабатывают раньше, чем начинают падать поды.