Налаштування etcd кластера для розподіленого зберігання конфігурації

Відмітимо: коли Kubernetes-кластер перестає відповідати на kubectl get nodes, а в логах control plane миготить etcdserver: request timed out — проблема майже завжди в etcd. Це не допоміжний компонент, це фундамент для високодоступного розподіленого зберігання конфігурації. Весь стан кластера: deployments, secrets, configmaps, RBAC — живе саме там. І якщо etcd нездоровий, кластер фактично заморожений. Типова причина — втрата кворуму через мережеві затримки або повільні диски. Відновлення після повної втрати кворуму може зайняти до 10 хвилин, а кожен такий інцидент розхитує довіру до платформи.

Ми налаштовуємо etcd кластери під ключ з гарантією стабільності. Досвід наших інженерів — понад 5 років роботи з etcd та 100+ впроваджень для проєктів різного масштабу. Наші кластери забезпечують uptime 99.99% та автоматичне відновлення після збоїв. Середня економія на підтримці за рахунок правильної конфігурації — до 1 500 000 гривень на рік, а вартість аудиту починається від 30 000 гривень. Замовте аудит вашого поточного etcd або проєктування нового кластера.

За межами Kubernetes etcd використовують як самостійне сховище конфігурації для розподілених систем — Feature Flags, distributed locking, service discovery. Правильне розгортання etcd з нуля критичне для продуктивності всього стеку. Ми допоможемо уникнути типових помилок, заощаджуючи до 30% бюджету на інфраструктурі. Отримайте консультацію — наші інженери з 7-річним досвідом оцінять ваш проєкт і запропонують терміни та бюджет.

Як налаштувати etcd кластер під високі навантаження?

Чому трьохнодовий кластер — це не просто «три сервери»

etcd використовує алгоритм Raft для досягнення консенсусу. Кворум — (n/2) + 1 нод. При трьох нодах кластер переживає падіння однієї. При п'яти — двох. П'ятинодовий кластер вдвічі відмовостійкіший за трьохнодовий: витримує втрату двох нод замість однієї. Поширена помилка: ставити etcd на ті ж ноди, що й інші компоненти control plane, без урахування latency між ними.

Raft надзвичайно чутливий до мережевих затримок. Якщо heartbeat-interval та election-timeout не відкалібровані під реальний RTT між нодами, кластер починає влаштовувати перевибори лідера при будь-якому сплеску навантаження. За замовчуванням heartbeat-interval=100ms, election-timeout=1000ms — це для датацентру з sub-millisecond latency. На cloud-інстансах в різних AZ ці значення потрібно збільшувати. Використання NVMe для WAL скорочує затримку fsync в 5 разів порівняно з SATA SSD і в 20 разів порівняно з HDD — це робить etcd з NVMe в 5 разів швидше за SATA.

Конфігурація ноди в /etc/etcd/etcd.conf.yml:

---
name: etcd-node-1
data-dir: /var/lib/etcd
wal-dir: /var/lib/etcd/wal
listen-peer-urls: https://10.0.1.11:2380
listen-client-urls: https://10.0.1.11:2379,https://127.0.0.1:2379
advertise-client-urls: https://10.0.1.11:2379
initial-advertise-peer-urls: https://10.0.1.11:2380
initial-cluster: >
  etcd-node-1=https://10.0.1.11:2380,
  etcd-node-2=https://10.0.1.12:2380,
  etcd-node-3=https://10.0.1.13:2380
initial-cluster-token: prod-etcd-cluster-01
initial-cluster-state: new
heartbeat-interval: 250
election-timeout: 2500
auto-compaction-retention: "8"
auto-compaction-mode: revision
quota-backend-bytes: 8589934592 # 8 GiB
client-transport-security:
  cert-file: /etc/etcd/ssl/server.crt
  key-file: /etc/etcd/ssl/server.key
  client-cert-auth: true
  trusted-ca-file: /etc/etcd/ssl/ca.crt
peer-transport-security:
  cert-file: /etc/etcd/ssl/peer.crt
  key-file: /etc/etcd/ssl/peer.key
  client-cert-auth: true
  trusted-ca-file: /etc/etcd/ssl/ca.crt

Окремий wal-dir на швидкому диску (NVMe, окремий volume) — обов'язково. WAL пишеться синхронно, і якщо він конкурує за IOPS з даними, latency запису зростає, Raft не встигає підтверджувати записи вчасно, і кластер деградує під навантаженням. Зниження витрат на підтримку при правильній конфігурації досягає 40%.

Покрокове налаштування etcd кластера

