为什么要在云平台上的节点内水平缩小/放大 pod？答案

【问题标题】：Why scale down/up pods horizontally within node on cloud platform?为什么要在云平台上的节点内水平缩小/放大 pod？
【发布时间】：2020-03-21 02:43:26
【问题描述】：

我是 K8s 的新手。我正在研究在 GKE/AKS 上使用 k8s 而非我们系统中使用的 Azure VM Scaleset 的好处。

对于 k8s，假设我们将 worker 应用程序部署到 5 个节点的集群中，每个节点可以运行 10 个 pod。每个节点是16核、64G内存的VM。

我的问题是，既然我们是按节点而不是按 pod 向云服务提供商付款，为什么我们要缩小节点上的 pod？

仅水平扩展和缩减节点是否更有意义，同时每个节点上的 pod 数量最多？

10 个 pod、20 个 pod、30 个 pod、40 个 pod、50 个 pod 是否更有意义，而 11 个 pod、21 个 pod、31 个 pod、41 个 pod 等听起来是在浪费我们支付的资源？

我一定错过了进行 pod 扩展的关键点。请指出他们。谢谢。

【问题讨论】：

标签： kubernetes google-kubernetes-engine azure-aks

【解决方案1】：

如果您的所有 pod 都是相同的，那么是的，仅以节点大小的等价物来扩展它们可能是有意义的（但在这种情况下，您可能希望真正确保节点可以以对您有意义的增量进行扩展工作负载大小——例如，您真的每次都需要另外 32 或 64 或 96 个内核的应用程序吗？这是新的 Google batch for Kubernetes 产品试图解决的问题之一——包括调整机器大小。

但是想想如果你有一组异构的工作负载（k8s 更有可能！）——那么 k8s 的一个优点是你可以将不同的工作负载打包到同一个节点上。

想象一下，如果一个工作负载需要大量 RAM，但 CPU 不多，而另一个工作负载需要大量 CPU 而不是很多 RAM - 您不希望它们都以一个节点为增量进行扩展，您希望 pod 能够根据每个应用程序的需求进行扩展，并且当您无法再将 binpack 打包到现有机器上时，节点可以扩展。

【讨论】：

感谢您在 GKE 上为我介绍批处理。
不客气。当然，AFAIT，它实际上是在最近几天推出的测试版，所以我不太了解它:)
对于多个应用程序以不同方式消耗资源的场景。如果为不同的应用程序使用多个集群，集群仅在节点上扩展，每个节点运行一个 pod。节点大小由满足应用程序要求的最小值确定。云平台上“不同工作负载到同一个节点”如何胜过这一策略？
你错过了 Kubernetes 非常强大的东西——不要考虑 1-2 个应用案例，想想成百上千个应用案例。你真的要维护成百上千个集群吗？所有这些应用程序是否都打包在确切的机器倍数中？他们会永远保持这种规模吗？即使是小规模，答案也可能是否定的。而且，即使您可以在 GCE 上使用自定义机器类型，但以这种方式增量扩展的每个内核的成本更高。
我从团队的角度思考问题。我们维护的服务少于 20 项。我们将一些服务推送到 Azure 云并运行大约 10 个 VM Scaleset，就像 10 个集群一样。 VM Scalesets 管理工作最少。我没有想过将所有服务都推送到云端以及如何管理它们。我必须在 gke/aks 上更多地使用 k8s，看看它如何帮助提高扩展性能和降低成本。我已经接受了这个答案。

【解决方案2】：

因为更容易考虑一次为单个部署扩展策略。
因为您可以将系统设置为将低利用率节点折叠在一起，然后删除未使用的节点。
因为它可以为您提供更好的统计数据来跟踪您的利用率。

【讨论】：