9

我有很多服务。一天中，少数服务忙了十个小时左右，而其他大部分服务都处于空闲状态或使用少量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，为了使节点自动伸缩，我必须为所有服务设置requests CPU，这正是我遇到的困难。

这是我的设置。

服务 实例 忙碌的时间 请求 cpu
(cpu/服务)		 总请求 CPU
繁忙的服务 2 8~12小时 300m 600m
繁忙的服务 2 8~12小时 300m 600m
非活动服务 30 0~1小时 100m 3000米

注意：不活动的服务请求CPU设置为100m，因为忙的时候小于100m就不好用了。

使用此设置，节点的数量将始终大于三个，这太昂贵了。我认为问题在于，虽然这些服务需要 100m 的 CPU 才能正常工作，但它们大多处于空闲状态。

我真的希望所有的服务都可以自动伸缩，我认为这是 Kubernetes 的好处，它可以帮助我更灵活地分配 Pod。我的想法错了吗？我不应该为非活动服务设置请求 CPU 吗？

即使我忽略不活动的服务。我发现 kubernetes 更多时候有两个以上的节点。如果我有更多的活动服务，即使在非高峰时间，请求 CPU 也会超过 2000m。有什么解决办法吗？

4

1 回答 1

7

我把所有的服务都放在了一个有两个cpu的虚拟机中，并根据cpu的使用情况进行缩放，最忙的时候有两个虚拟机，但大多数时候只有一个。

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

不活动的服务请求cpu设置为100m是因为忙的时候小于100m就不好用了。

我认为问题在于，虽然这些服务需要 100m 的 cpu 才能正常工作，但它们大多处于空闲状态。

CPU请求是保证的预留资源量。在这里，您为几乎闲置的服务预留了太多资源。将 CPU 请求设置得更低，可能低至20m甚至5m? 但由于这些服务在繁忙时期需要更多资源，因此设置更高的限制，以便容器可以“爆发”并为此使用Horizo​​ntal Pod Autoscaler。使用 Horizo​​ntal Pod Autoscaler 时，将创建更多副本，并且流量将在所有副本之间进行负载平衡。另请参阅管理容器资源。

对于你的“繁忙的服务”也是如此，预留更少的 CPU 资源并更积极地使用 Horizo​​ntal Pod Autoscaling 以便在高负载时将流量分散到更多节点，但在流量低时可以缩减并节省成本。

我真的希望所有的服务都可以自动伸缩，我认为这是 Kubernetes 的好处，它可以帮助我更灵活地分配 Pod。我的想法错了吗？

是的，我同意你的看法。

我不应该为非活动服务设置请求 cpu 吗？

至少对于生产环境，始终为request和limit设置一些值是一个好习惯。如果没有资源请求，调度和自动缩放将无法正常工作。

如果我有更多的活跃服务，即使在非高峰时段，请求 cpu 也会超过 2000m。有什么解决办法吗？

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

我发现 kubernetes 更多时候有两个以上的节点。

是的，这有两个方面。

如果您只使用两个节点，您的环境可能很小，并且 Kubernetes 控制平面可能包含更多节点并且是大部分成本。对于非常小的环境，Kubernetes 可能很昂贵，使用诸如Google Cloud Run之类的无服务器替代方案会更具吸引力

第二，可用性。最好有至少两个节点以防突然崩溃（例如硬件故障或内核崩溃），这样您的“服务”仍然可用，同时节点自动缩放器扩展新节点。对于 a的副本数量也是如此Deployment，如果可用性很重要，请至少使用两个副本。例如，当您为维护或节点升级而耗尽节点时，Pod 将被驱逐 - 但不会首先在不同的节点上创建。控制平面将检测到Deployment（技术上 ReplicaSet）的副本数量少于所需数量并创建一个新 pod。但是当在新节点上创建新的 Pod 时，会在 Pod 运行之前先拉取容器镜像。Deployment为避免在这些事件期间发生停机，请为您的和Pod 拓扑传播约束使用至少两个副本，以确保这两个副本在不同的节点上运行。

注意：当 Pod 通常需要低 CPU 但会定期扩展时，您可能会遇到与如何使用 K8S HPA 和自动缩放器相同的问题，这应该通过即将推出的 Kubernetes 功能来缓解：KEP - Trimaran: Real Load Aware Scheduling

于 2021-03-30T17:45:50.720 回答