Kubernetes 中 QoS Burstable pod 的资源分配

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 是否总是将这个 pod 分配到一个具有 14GB 内存的实例上？
• Kubernetes 会一直为这个 pod 预留 14 GB 的内存吗？ 如果是，那么它与QoS Guaranteed类有何不同？

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

Answer 1

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

更准确地说，pod 将被调度到节点之一，这样所有 pod（包括它试图调度的 pod）请求的资源总和不会超过节点可分配的资源。 这里的操作词是可分配资源。

可分配资源是指那些超出操作系统 Pod 所需资源的可用资源。 为系统进程保留了多少硬件资源是 Kubernetes 的可配置属性，在他们的节点可分配资源文档中有更好的描述

Answer 2

调度 Pod 时不考虑内存限制。

Kubernetes 是否总是将这个 pod 分配到一个具有 14GB 内存的实例上？

默认情况下，这个 pod 将分配给任何满足 4GB 内存请求的节点。

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

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

Kubernetes 会一直为这个 pod 预留 14 GB 的内存吗？ 如果是，那么它与 QoS 保证类有何不同？

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

调度程序还考虑了调度程序配置和调度程序策略：

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

调度策略可用于指定kube-scheduler运行以分别过滤和评分节点的谓词和优先级。