etcd部署硬件资源推荐
etcd 通常在开发或测试环境中运行良好，即使资源有限；在笔记本电脑或廉价云服务器上开发时，使用 etcd 也很常见。然而，在生产环境中运行 etcd 集群时，遵循一些硬件指南对于正确的管理非常有用。这些建议并非硬性规定；它们为稳健的生产部署提供了良好的起点。
正如以往一样，在投入生产之前，应使用模拟工作负载对部署进行测试。
CPUs
大多数 etcd 部署对 CPU 的需求并不高。典型的集群需要 2 到 4 个核心即可平稳运行。对于负载较重的部署，如服务成千上万的客户端或每秒处理数万个请求，可能会受到 CPU 限制，因为 etcd 可以从内存中处理请求。此类重负载部署通常需要 8 到 16 个专用核心。
内存（RAM）
etcd 的内存占用相对较小，但性能仍然依赖于足够的内存。etcd 服务器会积极缓存键值数据，并将大部分内存用于跟踪watchers。通常，8GB 的内存已足够。对于拥有成千上万watchers和数百万keys的重负载部署，建议分配 16GB 至 64GB 的内存。
磁盘（Disks）
快速磁盘是 etcd 部署性能和稳定性的最关键因素。
慢速磁盘会增加 etcd 请求的延迟，并可能影响集群的稳定性。由于 etcd 的共识（consensus）协议依赖于将元数据持久化存储到日志中，大多数 etcd 集群成员必须将每个请求写入磁盘。此外，etcd 还会定期将其状态增量地保存到磁盘，以便在需要时截断日志。如果这些写入操作太慢，心跳可能会超时并触发选举，从而破坏集群的稳定性。一般来说，要判断磁盘是否足够快，可以使用基准测试工具，例如 fio。可以在此处查看示例。
etcd 对磁盘写入延迟非常敏感。通常，需要 50 次顺序 IOPS（例如，7200 转速的磁盘）。对于负载较重的集群，建议使用 500 次顺序 IOPS（例如，典型的本地 SSD 或高性能虚拟化块设备）。请注意，大多数云服务提供商发布的是并发 IOPS，而非顺序 IOPS；发布的并发 IOPS 可能是顺序 IOPS 的 10 倍。要测量实际的顺序 IOPS，建议使用磁盘基准测试工具，如 diskbench 或 fio。
etcd 对磁盘带宽的要求适中，但更高的磁盘带宽可以在成员故障后更快地恢复。通常，10MB/s 的带宽可以在 15 秒内恢复 100MB 的数据。对于大型集群，建议提供 100MB/s 或更高的带宽，以在 15 秒内恢复 1GB 的数据。
如果可能，建议使用 SSD 来支持 etcd 的存储。SSD 通常提供比旋转磁盘更低的写入延迟和更小的延迟变化，从而提高 etcd 的稳定性和可靠性。如果使用旋转磁盘，建议选择最快的磁盘（如 15000 转速）。使用 RAID 0 也是提高磁盘速度的有效方法，适用于旋转磁盘和 SSD。对于至少有三个集群成员的情况，RAID 的镜像和/或奇偶校验变种并非必需；etcd 的一致性复制已能提供高可用性。
网络（Network）
多成员的 etcd 部署受益于快速且可靠的网络。为了确保 etcd 一致性和分区容忍性，不可靠的网络和分区故障会导致可用性差。低延迟确保 etcd 成员之间的快速通信。高带宽可以减少恢复失败成员所需的时间。对于常见的 etcd 部署，1GbE 网络已足够。对于大型 etcd 集群，10GbE 网络可以减少平均恢复时间。
如果可能，将 etcd 成员部署在同一数据中心，以避免延迟开销并减少分区事件的可能性。如果需要在另一个数据中心的故障域中部署，请选择距离现有数据中心更近的数据中心。有关跨数据中心部署的更多信息，请参阅调优文档。
示例硬件配置
以下是在 AWS 和 GCE 环境中的一些示例硬件配置。正如之前提到的，管理员应在将 etcd 部署投入生产之前，使用模拟工作负载进行测试。
请注意，这些配置假设这些机器完全专用于 etcd。在这些机器上运行其他应用程序可能会导致资源争用，从而导致集群不稳定。
小型集群
服务于少于 100 个客户端，每秒少于 200 个请求，存储不超过 100MB 数据。
示例应用工作负载：50 节点的 Kubernetes 集群
| 提供商 | 类型 | vCPUs | 内存（GB） | 最大并发 IOPS | 磁盘带宽（MB/s） |
|---|---|---|---|---|---|
| AWS | m4.large | 2 | 8 | 3600 | 56.25 |
| GCE | n1-standard-2 | 2 | 7.5 | 1500 | 25 |
中型集群
服务于少于 500 个客户端，每秒少于 1000 个请求，存储不超过 500MB 数据。
示例应用工作负载：250 节点的 Kubernetes 集群
| 提供商 | 类型 | vCPUs | 内存（GB） | 最大并发 IOPS | 磁盘带宽（MB/s） |
|---|---|---|---|---|---|
| AWS | m4.xlarge | 4 | 16 | 6000 | 93.75 |
| GCE | n1-standard-4 | 4 | 15 | 4500 | 75 |
大规模（Large）集群
超大规模（Large）集群服务于少于 1500 个客户端，每秒少于 10000 个请求，存储不超过 1GB 数据。
示例应用工作负载：1000 节点的 Kubernetes 集群
| 提供商 | 类型 | vCPUs | 内存（GB） | 最大并发 IOPS | 磁盘带宽（MB/s） |
|---|---|---|---|---|---|
| AWS | m4.2xlarge | 8 | 32 | 8000 | 125 |
| GCE | n1-standard-8 + 250GB PD SSD | 8 | 30 | 7500 | 125 |
超大规模（xLarge）集群
超大规模（xLarge）集群服务于超过 1,500 个客户端，每秒处理超过 10,000 个请求，存储超过 1GB 的数据。
示例应用工作负载：3,000 节点的 Kubernetes 集群
| 提供商 | 类型 | vCPUs | 内存（GB） | 最大并发 IOPS | 磁盘带宽（MB/s） |
|---|---|---|---|---|---|
| AWS | m4.4xlarge | 16 | 64 | 16,000 | 250 |
| GCE | n1-standard-16 + 500GB PD SSD | 16 | 60 | 15,000 | 250 |