QoS（Quality of Service） 简介
QoS（Quality of Service） 简介 QoS（Quality of Service），大部分译为 “服务质量等级”，又译作 “服务质量保证”，是作用在 Pod 上的一个配置，当 Kubernetes 创建一个 Pod 时，它就会给这个 Pod 分配一个 QoS 等级，可以是以下等级之一：
Guaranteed：Pod 里的每个容器都必须有内存/cpu 限制和请求，而且值必须相等。如果一个容器只指明limit而未设定request，则request的值等于limit值。
Burstable：Pod 里至少有一个容器有内存或者 cpu 请求且不满足 Guarantee 等级的要求，即内存/cpu 的值设置的不同。
BestEffort：容器必须没有任何内存或者 cpu 的限制或请求。
设置资源很烦，但是十分必要。如果不设，Pod虽然很容易被调度，可以使用整个node资源，但是当资源紧俏时，会被第一个kill。
该配置不是通过一个配置项来配置的，而是通过配置 cpu/MEM的 limits 与 requests 值的大小来确认服务质量等级。
可压缩资源：cpu 在压缩资源部分已经提到cpu属于可压缩资源，当pod使用超过设置的limits值，pod中进程使用cpu会被限制，但不会被kill。
不可压缩资源：内存 Kubernetes通过cgroup给pod设置QoS级别，当资源不足时先kill优先级低的pod，在实际使用过程中，通过OOM分数值来实现，OOM分数值从0-1000。
OOM分数值根据OOM_ADJ参数计算得出，对于Guaranteed级别的pod，OOM_ADJ参数设置成了-998，对于BestEffort级别的pod，OOM_ADJ参数设置成了1000，对于Burstable级别的POD，OOM_ADJ参数取值从2到999。对于kuberntes保留资源，比如kubelet，docker，OOM_ADJ参数设置成了-999，表示不会被OOM kill掉。OOM_ADJ参数设置的越大，通过OOM_ADJ参数计算出来OOM分数越高，表明该pod优先级就越低，当出现资源竞争时会越早被kill掉，对于OOM_ADJ参数是-999的表示kubernetes永远不会因为OOM而被kill掉。
资源限制 Limits 和 资源需求 Requests
对于cpu：如果pod中服务使用cpu超过设置的 limits，pod不会被kill掉但会被限制。如果没有设置limits，pod可以使用全部空闲的cpu资源。
对于内存：当一个pod使用内存超过了设置的 limits，pod中 container 的进程会被 kernel 因OOM kill掉。当container因为OOM被kill掉时，系统倾向于在其原所在的机器上重启该container或其他重新创建一个pod。
QoS 优先级
三种 QoS 优先级，从高到低（从左往右）
Guaranteed --> Burstable --> BestEffort
Kubernetes 资源回收策略
Kubernetes 资源回收策略：当集群监控到 node 节点内存或者cpu资源耗尽时，为了保护node正常工作，就会启动资源回收策略，通过驱逐节点上Pod来减少资源占用。
三种 QoS 策略被驱逐优先级，从高到低（从左往右）
BestEffort --> Burstable --> Guaranteed
使用建议 如果资源充足，可以将 pod QoS 设置为 Guaranteed 不是很关键的服务 pod QoS 设置为 Burstable 或者 BestEffort。
K8S通过Request和Limit两个抽象概念来给Pod申请资源与配额：
（1）Request是资源预估申请，由K8s调度决策是否能够满足申请，如有资源则保证供给，如果资源资源不足则显示等待状态。
（2）Limit是容器资源限额： 内存超额 > OOMKill相关的容器 cpu超额 > 限制使用量(throttling)
（3）Request <= Limit
（4）管理员还可配置名字空间级别的配额(ResourceQuota/LimitRange)
TRANSLATE with版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
