kubernetes - 如何在 Kubernetes 中对大量非事件 Pod 有效地使用 CPU？

Question

我有很多服务。一天中，少数服务忙了大约十个小时，而其他大部分服务都处于空闲状态或使用少量cpu。
以前我把所有的服务都放在一个有两个cpu的虚拟机里，按cpu的使用情况进行缩放，最忙的时候有两个虚拟机，但大多数时候只有一个。


服务
实例
一天中的忙碌时间
忙碌时的CPU(核心/服务)
空闲时的CPU(核心/服务)


繁忙的服务
2
8~12小时
0.5~1
0.1~0.5

繁忙的服务
2
8~12小时
0.3~0.8
0.1~0.3

非事件服务
30
0~1小时
0.1~0.3
< 0.1


现在我想把它们放到kubernetes中，每个节点有两个CPU，并使用节点自动伸缩和HPA，为了使节点自动伸缩，我必须为所有服务设置请求CPU，这正是我遇到的困难。
这是我的设置。


服务
实例
忙碌的时间
请求 CPU(CPU/服务)
总请求 cpu


繁忙的服务
2
8~12小时
300米
600米

繁忙的服务
2
8~12小时
300米
600米

非事件服务
30
0~1小时
100米
3000米


注意:inactive service requests CPU设置为100m，因为忙的时候小于100m就不好用了。
有了这个设置，节点的数量总是会大于三个，成本太高了。我认为问题在于，虽然这些服务需要100m的CPU才能正常工作，但它们大多处于空闲状态。
我真的希望所有的服务都可以自动伸缩，我认为这是 kubernetes 的好处，它可以帮助我更灵活地分配 pod。我的想法错了吗？我不应该为非事件服务设置请求 CPU 吗？
即使我忽略不事件的服务。我发现 kubernetes 经常有两个以上的节点。如果我有更多的活跃服务，即使在非高峰时段，请求 CPU 也会超过 2000m。有什么解决办法吗？

Answer 1

I put all services in a virtual machine with two cpus, and scale by cpu usage, there are two virtual machine at the busiest time, but most of the time there is only one.

首先，如果您有任何可用性要求，我建议您始终至少拥有 两个节点。如果您只有一个节点并且发生了一次崩溃(例如硬件故障或内核崩溃)，则需要几分钟才能检测到这一点，而在新节点启动之前需要几分钟。

The inactive service requests cpu is set to 100m because it will not work well if it is less than 100m when it is busy.

I think the problem is that although these services require 100m of cpu to work properly, they are mostly idle.

CPU 请求是有保证的预留资源量。在这里，您为几乎空闲的服务预留了太多资源。将 CPU 请求设置得更低，可能低至 20m甚至 5m ?但是由于这些服务在繁忙时期会需要更多的资源，所以设置一个更高的限制，以便容器可以“爆裂”并使用 Horizontal Pod Autoscaler对于这些。使用 Horizo​​ntal Pod Autoscaler 时，将创建更多副本，并且流量将在所有副本之间进行负载平衡。另见 Managing Resources for Containers .
这对于你的“繁忙的服务”也是如此，保留更少的 CPU 资源，更积极地使用 Horizo​​ntal Pod Autoscaling，以便在高负载时将流量分散到更多节点，但在流量低时可以缩减并节省成本。

I really hope that all services can autoscaling, I think this is the benefit of kubernetes, which can help me assign pods more flexibly. Is my idea wrong?

是的，我同意你的看法。

Shouldn't I set a request cpu for an inactive service?

始终为请求和限制设置一些值是一种很好的做法，至少对于生产环境是这样。如果没有资源请求，调度和自动缩放将无法正常工作。

If I have more active services, even in off-peak hours, the requests cpu will exceed 2000m. Is there any solution?

一般来说，尽量使用较低的资源请求，并更积极地使用 Horizo​​ntal Pod Autoscaling。这对于您的“繁忙服务”和“非事件服务”都是如此。

I find that kubernetes more often has more than two nodes.

是的，这有两个方面。
如果您只使用两个节点，您的环境可能很小，Kubernetes 控制平面可能包含更多节点，并且是成本的主要部分。对于非常小的环境，Kubernetes 可能很昂贵，而且使用它会更有吸引力，例如无服务器替代方案，如 Google Cloud Run
其次，对于可用性。在突然崩溃的情况下，至少有两个节点是很好的，例如硬件故障或内核崩溃，以便您的“服务”仍然可用，同时节点自动缩放器扩展新节点。对于 Deployment 的副本数也是如此。 ，如果可用性很重要，请至少使用两个副本。当你例如 drain a node对于维护或节点升级，pod 将被驱逐 - 但不会首先在不同的节点上创建。控制平面将检测到 Deployment (技术上是 ReplicaSet)的副本数量少于所需数量并创建一个新的 pod。但是当在新节点上创建新的 Pod 时，容器镜像会在 Pod 运行之前先被拉取。为避免在这些事件期间停机，请至少为您的 Deployment 使用两个副本。和 Pod Topology Spread Constraints确保这两个副本在不同的节点上运行。

注意:您可能会遇到与 How to use K8S HPA and autoscaler when Pods normally need low CPU but periodically scale 相同的问题这应该通过即将推出的 Kubernetes 功能来缓解: KEP - Trimaran: Real Load Aware Scheduling