etcd

etcd — это распределённое, отказоустойчивое хранилище данных типа «ключ-значение» с открытым исходным кодом, предназначенное для хранения конфигурационной информации, обнаружения сервисов и координации работы распределённых систем. Разработано на языке Go компанией CoreOS (ныне часть Red Hat, входящей в IBM). etcd является одной из ключевых технологий в экосистеме контейнеризации и оркестрации, в первую очередь — платформы Kubernetes.

История

Проект etcd был основан в июне 2013 года Брэндоном Филипсом (Brandon Philips) и Алексом Полви (Alex Polvi) из компании CoreOS. Изначально он создавался как замена ZooKeeper и Doozer для управления конфигурациями операционной системы CoreOS. Название «etcd» происходит от словосочетания «/etc» (каталог конфигурационных файлов в Unix-подобных системах) и «distributed» (распределённый).

В декабре 2013 года etcd был официально представлен сообществу с открытым исходным кодом. В 2014 году проект был принят в инкубатор Cloud Native Computing Foundation (CNCF), а в 2018 году стал зрелым проектом CNCF. Ключевым этапом развития стало принятие etcd в качестве основного хранилища состояния для Kubernetes, начиная с версии 1.0 (2015 год). С тех пор etcd активно развивается: вышли версии 3.x, в которых была значительно улучшена производительность, добавлена поддержка транзакций, наблюдателей (watchers) и сжатия истории изменений.

Архитектура и принципы работы

Распределённая природа

etcd спроектирован как кластерное решение, состоящее из нескольких узлов (обычно 3, 5 или 7). Кластер обеспечивает отказоустойчивость: при выходе из строя части узлов (до (N-1)/2, где N — количество узлов) система продолжает корректно функционировать. etcd использует протокол консенсуса Raft для согласования состояния между узлами. Raft гарантирует, что все узлы кластера будут иметь одинаковое состояние данных, даже при сбоях сети или отказе отдельных узлов.

Модель данных

Данные в etcd хранятся в виде иерархического пространства ключей (key-value store). Ключи организованы в древовидную структуру, аналогичную файловой системе, с разделителем «/». Например, ключ /config/app/database/connection может содержать значение строки подключения. Каждый ключ может иметь версию, время создания и время последнего изменения. etcd поддерживает:

• TTL (Time-To-Live) — автоматическое удаление ключей по истечении заданного времени.
• Транзакции — атомарные операции сравнения-и-замены (compare-and-swap, CAS) и сравнения-и-удаления.
• Наблюдатели (watchers) — механизм, позволяющий клиентам подписываться на изменения определённых ключей или префиксов и получать уведомления в реальном времени.
• Лизы (leases) — механизм аренды, позволяющий связывать несколько ключей с одним временем жизни.

Протокол gRPC

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

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

Хранение конфигураций

etcd является централизованным хранилищем конфигурационных данных для распределённых приложений. Приложения могут читать актуальные настройки из etcd, а при изменении конфигурации — получать уведомления через watcher. Это позволяет динамически обновлять параметры без перезапуска сервисов.

Обнаружение сервисов (Service Discovery)

Сервисы могут регистрировать своё местоположение (IP-адрес и порт) в etcd при запуске и удалять запись при остановке. Другие сервисы могут находить их через запросы к etcd. Механизм TTL и keep-alive (продление аренды) гарантирует, что записи о неработающих экземплярах будут автоматически удалены.

Координация распределённых систем

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

Хранение состояния Kubernetes

Основное применение etcd в современной инфраструктуре — это хранение состояния кластера Kubernetes. Все объекты Kubernetes (поды, сервисы, деплойменты, конфигурационные карты, секреты и т.д.) хранятся в etcd. При каждом изменении состояния кластера (например, создание пода) соответствующая запись обновляется в etcd. Без etcd работа Kubernetes невозможна.

Версии и API

etcd v2 (устаревшая)

