etcd в Kubernetes: как работает хранилище кластера и где ломается на практике

Зачем в Kubernetes вообще нужен etcd

Если упростить, Kubernetes без etcd не знает, какие есть ноды, поды, сервисы, секреты и вообще «какое сейчас состояние мира». kube-apiserver принимает запросы, валидирует их и сохраняет состояние в etcd. Остальные компоненты control plane читают это состояние и приводят реальный кластер к нужному виду.

Главный практический вывод: большинство «странных» проблем control plane сводится к тому, что etcd не успевает подтверждать записи, теряет quorum или упирается в диск/CPU/сеть. Поэтому расследование часто начинается с вопросов к etcd: как быстро он синхронно пишет на диск, насколько стабилен лидер, нет ли раздувшейся базы и признаков проблем консенсуса.

Если control plane живёт на ваших серверах, держите etcd на предсказуемой инфраструктуре: на выделенных ресурсах и с нормальной дисковой подсистемой. Для небольших production-кластеров часто проще и надёжнее вынести control plane на отдельные VDS, чем пытаться ужать его рядом с «шумными» ворклоадами.

Как etcd хранит данные: Raft, quorum и leader election

etcd — распределённое хранилище ключ-значение, использующее протокол Raft для консенсуса. В кластере есть один leader и несколько followers. Все записи проходят через лидера: он принимает proposal, реплицирует лог на фолловеры и считает операцию подтверждённой, когда её приняли (и надёжно зафиксировали) большинство узлов — это и есть quorum.

Ключевые понятия, которые помогают диагностировать сбои:

• Quorum: большинство участников. Для 3 узлов — 2, для 5 узлов — 3. Если quorum не набирается, операции записи не подтверждаются, а компоненты Kubernetes начинают упираться в таймауты.
• Leader election: выбор лидера. Частые перевыборы почти всегда означают проблемы с сетью, диском, перегрузкой CPU либо «стоп-мир» паузами из-за давления памяти/планировщика.
• Raft log: журнал операций. Пока он не «подчищен» (compaction/snapshot), нагрузка и размер обслуживаемых данных растут.

Практический нюанс: даже при идеальной сети cluster-wide latency по записи будет определяться самым медленным участником «большинства». В трёхузловом etcd один узел с плохим диском способен испортить жизнь всему control plane, потому что лидеру нужно подтверждение хотя бы от одного фолловера. Если именно «медленный» фолловер регулярно оказывается в цепочке кворума, задержки становятся системными.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Почему disk latency и fsync — главный враг etcd

etcd пишет данные в WAL (write-ahead log) и в backend (bbolt). Для корректности консенсуса ему важно гарантировать, что запись действительно попала на стабильное хранилище. Поэтому критичная операция — fsync (принудительная синхронизация на диск). Если диск медленный или нестабилен по задержкам, «пики» в disk latency напрямую превращаются в задержки подтверждения raft-операций.

Как это проявляется со стороны Kubernetes:

• kubectl «подвисает», kube-apiserver отвечает с задержками или отдаёт 500/timeout.
• kube-controller-manager и kube-scheduler жалуются на таймауты при работе с API.
• Кластер начинает «дрожать»: ретраи, рост очередей, лавина событий, повышение нагрузки на control plane.

Для etcd важна не столько «средняя скорость диска», сколько предсказуемость задержек. 99-й перцентиль по latency часто важнее среднего значения.

Если вы ловите «редкие, но болезненные» подвисания API, почти всегда стоит искать именно хвосты распределения: очереди в storage, скачки await, проблемы на уровне гипервизора или backend-хранилища.

Что чаще всего делает fsync медленным

• Сетевые диски и перегруженные СХД: latency скачет, а Raft чувствует каждый скачок.
• Overcommit на хосте: «шумные соседи», contention по IO, очереди в гипервизоре.
• Недостаток IOPS из-за неверного типа диска/класса хранения или агрессивного throttling.
• Паузы планировщика: высокий steal time, проблемы CPU scheduling, давление памяти.

Симптомы проблем etcd и что проверять в первую очередь

Ниже — практичный чеклист, который помогает быстро понять, «это etcd или нет», и в какую сторону копать.

1) Признаки потери quorum или нестабильного лидера

