☰

具有嘈杂邻居的保证 QOS Pod 的 Pod CPU 行为

tag-icon • tag-icon kubernetes
具有嘈杂邻居的保证 QOS Pod 的 Pod CPU 行为

努力去理解GuaranteedQos 类（通过相同的限制和请求）对 CPU 的行为，是否能真正保证我的 pod 在需要时能够获得所请求的 CPU，即使一个有BurstableQos 的吵闹邻居使用的 CPU 比Guaranteed和Burstablepod 可用的 CPU 还多。

考虑以下（简化的）场景：

节点有 2 个 CPU 和 2 个调度 pod：

  • 1 个具有Burstable请求的 pod 1 个 CPU 限制 2 个 CPU

  • 1 个 Pod，Guaranteed请求数为 1 CPU 限制为 1 CPU

现在考虑一下Guaranteedpod 当前正在使用 0.6 CPU（由容器内的语言运行时使用），而burstablepod 突发使用 1.4 CPU。

当保证的 pod 需要更多 CPU 时会发生什么？它会获得额外的 CPU 而另一个burstable受到限制吗？

  1. 或者说它会受到限制吗？
  2. 不允许升级到 1.4 版，因为即使没有实际使用，“请求的” CPU 也被保留了？
  3. podGuaranteed现在得不到它所需要的 CPU 吗？

答案1

Kubernetes 中有 3 个类：

  • 保证 - 如果你设置 仅有的 限制 或者 如果您将限制和请求设置为相同的值。（最高优先级）。
  • 可爆破 - 如果你设置 仅有的 要求 或者 如果您设置的请求低于限制。（中优先级）。
  • 最大努力 - 如果您根本没有设置这些。（优先级较低）。

对于 CPU，其多余的功率将按分配给节点上运行的容器的 request.cpu 值的比例分配。如果两个进程争夺 CPU，请求更高的进程将获得更多。然而，如果两个进程争夺 CPU，那么来自 Guaranteed 类的进程将获得更多。另一个只会得到剩下的部分（事实上，内核不会让他饿死，但是速度会慢得多）。

您还可以找到有关 QoS 类别及其行为的更多信息这里和这里。最后一个网站非常好。Guy 很好地解释了当资源使用过多时会发生什么。这分为内存和 CPU。

相关内容