etcd faq part 1 RAFT abstract, configuration, deployment requirements
https://etcd.io/docs/v3.4/faq/
(now you know why I had a consensus algorithm video!) etcd is a distributed key-value store developed by CoreOS, primarily used to store and manage configuration data, state information, and metadata for distributed systems. It is known for providing strong consistency and reliability through the Raft consensus algorithm, making it suitable for critical data storage in clustered environments. Commonly utilized by Kubernetes to manage cluster state and configurations, etcd ensures that data is consistently replicated across multiple nodes, enhancing system resilience and availability.
---
Why doesn’t changing --listen-peer-urls or --initial-advertise-peer-urls update the advertised peer URLs in etcdctl member list?
A member’s advertised peer URLs come from --initial-advertise-peer-urls on initial cluster boot. Changing the listen peer URLs or the initial advertise peers after booting the member won’t affect the exported advertise peer URLs since changes must go through quorum to avoid membership configuration split brain. Use etcdctl member update to update a member’s peer URLs.
Deployment
System requirements
Since etcd writes data to disk, its performance strongly depends on disk performance. For this reason, SSD is highly recommended. To assess whether a disk is fast enough for etcd, one possibility is using a disk benchmarking tool such as fio. For an example on how to do that, read here. To prevent performance degradation or unintentionally overloading the key-value store, etcd enforces a configurable storage size quota set to 2GB by default. To avoid swapping or running out of memory, the machine should have at least as much RAM to cover the quota. 8GB is a suggested maximum size for normal environments and etcd warns at startup if the configured value exceeds it. At CoreOS, an etcd cluster is usually deployed on dedicated CoreOS Container Linux machines with dual-core processors, 2GB of RAM, and 80GB of SSD at the very least. Note that performance is intrinsically workload dependent; please test before production deployment. See hardware for more recommendations.