Если лидер часто меняется, задержки по записи растут каскадом. Смотрите логи etcd и события control plane: упоминания election, term change, timeout, peer became inactive.

Наблюдение, которое часто экономит время: если чтения иногда нормальные, а записи почти всегда тормозят, вероятность проблем с подтверждением Raft (диск/кворум/перевыборы) очень высокая.

2) Диск: latency и очереди во время инцидента

На хостах с etcd важно оценивать не только throughput, но и latency. В момент инцидента полезны iostat, pidstat, iotop и системные метрики по очередям/задержкам. Ищите корреляцию: рост задержек API ↔ рост latency по диску ↔ рост времени commit/apply в etcd.

3) Размер базы и состояние backend

etcd может быть «жив», но деградировать из-за большого размера backend, фрагментации и неаккуратной политики compaction. Это типично для кластеров с большим количеством объектов, активными контроллерами и высоким churn (частые пересоздания подов, events, leases).

etcd metrics: какие метрики реально помогают

В эксплуатации etcd полезно воспринимать как отдельный критичный сервис со своими SLI. Даже если у вас пока нет идеальной observability, минимальный набор метрик сильно упрощает расследования.

Латентность и производительность

• Raft commit/apply latency: сколько времени уходит на подтверждение и применение операций.
• Backend commit duration: косвенно показывает влияние диска и стоимости fsync.
• DB size и скорость роста: если размер растёт бесконтрольно, почти неизбежны окна деградации и потребность в обслуживании (compaction/defrag).

Стабильность кластера

• Leader changes: частая смена лидера — красный флаг (сеть, диск, CPU starvation).
• Peer round-trip time и Raft-сообщения: помогают увидеть, кто тормозит quorum.

Очереди и «косвенные симптомы»

• Slow requests: отличный индикатор деградации ещё до падения.
• FD/ресурсные лимиты: проблемы с дескрипторами и лимитами процессов часто приводят к вторичным эффектам и нестабильности.

Отдельная практика: фиксируйте «норму» по метрикам (baseline) на здоровом кластере. Без этого легко спорить о «вроде медленно», но трудно доказать, что началась именно деградация.

Alarms в etcd: что означают и как действовать

Механизм alarms — это не «просто лог», а сигнал о состоянии, которое требует вмешательства. Типичные alarms связаны с пространством на диске, превышением лимитов backend и угрозой остановки записи.

Что важно в реальной эксплуатации:

• Alarm — это симптом. Лечить нужно причину: место на диске, рост базы, отсутствие compaction или невозможность корректно обслуживать backend.
• Игнорирование alarms часто заканчивается тем, что etcd переходит в защитный режим и перестаёт принимать новые записи. Для Kubernetes это быстро превращается в «встал control plane».

Compaction и defrag: зачем нужны обе операции

В etcd часто путают две разные вещи — compaction и defrag. Обе важны, но решают разные задачи.

Compaction: логическая «уборка истории»

etcd хранит историю изменений (ревизии). Compaction удаляет старые ревизии и сокращает объём исторических данных, которые больше не нужны. Это снижает стоимость чтения истории, ограничивает рост данных для обслуживания и в целом стабилизирует поведение базы.

Практический эффект: после compaction «логическая» масса истории уменьшается, но файл базы на диске может почти не уменьшиться.

Defrag: физическое уплотнение файла базы

Defrag уплотняет backend, возвращая неиспользуемое место внутри файла. Данные переписываются более компактно. Это может заметно уменьшить размер файла и улучшить локальность, но операция IO-тяжёлая: её нужно планировать и делать по очереди на членах кластера.

Типичная безопасная стратегия обслуживания

• Делайте compaction регулярно (частота зависит от churn и политики хранения).
• Делайте defrag по расписанию или по порогу (например, если размер файла заметно выше ожидаемого или после крупной compaction).
• Не запускайте тяжёлые операции одновременно на всех членах: держите quorum и контролируйте latency.

Compaction держит историю под контролем, а defrag возвращает физическое место и снижает «раздутие» файла. В стабильной эксплуатации обычно нужен тандем.

Команды: посмотреть статус, сделать snapshot, compaction и defrag

Ниже — базовые примеры с etcdctl. Выполняйте их на control plane-ноде, где настроены доступ и сертификаты. Перед обслуживанием полезно сделать snapshot.

