聊聊 K8S pod 的 QoS（Quality Of Service)

聊聊 K8S pod 的 QoS（Quality Of Service)

1 K8S QoS概述

• 现实世界中人跟人的地位不一样，k8世界中pod跟pod的地位也不一样,这就是 k8s 的 QoS（Quality Of Service),即服务等级质量，可以认为其是K8S的一种 SLA；
• 当系统资源充足的时候，所有 pod 都很happy，我们可以不用关注其QoS；
• 而一旦系统资源紧张的时候，等级低的 pod 就有可能被 evicted 驱逐，其底层容器中的进程也有可能被操作系统的kernel内核杀死，所以我们需要了解 k8s pod 的 QoS 的原理和机制，以根据Pod重要性的不同，合理配置其 QoS,从而确保SLA；

2 从一个 pod 被驱逐问题聊起

2.1 某 k8s pod被驱逐问题-问题现象

某微服务采用 docker 容器化模式部署在 k8s 集群中，在公司内部开发测试时一切良好，但是在某客户现场部署时，某特定 pod 频繁被驱逐（evicted)。

2.2 某 k8s pod被驱逐问题-问题原因

通过命令 “kubectl describe pod xxx” 查看详细可见，该 pod 使用的内存资源为 1273MB，超过了申请的内存资源 500MB，且此时此时pod所在的 k8s 节点内存资源紧张，所以该超额使用了内存资源的 pod 被 evicted 驱逐了,如下图所示：

2.3 某 k8s pod被驱逐问题-问题解决

• 为缓解问题，可以扩展 K8S 集群，使其可以供应更多的资源，此时特定Pod被调度到的节点，就不容易出现资源紧张的现象，该Pod也就不容易被驱逐了：比如可以横向扩展添加更多的 worker节点，也可以纵向扩展调高每台 worker 节点的内存和CPU资源（如果k8s是部署在vmware等虚拟平台上，一般是可以在线纵向扩展节点的内存磁盘和CPU资源的）；
• 为彻底确保特定 pod不被驱逐，应该配置该 pod 的 Quality of Service (QoS) classes 为 Guaranteed，此时即使该pod被调度到的节点出现了资源紧张的现象，k8s也只会 evicted 驱逐其它 QoS 为 Burstable/Best-Effort 的 pods；
• 我们没有办法直接指定 Pod 的 QoS,但可以将 memory request 和 memory limit配置为相同值，此时其 QoS就是Guaranteed了；
• 可以通过命令 kubectl get pod xx/kubectl describe pod xx，查看命令输出中的 qosClass 确认其Qos，如上图可见，当前被驱逐的 pod， 其 qosClass 是 Burstable 而不是 Guaranteed；

3 k8s 的 QoS 相关知识

3.1 QoS 综述

• K8S 为不同 pod 提供了不同的 QoS 服务质量级别，其底层是基于 pod 对资源的申请量和限制量决定的（"Requests and Limits” and “QoS Classes” are tightly coupled）；
• 需要长时间以稳定状态运行的Pods，可以配置为 Guaranteed 级别以确保其资源供应，而其它 pod 则可以配置为 Burstable 甚至 Best-Effort级别；
• 在为 pod 底层的 container 指定资源时，可以指定其资源需求即 request, request 代表了 k8s 可以确保提供给容器的资源数；
• 在为 pod 底层的 container 指定资源时，还可以指定其资源上限即 limit, limit代表了k8s允许特定容器可以使用的资源的上限（如果容器使用的资源超过了其limit上限，其底层进程就可能会被 kernel杀死）；
• 当没有指定容器的 request时，其默认值是 limit；
• 当没有指定容器的 limit 时，其默认值是0，即没有限制；
• k8s 对 pod 的调度是基于 requests 而不是 limits；
• A request is the amount of that resources that the system will guarantee for the container, and Kubernetes will use this value to decide on which node to place the pod;
• A limit is the maximum amount of resources that Kubernetes will allow the container to use;
• In the case that request is not set for a container, it defaults to limit. If limit is not set, then if defaults to 0 (unbounded). Setting request < limits allows some over-subscription of resources as long as there is spare capacity.This is part of the intelligence built into the Kubernetes scheduler.

3.2 为 pods 指定资源-cpu&memory

• CPU 资源是以 (v)Core 来计量的,可以通过十进制小数进行指定，比如 0.5 代表半个 vcore；也可以通过 milicpu 进行指定，比如 500m 也代表半个 vcore；
• 内存资源是以 BYTE 字节数计量的，可以指定单位比如 KB/MB/GB等。You specify them as decimals with one of SI suffixes (E, P, T, G, M, K) or their power-of-two equivalents (Ei, Pi, Ti, Gi, Mi, Ki). For example, the following represent roughly the same value: 128974848, 129e6, 129M, 123Mi.

