Что такое etcd и зачем он нужен

etcd — это распределённое, отказоустойчивое, сильноконсистентное key-value хранилище, реализующее алгоритм согласования Raft. В Kubernetes etcd является source of truth — там хранится всё критичное состояние кластера: объекты API (Pod, Deployment, Service, ConfigMap, Secret и т.д.), данные контроллеров и метаданные.

Основные свойства и возможности

• Сильная консистентность (linearizability). Записи в etcd проходят через Raft-лидер; большинство операций читают/записывают согласованное состояние.

• Raft-кластер и quorum. Для корректной работы нужен кворум (большинство членов). Потеря кворума делает запись невозможной.

• API с поддержкой транзакций и watch. Есть атомарные сравнения и операции, а также возможность «подписаться» (watch) на изменения ключей — это важно для реактивных контроллеров.

• Лиз (lease)/TTL. Ключи могут иметь срок жизни; используются, например, для механизма блокировок и лидер-элекции.

• Снимки (snapshot), WAL, компакция и дефрагментация. Для резервного копирования, восстановления и управления размером базы.

Роль в Kubernetes

• Хранит desired state и текущие объекты; kube-apiserver читает/записывает данные в etcd.

• Контроллеры и scheduler ориентируются на данные в etcd при принятии решений.

• Секреты по умолчанию лежат в etcd, поэтому безопасность этого хранилища критична.

Архитектурные и эксплуатационные моменты

• HA: рекомендовано разворачивать etcd кластер с нечётным числом членов (3 или 5) для обеспечения устойчивости и производительности.

• Ресурсы: etcd чувствителен к задержкам сети и дисковой подсистеме — предпочитаются SSD и низкая сетeвая латентность.

• Безопасность: обязательно TLS для клиентского и peer-трафика; ограничить доступ по сети; использовать аутентификацию/роли в etcd; дополнительно включать шифрование секретов на уровне API-сервера.

• Бэкапы и восстановление: регулярные snapshot'ы и проверка restore-процедур — обязательны. Потеря/коррупция данных в etcd может сделать кластер неконсистентным или непригодным.

• Мониторинг: метрики (latency, leader changes, db size, compaction) и оповещения по проблемам quorum, длительным GC/compaction и росту базы.

Ограничения и рекомендации по использованию

• Не храните большие бинарные объёмы и не используйте etcd как «файловое хранилище» — он предназначен для маленьких структурированных ключ-значение.

• Планируйте размер данных, периодическую компактацию и дефрагментацию.

• Тестируйте восстановление из бэкапов и процедуру при потере кворума.

• В production часто выделяют отдельные узлы или диски для etcd; в управляемых сервисах control plane/etcd может быть управляем провайдером.

Примеры операций (концептуально)

• Снятие snapshot: etcdctl snapshot save snapshot.db

• Восстановление из snapshot: etcdctl snapshot restore snapshot.db

• Просмотр членов кластера: etcdctl member list
  (на практике требуется указать endpoints, TLS-сертификаты и переменную ETCDCTL_API=3).

etcd — критическая часть Kubernetes: он отвечает за целостность и согласованность всех конфигураций и состояния. Неправильная эксплуатация, отсутствие шифрования или резервных копий могут привести к серьёзным проблемам с кластером.