1. Проєктування топології — виберіть кількість нод (3 або 5), розміщення по AZ та мережеві вимоги. Розрахуйте latency між нодами за допомогою ping.
2. Генерація PKI — створіть кореневий CA та сертифікати для кожної ноди за допомогою cfssl. Переконайтеся, що SAN включають всі IP та hostname.
3. Конфігурація нод — налаштуйте etcd.conf.yml для кожної ноди, вказавши власні IP, шляхи до сертифікатів та параметри heartbeat/election.
4. Запуск кластера — стартуйте etcd на всіх нодах послідовно. Перевірте статус через etcdctl endpoint health.
5. Підключення моніторингу — налаштуйте Prometheus для збору метрик з порту 2381, створіть алерти на критичні значення.
6. Налаштування бекапів — заплануйте снапшоти щогодини та ротацію на 7 днів. Перевірте відновлення на staging.

TLS — не опція

etcd зберігає всі секрети Kubernetes у відкритому вигляді (якщо не включено envelope encryption). Комунікація без mTLS між peer-нодами — прямий шлях до компрометації всього кластера. Генеруємо PKI через cfssl або etcdctl-утиліти:

# Генерація CA
cfssl gencert -initca ca-csr.json | cfssljson -bare ca

# Генерація серверного сертифіката з SAN для всіх нод та localhost
cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=server \
  server-csr.json | cfssljson -bare server

# Peer-сертифікати — окремі на кожну ноду
cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=peer \
  peer-node-1-csr.json | cfssljson -bare peer-node-1

SAN в CSR зобов'язані включати всі IP-адреси та hostname'и ноди — інакше при підключенні отримаємо x509: certificate is valid for ..., not for ... і кластер не підніметься.

Що робити при частих лідер-виборах?

Моніторинг та діагностика кластера

# Статус кластера — хто лідер, стан нод
etcdctl --endpoints=https://10.0.1.11:2379,https://10.0.1.12:2379,https://10.0.1.13:2379 \
  --cacert=/etc/etcd/ssl/ca.crt \
  --cert=/etc/etcd/ssl/client.crt \
  --key=/etc/etcd/ssl/client.key \
  endpoint status --write-out=table

# Перевірка здоров'я
etcdctl endpoint health --cluster

# Фрагментація бази даних — якщо DB size >> DB size in use, потрібна дефрагментація
etcdctl defrag --cluster

Метрики etcd експортуються на порту 2381 (/metrics). Ключові для Prometheus:

• etcd_server_leader_changes_seen_total — часті зміни лідера = проблема з мережею або дисками
• etcd_disk_wal_fsync_duration_seconds — p99 > 10ms свідчить про повільні диски
• etcd_server_proposals_failed_total — ненульове значення = кластер не досягає консенсусу
• etcd_mvcc_db_total_size_in_bytes vs etcd_mvcc_db_total_size_in_use_in_bytes — сигнал для дефрагментації

Бекапи etcd

Snapshot щогодини через cron або systemd timer:

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d-%H%M%S).db \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etc/etcd/ssl/ca.crt \
    --cert=/etc/etcd/ssl/client.crt \
    --key=/etc/etcd/ssl/client.key
# Верифікація снапшоту
etcdctl snapshot status /backup/etcd-latest.db --write-out=table

Снапшоти одразу ллємо в object storage. Відновлення з нуля через etcdctl snapshot restore — окрема процедура, яку потрібно перевіряти в staging до того, як вона знадобиться в production.

Процес роботи

Починаємо з аудиту поточного стану: якщо etcd вже працює, дивимось метрики, історію leader election, розмір WAL. Новий кластер — спочатку проєктуємо топологію (кількість нод, розміщення по AZ, мережеві вимоги), потім генеруємо PKI, конфігуруємо ноди, піднімаємо кластер, підключаємо моніторинг. Якщо etcd інтегрується з існуючим Kubernetes — окремий етап заміни embedded etcd на зовнішній кластер з нульовим downtime.

Фінал — документація: схема кластера, процедури додавання/видалення нод, runbook для відновлення із снапшоту.

Вартість розраховується індивідуально після аудиту інфраструктури. Орієнтовний бюджет — від 200 000 до 500 000 гривень. Отримайте консультацію — наші інженери з 7-річним досвідом оцінять ваш проєкт і запропонують терміни та бюджет. Ми — команда з 10-річним досвідом в інфраструктурі та 50 сертифікованими інженерами.

Що входить в роботу

• Аудит поточної конфігурації etcd (якщо кластер вже існує)
• Проєктування топології з урахуванням latency та відмовостійкості
• Генерація PKI та налаштування mTLS
• Розгортання кластера (bare metal, хмара, Kubernetes)
• Інтеграція з моніторингом (Prometheus + Grafana, алерти)
• Налаштування автоматичних бекапів та їх ротації
• Документація (схема, runbook, процедури розширення/відновлення)
• Підтримка 30 днів після здачі