Question

当您在同一节点上安排了各种易爆Pod时，就会发生我要尝试使用的用例。当节点的内核正在调度CPU并且CPU负担很重时，如何确保特定Pod中的工作负载优先于另一个Pod？在一个典型的Linux主机中，我对进程之间争用的想法立即变成了进程的“精妙”，但是我看不到任何等效的k8s机制来指定节点上Pod中进程之间的CPU调度优先级。

我已经读过k8s提供的newest capabilities，它（如果我正确解释了文档）只是提供了一种CPU固定到Pod的机制，这并没有真正地困扰我。如果优先级较高的Pod没有活动的工作负载，而仍然允许优先级较高的工作负载具有CPU调度优先级，我仍然希望通过“第二类”的Pod来最大化CPU利用率。

到目前为止，尚未找到满意的答案，我认为社区将选择一种体系结构解决方案，例如自动扩展或在节点之间隔离工作负载。我认为这些并不是真正解决问题的方法，但实际上只是向它抛出更多的CPU，这是我要避免的事情。当CPU空闲时，为什么还要增加更多节点？

Answer 1

首先让我解释一下在k8s中内存分配是如何发生的（内存有些不同）

您可以如下定义CPU要求。我们将CPU定义为千分之一。

resources:
  requests:
    cpu: 50m
  limits:
    cpu: 100m

在上面的示例中，我们要求最少5％和最多10％的CPU份额。

kubernetes使用请求来调度Pod。如果一个节点的可用CPU仅超过5％，则将在该节点上计划Pod。

限制将传递给docker（或任何其他运行时），然后docker在cgroup中配置cpu.shares。

因此，如果您请求5％的CPU且仅使用1％，则剩余的未锁定到此Pod，其他Pod可以使用此空闲CPU来确保所有Pod获得所需的CPU，从而确保节点的CPU利用率高。 / p>

如果限制为10％，然后尝试使用更多的限制，那么Linux将限制CPU的使用，但不会杀死pod。

因此，您可以为可爆吊舱设置更高的限制，除非所有吊舱cpu同时爆裂，否则您可以。如果它们同时爆裂，则可获得的CPU数量将相等。

您可以使用pod affinity-and-anti-affinity来安排其他节点上的所有易爆Pod。

Answer 2

CPU请求与cgroup CPU优先级相关。基本上，如果Pod A请求的CPU为100m，而Pod B的请求为200m，即使在饥饿的情况下，B的运行秒数也将是A的两倍。

Answer 3

如前所述，Pods中的资源管理用requests和limits声明。

在Kubernetes中，基于requests和limits配置有3种QoS类别：

保证（限制==请求）
可爆（限制>请求）
尽力而为（限制和请求未指定）

2）和3）都可能被认为是“突发的”，因为它可能消耗比请求更多的资源。

最适合您的情况的是将Burtstable类用于具有更高优先级的Pod和其他功能。

如何处理易爆的K8S Pod的CPU争用？

3 个答案: