k8s 限制方式limit和request
1.Request
容器请求资源，预留资源，应使用的基本资源（预留性质，不是实际占用），用于资源调度的参考值，只会分配到满足这个配置的节点上。分配太大会造成资源的浪费，当request没有节点能满足时，pod处于pending状态。
容器使用的最小资源需求,作为容器调度时资源分配的判断依赖。只有当节点可以分配资源量 >= 容器资源请求数是才允许将容器调度到该节点.单Request 参数不限制容器的最大可用使用的资源
1.request小于limits 20%-30%
2.request不能大于limits
3.节点上limit值不建议超过宿主机配置，建议小于宿主机的20%
2.Limit
容器可以使用资源的最大值,设置为0表示使用资源无上限。
Request 能够保证POD有足够的资源运行,而Limit 则是防止某个POD无限制地使用资源,导致宿主机雪崩，从而影响其他POD崩溃。两者之间必须满足关系:
0<=Request<=Limit<=Infinity (如果Limit为0表示不对资源进行限制，这时可以小于Request)
3.Request和Limit对比
对于每一个资源,container可以指定具体的资源需求(requests)和闲置(Limits),request 申请范围是0 到node节点的最大配置,而Limit 申请范围是requests到无限,即 0 <= Requests <= Node Allocatable，Request <= Limits <= Infinity。 对于CPU,如果POD中服务使用CPU 超过设置的Limits，pod 不会被Kill 掉,但是会被闲置。如果没有设置Limits，pod可以使用全部空闲的CPU 资源。 对于内存,当一个POD 使用内存超过了设置的Limits,POD 中container 的进程会被kernel 因OOM 而kill掉。当container 因为OOM被kill时，系统倾向于在其原所在的机器上重启该container或其他节点上重新重建一个POD
4.QoS分类
Kubelet提供QoS服务质量管理，支持系统级别的OOM控制。在Kubernetes中，pod的QoS级别包括：Guaranteed, Burstable与 Best-Effort
1.Guaranteed
pod中的所有容器都必须对cpu和memory同时设置limits，如果有一个容器要设置requests，那么所有容器都要设置，并设置参数同limits一致，那么这个pod的QoS就是Guaranteed级别。 注：如果一个容器只指明limit而未设定request，则request的值等于limit值。
Guaranteed：容器只指明了limits而未指明requests
Guaranteed：requests与limit均指定且值相等
2.Burstable
pod中只要有一个容器的requests和limits的设置不相同，该pod的QoS即为Burstable(即可能会停服)
Burstable bar没有指定resources
Burstable：pod中只要有一个容器没有对cpu或者memory中的request和limits都没有明确指定
Burstable：Container foo没有设置limits，而bar requests与 limits均未设置
3.Best-Effort
如果对于全部的resources来说requests与limits均未设置，该pod的QoS即为Best-Effort
5.可压缩资源与不可压缩资源
Kubernetes根据资源能否伸缩进行分类，划分为可压缩资源和不可以压缩资源2种。 CPU资源是目前支持的一种可压缩资源，而内存资源和磁盘资源为目前所支持的不可压缩资源。
6.QoS优先级
3种QoS优先级从有低到高（从左向右）：
Best-Effort pods -> Burstable pods -> Guaranteed pods
7.资源回收策略
可压缩资源：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。对于kubernetes保留资源，比如kubelet，docker，OOM_ADJ参数设置成了-999，表示不会被OOM kill掉。OOM_ADJ参数设置的越大，通过OOM_ADJ参数计算出来OOM分数越高，表明该pod优先级就越低，当出现资源竞争时会越早被kill掉，对于OOM_ADJ参数是-999的表示kubernetes永远不会因为OOM而被kill掉。
QoS pods被kill掉的场景与顺序
1.Best-Effort 类型的pods：系统用完了全部内存时，该类型pods会最先被kill掉。 2.Burstable类型pods：系统用完了全部内存，且没有Best-Effort container可以被kill时，该类型pods会被kill掉。 3.Guaranteed pods：系统用完了全部内存、且没有Burstable与Best-Effort container可以被kill，该类型的pods会被kill掉。 注：如果pod进程因使用超过预先设定的limites而非Node资源紧张情况，系统倾向于在其原所在的机器上重启该container或本机或其他重新创建一个pod, 即自动迁移服务。
8.使用建议
如果资源充足，可将QoS pods类型均设置为Guaranteed。用计算资源换业务性能和稳定性，减少排查问题时间和成本。 如果想更好的提高资源利用率，业务服务可以设置为Guaranteed，而其他服务根据重要程度可分别设置为Burstable或Best-Effort，例如filebeat。