Question

如果limit资源大于request资源，则K8会将pod分配给QoS Burstable

示例配置：

apiVersion: v1
kind: Pod
metadata:
  name: test-metadata
  namespace: demo
spec:
  containers:
  - name: test1
    image: nginx
    resources:
      limits:
        memory: "14Gi"
      requests:
        memory: "4Gi"

Kubernetes是否会始终在具有14GB内存的实例上分配此Pod？
Kubernetes是否会始终为该Pod保留14 GB的内存？如果是，那么它与QoS Guaranteed类有何不同？

我不想使用QoS Guaranteed，因为工作量可能会有所不同。

Answer 1

默认情况下，在尝试调度Pod时，Kubernetes仅考虑资源请求。这意味着您的Pod仅会安排到某个节点，该节点至少具有Pod要求的大量可用资源。

更精确地说，将把Pod调度到节点之一，以使所有Pod（包括它正尝试调度的Pod）所请求的资源总和不超过节点可分配的资源。这里的有效词是可分配的资源。

可分配资源是那些资源，这些资源超出了操作系统Pod所需的资源。为系统进程保留多少硬件资源是Kubernetes的可配置属性，在their documentation of node allocatable resources

中有更好的描述

Answer 2

安排Pod时不考虑内存限制。

Kubernetes会始终在具有14GB内存的实例上分配此Pod吗？

默认情况下，此Pod将分配给满足4GB内存要求的任何节点。

在节点方面，当节点资源用完时，任何使用超过其请求资源的pod都会被逐出。换句话说，Kubernetes从不提供Pod要求之外的任何资源可用性保证。

使用超出节点总内存的内存限制将永远不会达到。

Kubernetes会始终为该Pod保留14 GB的内存吗？如果是，那么它与QoS保证类有什么不同？

否，默认情况下，kubernetes将保留所需的最少内存量，即请求的4GB。

计划程序还考虑了scheduler configuration和scheduler policies：

调度程序配置允许通过编写配置文件并将其路径作为命令行参数传递来自定义kube-scheduler的行为。

可以使用调度策略来指定kube-scheduler运行到filter and score nodes的谓词和优先级。

Kubernetes中QoS Burstable Pod的资源分配

2 个答案: