Consul vs etcd: выбор key-value стораджа

Consul и etcd — два популярных инструмента для distributed KV-хранилищ. Оба используют Raft-консенсус, но решают разные задачи. Выбор зависит от конкретного use case.

Основные отличия

Consul

Фокус на service discovery и service mesh
Встроенные health checks
Built-in DNS-сервер
Multi-datacenter support из коробки
Intention-based security для service mesh

etcd

Фокус на distributed key-value store
Используется как backing store для Kubernetes
Минимальный footprint
Простой API (gRPC + HTTP)
Watch mechanism для отслеживания изменений

API сравнение

Consul

# Запись значения
curl -X PUT -d 'web-v1' http://consul:8500/v1/kv/services/web/version

# Чтение
curl http://consul:8500/v1/kv/services/web/version?raw

# Service registration
curl -X PUT -d '{
  "ID": "web-1",
  "Name": "web",
  "Tags": ["v1"],
  "Address": "10.0.0.1",
  "Port": 8080,
  "Check": {
    "HTTP": "http://10.0.0.1:8080/health",
    "Interval": "10s"
  }
}' http://consul:8500/v1/agent/service/register

# Discovery
curl http://consul:8500/v1/catalog/service/web

etcd

# Запись через etcdctl
etcdctl put /services/web/version "web-v1"

# Чтение
etcdctl get /services/web/version

# Watch на изменение ключа
etcdctl watch /services/web/version

# Диапазон ключей
etcdctl get /services/ --prefix

Производительность

etcd обычно показывает более высокую производительность для чистых KV-операций:

etcd: ~10,000 writes/sec, ~20,000 reads/sec (3-нода кластер)
Consul: ~5,000 writes/sec, ~15,000 reads/sec (3-нода кластер)

Для Kubernetes etcd — единственный выбор (это его backing store). Для service discovery и service mesh — Consul offers significantly больше функциональности.

Кластеризация

Consul

# Конфигурация серверного кластера
{
  "datacenter": "dc1",
  "data_dir": "/opt/consul/data",
  "log_level": "INFO",
  "node_name": "consul-server-1",
  "server": true,
  "bootstrap_expect": 3,
  "ui": true,
  "bind_addr": "10.0.0.1",
  "retry_join": [
    "10.0.0.2",
    "10.0.0.3"
  ],
  "encrypt": "my-secret-key"
}

etcd

# Конфигурация кластера etcd
etcd \
  --name etcd-1 \
  --initial-advertise-peer-urls http://10.0.0.1:2380 \
  --listen-peer-urls http://10.0.0.1:2380 \
  --listen-client-urls http://10.0.0.1:2379,http://127.0.0.1:2379 \
  --advertise-client-urls http://10.0.0.1:2379 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-cluster etcd-1=http://10.0.0.1:2380,etcd-2=http://10.0.0.2:2380,etcd-3=http://10.0.0.3:2380 \
  --initial-cluster-state new

Когда выбирать что

Consul лучше подходит для:

Service discovery в микросервисной архитектуре
Service mesh (Envoy integration)
Multi-datacenter service discovery
Когда нужен built-in DNS
Когда нужна ACL и intentions

etcd лучше подходит для:

Бэкенда для Kubernetes
Простого distributed KV с минимальным overhead
Когда важна максимальная производительность
Когда нужна интеграция с gRPC

Заключение

Consul и etcd — не конкуренты, а инструменты для разных задач. Consul идеален для service discovery и service mesh. etcd — лучший выбор для чистого KV-хранилища и как backing store для Kubernetes. Понимание их различий поможет сделать правильный выбор.