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

发布时间:2023-03-04 08:00

资源需求(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资源。

  • 对于内存,当一个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已被禁止。

ItVuer - 免责声明 - 关于我们 - 联系我们

本网站信息来源于互联网,如有侵权请联系:561261067@qq.com

桂ICP备16001015号