如何在Kubernetes中对大量非活动Pod有效地使用CPU？
我有很多服务。一天中，少数服务忙了大约十个小时，而其他大部分服务都处于空闲状态或使用少量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 |
回答
我把所有的服务放在一个有两个cpu的虚拟机里，按cpu的使用情况进行缩放，最忙的时候有两个虚拟机，但大多数时候只有一个。
首先，如果您有任何可用性要求，我建议您始终至少拥有两个节点。如果您只有一个节点并且发生了一次崩溃（例如硬件故障或内核崩溃），则需要几分钟时间才能检测到这一点，而在新节点启动之前需要几分钟时间。
inactive service requests cpu设置为100m，因为忙的时候小于100m就不好用了。
我觉得问题是这些服务虽然需要100m的cpu才能正常工作，但大多是闲置的。
CPU请求是有保证的预留资源量。在这里，您为几乎空闲的服务预留了太多资源。将 CPU 请求设置得更低，可能低至20m甚至更低5m？但是由于这些服务在繁忙时期会需要更多资源，所以设置一个更高的限制，以便容器可以“爆裂”，并为此使用Horizontal Pod Autoscaler。使用 Horizontal Pod Autoscaler 时，将创建更多副本，并且流量将在所有副本之间进行负载平衡。另请参阅管理容器资源。
这对于你的“繁忙的服务”也是如此，保留更少的 CPU 资源，更积极地使用 Horizontal Pod Autoscaling，以便在高负载时将流量分散到更多节点，但在流量低时可以缩减并节省成本。
我真的希望所有的服务都可以自动伸缩，我认为这是 kubernetes 的好处，它可以帮助我更灵活地分配 pod。我的想法错了吗？
是的，我同意你的看法。
我不应该为非活动服务设置请求 CPU 吗？
总是为request和limit设置一些值是一个很好的做法，至少对于生产环境是这样。如果没有资源请求，调度和自动缩放将无法正常工作。
如果我有更多的活跃服务，即使在非高峰时间，请求cpu也会超过2000m。有什么解决办法吗？
一般来说，尽量使用较低的资源请求，并更积极地使用 Horizontal Pod Autoscaling。这对于您的“繁忙服务”和“非活动服务”都是如此。
我发现 kubernetes 经常有两个以上的节点。
是的，这有两个方面。
如果您只使用两个节点，您的环境可能很小，Kubernetes 控制平面可能包含更多节点，并且是成本的主要部分。对于非常小的环境，Kubernetes 可能很昂贵，并且使用诸如Google Cloud Run 之类的无服务器替代方案会更具吸引力
其次，对于可用性。在突然崩溃（例如硬件故障或内核崩溃）的情况下，最好至少有两个节点，这样您的“服务”仍然可用，同时节点自动缩放器会扩展一个新节点。对于 a的副本数量也是如此Deployment，如果可用性很重要，请至少使用两个副本。例如，当您排空节点以进行维护或节点升级时，pod 将被逐出 - 但不会首先在不同的节点上创建。控制平面将检测到Deployment（技术上是 ReplicaSet）的副本数量少于所需数量并创建一个新的 pod。但是当在新节点上创建新的 Pod 时，容器镜像会在 Pod 运行之前先被拉取。为了避免这些事件中的停机时间，使用至少两个副本为您Deployment和机架拓扑传播限制，以确保这两个副本的不同节点上运行。
注意：当 Pod 通常需要较低的 CPU 但会定期扩展时，您可能会遇到与如何使用 K8S HPA 和自动缩放器相同的问题，这应该通过即将推出的 Kubernetes 功能来缓解：KEP - Trimaran ：Real Load Aware Scheduling
- If only every question and answer in SO were this good.