最近，我一直在学习有关 Kubernetes 的知识，并了解到 Kubernetes 可以水平自动扩展容器并在需要时将服务器添加到节点池（当然，云提供商应该支持此功能才能实现）。例如，当服务器上的容器超过该服务器资源的 70% 时，就会添加一台新服务器，并且会根据每台服务器的运行时间自动向您收费。GCP 和 AWS 等大型云提供商都支持此功能。
所以，我在想，为什么不直接选择最便宜的服务器，让 Kubernetes 使用这些服务器进行扩展呢？据我所知，如果可以使用 5 美元的服务器，就没有必要在节点池中使用 100 美元的服务器。当然，100 美元可以处理更多负载，但如果您使用 5 美元的服务器，Kubernetes 会自动为您添加新服务器。
为什么甚至可以选择使用更昂贵的服务器来管理 Kubernetes？为什么不每个人都选择最便宜的服务器？
答案1
这个等式包含很多内容。
您到底能降到多低？一个关键因素是您的 pod 有多小。如果其中一个 pod 中的应用程序需要 4G RAM，那么将 1 个 8G 服务器拆分为 4x2G 服务器意味着该应用程序现在没有节点可运行。
增加开销。每个节点运行 Kubernetes 都会产生一些开销。每个节点上还会运行 DaemonSet，这会增加更多开销。如果将节点数量增加一倍，则 DaemonSet 的副本数量也会增加一倍，这会增加运行集群的成本。即使没有这些，也会有操作系统、Linux 发行版、kubelet 和其他 Kubernetes 组件的开销。节点越小，节点上工作负载的百分比越大，只是运行节点的开销，而不是运行应用程序的开销。
考虑管理开销。是的，基础设施即代码、自动扩展组等会有所帮助。但是，节点越多，出现问题时需要管理、监控和调试的事情就越多。
网络因素。节点越多，节点之间的网络流量就越大，这比通过 Linux 桥接的节点内的虚拟网络要慢。云提供商还倾向于在较小的节点上显著限制网络，从而导致超时和延迟，这可能会使应用程序无法使用。
根据我的经验，公司很快就会达到 10 个节点左右的 HA。您希望剩余节点有足够的容量来处理从故障节点故障转移的容器。对于 10 个节点，这意味着要留下 10% 多一点的额外容量来处理集群中一个故障节点。如果您只有 3 个节点，则每个节点的利用率需要低于 2/3 才能处理单个节点故障。在这些公司达到 20 个节点之前，他们开始扩展到更大的节点。这使得集群中的节点更新可以通过小型团队和最低限度的自动化进行管理。在某个时候，更大节点的成本超过了运行更多节点的更多管理开销的成本，他们又会转向扩展以获得更大的容量。
答案2
除了 Kubernetes，大型数据中心的主要问题是冷却、电力和空间。高端服务器通常需要较少的运营干预，结构紧凑且节能。但从长远来看，它们更具成本效益。
诀窍在于找到最佳的扩展单元。