ETCD官网文档系列-硬件推荐

最新推荐文章于 2025-05-27 21:45:01 发布

原创最新推荐文章于 2025-05-27 21:45:01 发布 · 611 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#etcd

kubernetes 专栏收录该内容

8 篇文章

订阅专栏

本文提供了一套硬件配置建议，针对不同规模的Etcd集群，包括CPU、内存、磁盘和网络需求，以及如何通过实例展示在AWS和GCE上的配置。生产环境部署前务必进行模拟负载测试。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Hardware recommendations

管理etcd集群的硬件指南

Etcd通常在开发或测试目的的有限资源下运行良好;在笔记本电脑或便宜的云机器上使用etcd进行开发是很常见的。然而，当在生产中运行etcd集群时，一些硬件指南对于适当的管理是有用的。这些建议并不是硬性规定;它们是健壮的生产部署的良好起点。与往常一样，部署在生产中运行之前应该使用模拟工作负载进行测试

CPUs

很少etcd部署需要大量的CPU容量。典型的集群需要2到4个内核才能平稳运行。负载重的etcd部署(每秒服务数千个客户机或数万个请求)往往受CPU限制，因为etcd可以从内存为请求服务。这种重型部署通常需要8到16个专用内核

内存

Etcd占用的内存相对较小，但它的性能仍然取决于有足够的内存。etcd服务器将积极地缓存键值数据，并将剩余的大部分内存用于跟踪监视程序。通常8GB就足够了。对于拥有数千个观察者和数百万个keys的重型部署，相应地分配16GB到64GB内存。

磁盘

快速磁盘是etcd部署性能和稳定性的最关键因素。

缓慢的磁盘将增加etcd请求延迟，并可能损害集群的稳定性。由于etcd的共识协议依赖于持久地将元数据存储到日志中，所以大多数etcd集群成员必须将每个请求写入磁盘。此外，etcd还将增量地将其状态写入到磁盘，以便截断此日志。如果这些写入花费的时间太长，心跳可能会超时并触发选举，从而破坏集群的稳定性。通常，要判断一个磁盘是否足够快，可以使用基准测试工具，如fio(https://github.com/axboe/fio)。阅读这里的例子(https://www.ibm.com/cloud/blog/using-fio-to-tell-whether-your-storage-is-fast-enough-for-etcd)。

Etcd对磁盘写延迟非常敏感。通常需要50个连续IOPS(例如，7200 RPM的磁盘)。对于负载较大的集群，推荐使用500个顺序IOPS(例如典型的本地SSD或高性能的虚拟化块设备)。请注意，大多数云提供商发布的是并发IOPS而不是顺序IOPS;发布的并发IOPS可以大于顺序IOPS 10倍。为了测量实际的顺序IOPS，我们建议使用磁盘基准测试工具，如diskbench(https://github.com/ongardie/diskbenchmark)或fio。

Etcd只需要适当的磁盘带宽，但是当失败的成员必须赶上集群时，更多的磁盘带宽可以换取更快的恢复时间。通常10MB/s可以在15秒内恢复100MB的数据。对于大型集群，建议在15秒内恢复1GB数据的速度为100MB/s或更高。

如果可能，使用SSD作为etcd的存储。SSD通常提供比机械磁盘更低的写延迟和更小的变化，从而提高了etcd的稳定性和可靠性。如果使用机械磁盘，请尽可能使用最快的磁盘(15,000 RPM)。对于机械磁盘和SSD，使用RAID 0也是一种提高磁盘速度的有效方式。对于至少三个集群成员，不需要RAID的镜像和/或奇偶校验变体;Etcd的一致性复制已经获得了高可用性

网络

多成员etcd部署受益于快速和可靠的网络。为了使etcd既一致又能容忍分区，带有分区中断的不可靠网络将导致较差的可用性。低延迟确保etcd成员可以快速通信。高带宽可以减少恢复失败的etcd成员的时间。1GbE对于普通的etcd部署已经足够了。对于大型etcd集群，10GbE网络将减少恢复的平均时间。

尽可能在单个数据中心中部署etcd成员，以避免延迟开销并减少分区事件的可能性。如果需要在其他数据中心中设置故障域，请选择离现有数据中心较近的数据中心。还请阅读调优(https://etcd.io/docs/v3.5/tuning/)文档，了解有关跨数据中心部署的更多信息