你敢相信，部署的两个服务在做压力测试的时候，把k8s集群给‘打’挂掉了
在制作这两个pod的时候，是没有做任何资源限制的，也就是服务需要多少个cpu，需要多少内存，直接向宿主机申请，没有任何限制，直至将宿主机的资源全部耗尽。。。
配置容器资源限制
对于一个pod来说，资源最基础的2个的指标就是：CPU和内存。
- 当pod 内存超过limit时，会被oom。
- 当cpu超过limit时，不会被kill，但是会限制不超过limit值。
例如：
# cpu可不做限制
# 内存最大限制2G, 最小1G
# 对于一些java项目, 必须设置java虚拟机的参数, 而且这个参数不能大于容器设置的限定值, 否则容器会因为内存过大不停的重启
resources:
limits:
memory: "2048Mi"
requests:
memory: "1024Mi"requestslimits
容器服务质量（QoS-Quality of Service）
Kubernetes 提供服务质量管理，根据容器的资源配置，将pod 分为Guaranteed, Burstable, BestEffort 3个级别。当资源紧张时根据分级决定调度和驱逐策略，这三个分级分别代表：
- Guaranteed：pod中所有容器都设置了limit和request， 并且相等（设置limit后假如没有设置request会自动设置为limit值）
- Burstable：pod中有容器未设置limit， 或者limit和request不相等。这种类型的pod在调度节点时， 可能出现节点超频的情况。
- BestEffort：pod中没有任何容器设置request和limit。
QoS使用建议
如果资源充足，可将 QoS pods 类型均设置为Guaranteed。用计算资源换业务性能和稳定性，减少排查问题时间和成本。如果想更好的提高资源利用率，业务服务可以设置为Guaranteed，而其他服务根据重要程度可分别设置为Burstable或Best-Effort。
pod 驱逐：
当节点的内存和cpu资源不足，开始驱逐节点上的pod时。QoS同样会影响驱逐的优先级。顺序如下：
- kubelet 优先驱逐 BestEffort的pod 和 实际占用资源大于requests的Burstable pod。
- 接下来驱逐实际占用资源小于request的Burstable pod。
- QoS为Guaranteed的pod最后驱逐， kubelet 会保证Guaranteed的pod 不会因为其他pod的资源消耗而被驱逐。
- 当QoS相同时，kubelet 根据 Priority 计算驱逐的优先级
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