3.3 k8s 对可压缩与不可压缩资源的request和limit的不同处理

k8s 对不同资源的 request 和 limit 的处理，取决于该资源的可压缩性（compressible or incompressible）；

3.3.1 k8s 对可压缩资源的request和limit的处理

• k8s支持的可压缩性资源（或者称为弹性资源），目前只有CPU;
• 对于可压缩性资源，Pods 如果使用的资源超过了其 limit，则会被 throttled 节流；如果pod中没有指定limit, 则 pods 可以使用所有可用的 CPU资源；
• Compressible Resource Guarantees:Pods will be throttled if they exceed their limit. If limit is unspecified, then the pods can use excess CPU when available；

3.3.2 k8s 对不可压缩资源的request和limit的处理

• k8s支持的非可压缩性资源，目前只有内存；
• 对于不可压缩性资源,可以确保 pod 可用获得其 request 的资源量；如果 pod使用的资源量超过了其 request， 则当其它 pod 需要资源时，该 pod 可能会被杀死；但是如果 pod使用的资源量小于其 request, 则他们不会被杀死；
• 当 Pods 使用的资源量超过其 limit, 则该pod的某个容器中，使用最多内存的某个进程，会被 kernel 杀死；
• Incompressible Resource Guarantees:Pods will get the amount of memory they request, if they exceed their memory request, they could be killed (if some other pod needs memory), but if pods consume less memory than requested, they will not be killed.
• Incompressible Resource Guarantees: When Pods use more memory than their limit, a process that is using the most amount of memory, inside one of the pod's containers, will be killed by the kernel；

3.4 k8s POD 的 QoS

• 如果 k8s 某节点的 CPU 或 memory 资源紧张,即该节点所有 pods 的 limits 之和大于该节点的资源供应量,理想情况下，k8s应该杀死重要程度不高，即 QoS 等级不高的容器；
• K8s 按重要等级不同，从高到低，将 pod 分为三种 Quality of Service (QoS)，即：Guaranteed, Burstable, 和 Best-Effort；
• 可以通过命令“kubectl describe nodes xxx | grep Allocatable -A 5"查看k8s某节点的资源供应量:

3.4.1 Guaranteed QoS

• 当 pod 中所有容器都声明了request和limits，且两者相等且不是0时， 则该 pod 的 QoS等级是 Guarantee（没有声明request时，其默认值等于limit）；
• 该 QoS 的 Pods， 其等级最高，在其资源使用量不超过其 limit的情况下，可以确保不被杀死；
• If limits and optionally requests (not equal to 0) are set for all resources across all containers and they are equal, then the pod is classified as Guaranteed；
• Pods are considered top-priority and are guaranteed to not be killed until they exceed their limits；

3.4.2 Burstable QoS

• 如果 pod 中一个或多个容器声明了 request且不为0，且 request 和 limit 的值并不相等，则该 pod 的级别为 Burstable；(当没有指定 limits 时，其默认值是没有限制)；
• 该 QoS 的 Pods，k8s 可以确保为其分配其 request 指定的最小资源量，且当 k8s 节点有空闲的可用资源时，这些 pods 可以使用这些资源；
• 在系统内存资源紧张，且集群中没有 QoS 为 Best-Effort 级别的其它 pods 时，一旦 Burstable (QoS) 的 pod 使用的资源量.超过了其 request， 这些 pod 就容易被杀死；
• If requests and optionally limits are set (not equal to 0) for one or more resources across one or more containers, and they are not equal, then the pod is classified as Burstable. When limits are not specified, they default to the node capacity；
• Pods have some form of minimal resource guarantee, but can use more resources when available. Under system memory pressure, these containers are more likely to be killed once they exceed their requests and no Best-Effort pods exist；

3.4.3 Best-Effort (QoS)

• 如果 Pod 底层所有的 container容器，都没有指定 request 和 limit, 则这些pod的 QoS 等级是 Best-Effort；
• 该 QoS 的 Pods，其等级最低，当系统内存资源紧张时，这些 pod 底层容器中的进程是最先会被杀死的；
• 不过该 QoS 等级的Pod底层的容器，可以使用k8s节点所有可用的空闲内存资源；
• If requests and limits are not set for all of the resources, across all containers, then the pod is classified as Best-Effort；
• Pods will be treated as lowest priority. Processes in these pods are the first to get killed if the system runs out of memory. These containers can use any amount of free memory in the node though；