硬件建议

etcd 通常在开发或测试目的下使用有限的资源运行良好；在笔记本电脑或廉价云机器上开发 etcd 是很常见的。然而，在生产环境中运行 etcd 集群时，一些硬件指南对于正确的管理是有用的。这些建议并不是硬性规定；它们是稳健生产部署的良好起点。一如既往，在投入生产之前，应使用模拟工作负载对部署进行测试。

CPU

很少有 etcd 部署需要大量的 CPU 容量。典型的集群需要两到四个核心才能平稳运行。负载较重的 etcd 部署，服务数千个客户端或每秒数万次请求，往往会受到 CPU 的限制，因为 etcd 可以从内存中提供请求。这种高负载部署通常需要八个到十六个专用核心。

内存

etcd 的内存占用相对较小，但其性能仍然依赖于足够的内存。etcd 服务器会积极缓存键值数据，并将大部分剩余内存用于跟踪观察者。通常 8GB 就足够了。对于有数千个观察者和数百万个键的高负载部署，应相应地分配 16GB 到 64GB 的内存。

磁盘

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

慢速磁盘会增加 etcd 请求的延迟，并可能损害集群的稳定性。由于 etcd 的共识协议依赖于持久化存储元数据到日志中，大多数 etcd 集群成员必须将每个请求写入磁盘。此外，etcd 还会逐步将其状态检查点写入磁盘，以便可以截断该日志。如果这些写操作花费太长时间，心跳可能会超时并触发选举，从而破坏集群的稳定性。一般来说，要判断磁盘是否足够快以供 etcd 使用，可以使用基准测试工具如 fio。请参阅这里的示例。

etcd 对磁盘写入延迟非常敏感。通常需要 50 个顺序 IOPS（例如，7200 RPM 磁盘）。对于负载较重的集群，建议使用 500 个顺序 IOPS（例如，典型的本地 SSD 或高性能虚拟化块设备）。请注意，大多数云提供商发布的并发 IOPS 而不是顺序 IOPS；发布的并发 IOPS 可能比顺序 IOPS 高出 10 倍。为了测量实际的顺序 IOPS，我们建议使用磁盘基准测试工具如 diskbench 或 fio。

etcd 仅需要适度的磁盘带宽，但更多的磁盘带宽可以加快故障成员追赶集群的速度。通常 10MB/s 可以在 15 秒内恢复 100MB 数据。对于大型集群，建议使用 100MB/s 或更高的速度，以便在 15 秒内恢复 1GB 数据。

尽可能使用 SSD 作为 etcd 的存储支持。SSD 通常提供更低的写入延迟和更小的波动，从而提高 etcd 的稳定性和可靠性。如果使用机械硬盘，请选择最快的硬盘（15,000 RPM）。使用 RAID 0 也是提高磁盘速度的有效方法，无论是机械硬盘还是 SSD。只要有至少三个集群成员，镜像和/或奇偶校验变体的 RAID 就是不必要的；etcd 的一致复制已经实现了高可用性。

网络

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

尽可能在同一数据中心内部署 etcd 成员，以避免延迟开销并减少分区事件的可能性。如果需要在另一个数据中心中设置故障域，请选择一个离现有数据中心较近的数据中心。请参阅调优文档以获取有关跨数据中心部署的更多信息。

示例硬件配置

以下是一些 AWS 和 GCE 环境中的硬件配置示例。如前所述，但必须强调的是，管理员应在将 etcd 部署投入生产之前使用模拟工作负载进行测试。

请注意，这些配置假设这些机器完全专用于 etcd。在这些机器上运行其他应用程序可能会导致资源争用，并导致集群不稳定。

小型集群

小型集群服务于少于 100 个客户端，每秒请求少于 200 次，并存储不超过 100MB 的数据。

示例应用工作负载：一个 50 节点的 Kubernetes 集群

中型集群

中型集群服务于少于 500 个客户端，每秒请求少于 1,000 次，并存储不超过 500MB 的数据。

示例应用工作负载：一个 250 节点的 Kubernetes 集群

大型集群

一个大型集群服务的客户端少于 1,500 个，每秒请求数少于 10,000 次，并且存储的数据不超过 1GB。

示例应用程序负载：一个 1,000 节点的 Kubernetes 集群

超大型集群

一个超大型集群服务的客户端多于 1,500 个，每秒请求数多于 10,000 次，并且存储的数据超过 1GB。

示例应用程序负载：一个 3,000 节点的 Kubernetes 集群