我是 K8s 新手。我正在研究在 GKE/AKS 上使用 k8s 相对于我们系统中使用的 Azure VM 规模集的优势。
对于 k8s，假设我们将工作应用程序部署到 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 扩展的关键点。 请指出。 谢谢。
最佳答案
如果您的所有 pod 都相同，那么是的，仅以节点大小的等价物来扩展它们可能是有意义的(但也许在这种情况下，您实际上希望确保节点可以以对您有意义的增量进行扩展)工作负载大小——例如，您的应用程序每次真的需要额外的 32 或 64 或 96 个核心吗？这是新的 Google batch for Kubernetes 产品试图解决的问题之一——包括调整机器规模)。
但是想想，如果您有一组异构的工作负载(k8s 的可能性更大!)——那么 k8s 的优点之一就是您可以将不同的工作负载打包到同一节点上。
想象一下，如果一个工作负载需要大量 RAM，但不需要太多 CPU，而另一个工作负载需要大量 CPU 而不是大量 RAM——您不希望它们都以一个节点增量进行扩展，您希望 pod 能够根据每个应用程序的需求进行扩展，并且当您无法再将 binpack 打包到现有计算机上时也能够扩展节点。
关于kubernetes - 为什么要在云平台的node内水平缩小/放大pod？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59038078/