k8s|Kubernetes服务质量保证之配置容器资源limits和requests

资源需求(Requests)和限制( Limits)

- name: jobmanager image: ponylee/flink:1.15.0-java8 workingDir: /opt/flink ports: - containerPort: 6123 name: rpc - containerPort: 6124 name: blob - containerPort: 8081 name: ui resources: limits: cpu: "1" memory: "1Gi" requests: cpu: 250m memory: "100Mi"

requests: Initial resource request for CPU and memory 容器需要的最低资源量(CPU,MEM)
limits: Upper limit until we want our application to grow at max 容器运行中所能分配的最大资源量
  • 对于每一个资源,container可以指定具体的资源需求(requests)和限制(limits),requests申请范围是0到node节点的最大配置,而limits申请范围是requests到无限,
    即0 <= requests <=Node Allocatable, requests <= limits <= Infinity。
  • 对于CPU,如果pod中服务使用CPU超过设置的limits,pod不会被kill掉但会被限制。如果没有设置limits,pod可以使用全部空闲的cpu资源。
  • 【k8s|Kubernetes服务质量保证之配置容器资源limits和requests】对于内存,当一个pod使用内存超过了设置的limits,pod中container的进程会被kernel因OOM kill掉。当container因为OOM被kill掉时,系统倾向于在其原所在的机器上重启该container或本机或其他重新创建一个pod。
QoS分类 Kubelet提供QoS(Quality of Service)服务质量管理,支持系统级别的OOM控制。在Kubernetes中,pod的QoS级别包括:Guaranteed, Burstable与 Best-Effort。根据limits和request两个参数的配置,k8s在集群资源不足的时候有不同的处理策略 – Quality of Service (QoS)
  • Best-Effort 最大努力
requests和limits两个参数都没有设置。就是没有对资源做限制,只要节点有足够资源会尽可能满足其需求。但是这种容器优先级是最低的:节点CPU或MEM资源不够时,会优先把该类容器杀掉以回收资源。
  • Burstable 爆发的
requests和limits都有设置并且requests小于limits。即最低要求requests所指定的资源,最高以limits为上限。优先级较Best-Effort高一点: 节点资源不足时,如果没有Best-Effort类型的容器,会删除该类容器。
  • Guaranteed 有保障的
requests参数与limits参数相同。具有最高优先级,资源不足时会优先删除Best-Effort和Burstable类容器以确保其运行。
使用建议
  • 如果资源充足,可将QoS pods类型均设置为Guaranteed。用计算资源换业务性能和稳定性,减少排查问题时间和成本。
  • 如果想更好的提高资源利用率,业务服务可以设置为Guaranteed,而其他服务根据重要程度可分别设置为Burstable或Best-Effort,例如filebeat。
注意: 不支持swap,当前的QoS策略假设swap已被禁止。

    推荐阅读