etcd vs Consul: qual key-value store?
O etcd é um key-value store focado e fortemente consistente (o backing store do Kubernetes); o Consul é uma plataforma mais ampla de service discovery, KV e service mesh.
O etcd faz uma coisa bem: um key-value store fortemente consistente baseado em Raft, famoso por ser o store do control plane do Kubernetes. O Consul adiciona service discovery, health checking, suporte multi-datacenter e o service mesh Connect sobre um KV store. O etcd vence em foco e simplicidade para armazenamento consistente de configuração; o Consul vence em service discovery e recursos de mesh.
| etcd | Consul | |
|---|---|---|
| Escopo | KV store | Discovery + KV + mesh |
| Consistência | Forte (Raft) | Forte (Raft) |
| Service discovery | Não (só KV) | De primeira classe |
| Mesh | Não | Connect |
| Melhor para | K8s, config store | Discovery, multi-DC, mesh |
Caso de uso e escopo
O etcd serve a um store de configuração/coordenação focado e confiável, especialmente no Kubernetes. O Consul serve a service discovery, health checks, configurações multi-datacenter e service mesh, onde seu conjunto de recursos mais amplo compensa.
Adequação a ops e CI
O etcd é mais simples, com uma superfície estreita; o Consul tem mais recursos e superfície operacional. Ambos são testados via integração no CI contra clusters efêmeros, onde runners gerenciados mais rápidos encurtam o startup de quórum e os testes de discovery.
O veredito
Quer um KV store focado e fortemente consistente (ou você roda Kubernetes): etcd. Quer service discovery, multi-DC e um service mesh: Consul. O escopo decide; o etcd é minimalista, o Consul é uma plataforma.