K8S QoS

Kubernetes QoS 介绍

QoS 指 服务质量保证，k8s 提供了 requests 和 limits 两种类型对资源进行分配和使用限制。对于一个 pod 来说，服务质量体现在两个为 2 个具体的指标，
Cpu 与 Memory。实际过程中，当某个 Node 节点上内存资源紧张时，k8s 会根据预先设置的不同 QoS 类别进行相应处理。

Kubernetes Qos 分类

• Guarantee
  Pod 中所有容器都必须对 cpu 和 memory 同时设置 limits。如果任何一个容器设置了 requests ，则所以其他容器必须设置 requests 配置，同时需要设置与
  requests 相同值对 limits 配置。

  # 例 1：只设置 limits 则 request 值等于 limits
  resources:
    limits:
        cpu: "100m"
          memory: "32Mi"
  
  # 例 2：同时设置相等的 requests 与 limits
  resources:
      requests:
        cpu: "100m"
          memory: "32Mi"
    limits:
        cpu: "100m"
          memory: "32Mi"

• Burstable
  Pod 中有任何一个容器的 requests 与 limits 不相等。

  # 例 1：有任何一个容器没有指定 resoureces
  containers:
    name: c1
      resources:
          requests:
            cpu: "100m"
              memory: "32Mi"
        limits:
            cpu: "200m"
              memory: "128Mi"
  ---
  containers:
    name: c2
  
  # 例 2：有任何一个容器没有指定 cpu 或 memory 的 requests 或 limits 的值
  containers:
    name: c1
      resources:
        limits:
            cpu: "200m"
  ---
  containers:
    name: c2
      resources:
        limits:
              memory: "128Mi"
  
  # 例 3：有任何一个容器配置不匹配，c1 未设置 limits，c2 未设置 limits、requests
  containers:
    name: c1
      resources:
        requests:
            cpu: "200m"
              memory: "128Mi"
  ---
  containers:
    name: c2

• Best-Effort
  Pod 中所有容器都没设置 requests、limits，而使用默认值。

  containers:
    name: c1
  ---
  containers:
    name: c2
  ---
  containers:
    name: c3

QoS 分类

Kubernetes QoS 优先级

• qos 三种类型的优先级如下：

QoS 优先级

Kubernetes QoS 终止顺序

当 k8s 中的 Node 节点的资源耗尽时，会对某些 Pods 进行资源回收（杀死 Pods），回收顺序根据 Qos 类型决定。

• Best-Effort: 资源耗尽时，这个类型的 Pods 会优先被杀死。
• Burstable: 资源耗尽时，如果没有 Best-Effort 类型的 Pods 时，这个类型的 Pods 会被杀死。
• Guaranteed: 资源耗尽时，如果没有 Best-Effort 或 Burstable 类型的 Pods 时，这个类型的 Pods 会被杀死。

Kubernetes QoS 配置建议

• 资源充足时：建议使用 Guaranteed 类型的 QoS 配置。可以保证 Pods 中容器可以持续、稳定的获得需要的资源。
• 资源有限时：建议使用 Burstable 类型的 Qos 配置。可以有效的保证资源利用率。

假设场景：应对 JVM 预热问题

1. JVM 在预热开始时，需要更多的 CPU（3 个）来进行预热；
2. JVM 在预热结束后，需要少数的 CPU（1 个）来保证程序运行；
   可以使用如下配置，保证预热和运行阶段都有充足的资源保证 pod 运行：

resoures:
  requests:
    cpu: 1000m
    memory: 1000Mi
  limits:
    cpu: 3000m
    memory: 1000Mi
由于 Kubernetes 使用 request 中指定的值来调度 Pod，它会找到具有 1000m CPU 容量的节点来调度这个 Pod。但是由于 3000m 的 limits
要高得多，如果应用程序在任何时候都需要超过 1000m 的 CPU，并且该节点上有空闲的 CPU 容量，那么就不会在 CPU 上限制应用程序。
如果可用，它最多可以使用 3000m。

参考资料：
Kubernetes-Qos 之 Guaranteed, Burstable，Best-Effor
Java 服务启动慢，JVM 预热的问题，我在 k8s 上改进了

---