k8s_资源限制_requests_limits-QoS-POD服务质量QoS

# 使用帮助
kubectl explain pod.spec.containers.resources.limits
kubectl explain pod.spec.containers.resources.requests
# 例子

    resources: 
      requests: 
        cpu:  "500m" #  "1"
        memory:  "512Mi"
      limits: 
        cpu:  "250m"
        memory:  "128Mi" # 1Gi 

QoS 类 

[root@m1 metrics]# kubectl describe pod pod-demo-resources|grep QoS
QoS Class: Guaranteed

Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类：
 

• Guaranteed  (该- run - ti\ de-)             优先级最高       保证的
• Burstable (be- si- te- bao \)                                      
• BestEffort   ( (Best 败\ 死 特 额 fe te)     优先级最低       尽力而为，尽最大努力；尽力服务

QoS 类为 Guaranteed 的 pod  需要满足如下条件

• Pod 中的每个容器都必须指定 CPU/内存 限制和 CPU/内存 请求。
• 对于 Pod 中的每个容器，CPU/内存 限制必须 等于  CPU/内存 请求。

• Pod 不符合 Guaranteed QoS 类的标准。
• Pod 中至少一个容器具有内存或 CPU 请求。

• Pod 中的容器必须 没有设置内存和 CPU 限制或请求

创建包含两个容器的 Pod
一个容器指定了内存请求 200 MiB。 另外一个容器没有指定任何请求和限制。
Pod QoS 类为 Burstabl

如何处理相同QoS等级的容器

每个运行中的进程都有一个称为OutOfMemory（OOM）分数的值。系统通过比较所有运行进程的OOM分数来选择要杀掉的进程。当需要释放内存时，分数最高的进程将被杀死。

OOM分数由两个参数计算得出：进程已消耗内存占可用内存的百分比，与一个基于pod QoS等级和容器内存申请量固定的OOM分数调节因子。
对于两个属于Burstable等级的单容器的pod，系统会杀掉内存实际使用量占内存申请量比例更高的pod。
这就是图  中使用了内存申请量 90% 的pod B在pod C（只使用了70%）之前被杀掉的原因，尽管pod C比pod B使用了更多兆字节的内存。

这说明我们不仅要注意requets和limits之间的关系，还要留心requests和预期实际消耗内存之间的关系。