第22章：Kubernetes Resource Requests & Limits

1. 资源要求

• Requests, 容器所需资源下限，最低要求，，虽然资源肯定会被分配走，但实际可能用不了这么多；

  spec.containers[].resources.requests.cpu

  spec.containers[].resources.requests.memory

• Limits, 容器所能使用的资源上限，最高要求，硬限制，不可能超过，否则就会OOM；

  spec.containers[].resources.limits.cpu

  spec.containers[].resources.limits.memory

  说明：在 Linux 系统上，容器运行时通常会配置内核 CGroups，负责应用并实施所定义的资源要求。

2. 资源单位

• CPU，1表示1个逻辑CPU，1CPU=1000 millicores，即100m=0.1CPU；

  注意：CPU最低不能低于1m;

• Memory, 定点数字E、P、T、G、M、k，或者2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki（Recommend）

参考链接：Resource Management for Pods and Containers

3. QoS class

QoS是相对Pod来说的，而Pod是由container组成的，因此根据Pod中container的Resource定义情况来自动确定QoS class，不需要人为定义；

• Guranteed, Pod中的所有container的requests和limits不能为空，且需要完全相等；——最高优先级，必须保障，如果资源不足，最后被驱逐；

• Burstable, Pod中只要有一个container定义了requests或者limits即可，不要求是否相等；——中等优先级，说明对资源有点需求；

• Besteffort, Pod中没有一个container定义了requests或者limits；——最低优先级，对资源没啥要求，尽力保证即可，如果资源节点不足，最先被驱逐；

参考链接：Pod Quality of Service Classes

4. 资源YAML示例

---
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

5. 资源度量

metrics-server 发现集群中的所有节点，并且查询每个节点的 kubelet 以获取 CPU 和内存使用情况。 kubelet 充当 Kubernetes 主节点与节点之间的桥梁，管理机器上运行的 Pod 和容器。

注意：原来的Heapster已在Kubernetes v1.11废弃，暂由metrics-server来替代，未来在更高的版本metrics-server可能也会废弃，如由OpenMetrics替代，但原理应该都差不多。

参考链接：

Tools for Monitoring Resources

metrics-server