etcd 通常在资源有限的情况下运行良好，用于开发或测试目的； 在笔记本电脑或便宜的云机器上使用 etcd 进行开发是很常见的。 但是，在生产中运行 etcd 集群时，一些硬件指南对于正确管理很有用。 这些建议并不是硬性规定； 它们是强大的生产部署的良好起点。 与往常一样，在生产中运行之前，应使用模拟工作负载测试部署。 CPUs很少有 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的数据。对于大型集群，建议在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 成员，以避免延迟开销并减少分区事件的可能性。 如果需要另一个数据中心的故障域，请选择更靠近现有数据中心的数据中心。 另请阅读 调优 文档以获取有关跨数据中心部署的更多信息。 硬件配置示例以下是 AWS 和 GCE 环境中的一些示例硬件设置。 如前所述，但无论如何必须强调，管理员应该在将 etcd 部署投入生产之前使用模拟工作负载对其进行测试。 请注意，这些配置假设这些机器完全专用于 etcd。 在这些机器上与 etcd 一起运行其他应用程序可能会导致资源争用并导致集群不稳定。 小规模集群小型集群服务的客户端少于 100 个，每秒请求少于 200 个，存储的数据不超过 100MB。 示例应用程序工作负载：一个 50 节点的 Kubernetes 集群
中等规模集群中型集群服务于少于 500 个客户端，每秒少于 1,000 个请求，并且存储不超过 500MB 的数据。 示例应用程序工作负载：一个 250 节点的 Kubernetes 集群
大规模集群一个大型集群服务的客户端少于 1,500 个，每秒少于 10,000 个请求，并且存储的数据不超过 1GB。 示例应用程序工作负载：一个 1,000 节点的 Kubernetes 集群
超大规模集群一个 xLarge 集群服务超过 1,500 个客户端，每秒处理超过 10,000 个请求，并存储超过 1GB 的数据。 示例应用程序工作负载：一个 3,000 节点的 Kubernetes 集群
|