Использовала простой HTTP/JSON API. Поддерживала базовые операции: Set, Get, Delete, Watch. Имела ограниченную производительность и не поддерживала транзакции. Версия v2 считается устаревшей и не рекомендуется к использованию в новых проектах.

etcd v3 (актуальная)

Версия v3, выпущенная в 2016 году, представила:

• gRPC API (с обратной совместимостью через HTTP-шлюз).
• Поддержку транзакций (TX).
• Механизм сжатия истории (compaction) для удаления старых версий ключей.
• Улучшенную производительность (до 10 000 записей в секунду на кластер).
• Поддержку лизингов (leases) и наблюдателей с фильтрацией по префиксу.

API v3 несовместим с v2, но etcd может одновременно обслуживать оба API (режим совместимости).

Производительность и масштабирование

Производительность etcd зависит от размера кластера, задержек в сети и типа операций. Типичные показатели для кластера из 3 узлов:

• Запись: до 10 000 операций в секунду (при размере значения до 1 КБ).
• Чтение: до 100 000 операций в секунду (при использовании кэширования на стороне клиента).
• Задержка записи: 1–5 мс (в локальной сети).

Масштабирование etcd осуществляется только путём увеличения числа узлов (вертикальное масштабирование неэффективно из-за природы протокола Raft). Для увеличения производительности записи рекомендуется использовать более быстрые диски (SSD/NVMe) и оптимизировать сетевые задержки.

Безопасность

etcd поддерживает несколько механизмов защиты:

• TLS/SSL — шифрование трафика между клиентом и сервером, а также между узлами кластера.
• Аутентификация — на основе имени пользователя и пароля или сертификатов клиента.
• Авторизация — ролевая модель (RBAC), позволяющая ограничивать доступ к определённым ключам и операциям.
• Шифрование данных на диске — опционально, через шифрование файловой системы.

Инструменты и экосистема

etcdctl

Основная утилита командной строки для взаимодействия с etcd. Поддерживает все операции API v3: put, get, del, watch, txn, lease, snapshot и другие.

etcdutl

Утилита для администрирования кластера: создание и восстановление снимков (snapshots), проверка целостности данных, миграция между версиями.

Клиентские библиотеки

Официальные клиенты доступны для Go, Java, Python, C++, Ruby, .NET, Node.js и других языков. Библиотеки реализуют протокол gRPC и предоставляют высокоуровневые API для работы с etcd.

Интеграция с Kubernetes

В Kubernetes etcd является компонентом control plane. Администраторы могут управлять etcd через kubectl (например, резервное копирование через etcdctl snapshot save). Для мониторинга etcd используются метрики Prometheus, которые собираются по умолчанию.

Сравнение с аналогами

Критика и ограничения

• Сложность администрирования: Настройка и обслуживание кластера etcd требуют высокой квалификации, особенно при сбоях сети или потере кворума.
• Ограниченный размер данных: etcd не предназначен для хранения больших объёмов данных (рекомендуется не более 8 ГБ на кластер для оптимальной производительности). Для больших данных используются специализированные БД.
• Зависимость от дисков: Производительность записи сильно зависит от скорости дисков (HDD недопустимы, только SSD/NVMe).
• Проблемы с версионированием: При длительной работе без сжатия истории может накапливаться большое количество версий, что приводит к росту размера БД и снижению производительности.
• Отсутствие встроенного шардинга: etcd не поддерживает автоматическое распределение данных по нескольким кластерам (шардинг). Для масштабирования за пределы одного кластера требуется ручная настройка или использование сторонних решений.

Источники

1. Официальная документация etcd (etcd.io)
2. Cloud Native Computing Foundation (CNCF) — проект etcd
3. Документация Kubernetes (kubernetes.io) — раздел «Хранение состояния»
4. Статья «etcd: A Distributed Key-Value Store» (CoreOS, 2013)
5. Книга «Designing Data-Intensive Applications» (Martin Kleppmann, 2017) — раздел о протоколах консенсуса
6. Исходный код проекта etcd на GitHub (github.com/etcd-io/etcd)