etcdctl endpoint status --write-out=table
etcdctl endpoint health --write-out=table
etcdctl snapshot save /var/backups/etcd/snapshot.db
etcdctl alarm list
etcdctl compact 1234567
etcdctl defrag

В production-режиме компакцию обычно делают до «приближённой текущей ревизии», а не наугад. Оптимальный конкретный ревизионный номер берут из статуса эндпоинтов (чтобы не ошибиться с отставшими членами) и выполняют операцию осознанно, учитывая нагрузку.

Почему etcd «всё ещё жив», но Kubernetes уже «плохой»

Одна из самых неприятных ситуаций: etcd отвечает на health-check, но пользователи видят деградацию. Причина проста: health-check часто проверяет «живость» процесса и базовую доступность, а не способность кластера быстро подтверждать записи и держать стабильный Raft.

• etcd «зелёный», но commit latency растёт до сотен миллисекунд и секунд.
• kube-apiserver начинает копить очередь запросов, kube-controller-manager получает лавину ретраев.
• Нагрузка растёт и ещё сильнее ухудшает задержки — замкнутый круг.

Выход — смотреть не только «жив/не жив», а латентность записи, смену лидера, задержки диска и размер базы. И держать под рукой план «что делать в первые 15 минут».

Разбор частых сценариев инцидентов

Сценарий A: резкий рост disk latency на одном узле

Как проявляется: всплески задержек API, периодические таймауты, иногда leader election.

Что делать: определить, какой член тормозит quorum (по метрикам и endpoint status), и оценить, можно ли временно вывести его из состава без потери доступности (например, при 5 членах). Параллельно разбирать диск: очередь, троттлинг, конкуренция за IO, проблемы на уровне хоста.

Сценарий B: постоянные leader changes

Как проявляется: «дрожание» control plane, периодические окна недоступности, в логах — частые election.

Что делать: проверить сетевую связность между членами (потери, jitter), время на нодах, CPU starvation и steal time, а также паузы процесса. Почти всегда это не «баг Raft», а инфраструктурная нестабильность. Из смежных тем по отказоустойчивости (в части кворума и DCS) может быть полезен разбор: как работает DCS и фейловер в HA-схемах.

Сценарий C: база etcd раздулась, compaction давно не делали

Как проявляется: постепенное ухудшение производительности, рост времени операций, увеличение IO даже без роста нагрузки.

Что делать: планировать обслуживание: compaction, затем defrag. Выполнять поочерёдно на членах кластера, контролируя latency и сохраняя quorum. Перед обслуживанием — snapshot.

Минимальный набор операционных правил для стабильного etcd

• Три или пять членов: это базовая практика, позволяющая переживать отказ узла и сохранять quorum.
• Стабильный диск с низкой latency: важны 95/99 перцентили, а не «в среднем быстро».
• Изоляция ресурсов: избегайте конкуренции за диск/CPU рядом с etcd.
• Мониторинг не только health, но и метрик по задержкам, leader changes, размеру базы и slow requests.
• Регламент на compaction/defrag и обработку alarms, чтобы обслуживание было плановым, а не аварийным.

Чеклист: что собрать для нормального troubleshooting

Во время инцидента «правильные» данные решают половину проблемы. Старайтесь собрать:

• Значения/графики disk latency и очередей на всех членах etcd (и на хосте/СХД, если есть доступ).
• События leader election и частоту смены лидера.
• Размер базы, скорость роста, факт compaction/defrag и их время.
• Ошибки/предупреждения из логов etcd и компонентов control plane про timeouts/slow requests.

Если собраны эти четыре группы сигналов, обычно быстро становится ясно: проблема в диске, сети, CPU starvation или в обслуживании базы. Дальше вы уже не гадаете, а действуете по плану. Для некоторых инфраструктурных разборов по производительности HTTP-стека и очередям на сервере может пригодиться материал: как диагностировать очереди и буферизацию на стороне веб-сервера.

Итоги

etcd в Kubernetes — это ядро состояния, и его поведение определяют quorum, Raft и стабильность лидера, а также физика диска и стоимость fsync. Для устойчивой работы важны метрики (особенно latency), внимательность к alarms и регулярные compaction/defrag. Когда эти практики настроены, большинство «загадочных» проблем control plane превращаются в понятные операционные задачи с повторяемым планом действий.