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资源。

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