为什么需要对Pod进行资源控制？

假如我们不为Pod设置资源控制，那么

• 每个节点都会尽可能容纳更多的Pod。
• 当服务压力升高时，每个Pod都会尽可能侵占空闲资源，直到节点CPU全负荷运作，内存耗尽。
• 系统业务延迟明显增加，服务大规模重启。
• 各个节点资源占用比例严重失衡，甚至集群远程服务挂起，只能重启。

我们能控制哪些资源的分配？

CPU

CPU属于弹性资源，因为CPU可以通过时间片轮转等算法实现多进程调度。

因此CPU资源是按比例的形式为Pod进行分配，k8s将CPU资源定义为1000个单位，设置cpu.requests = 0.5 和cpu.requests = 500m是等价的，它代表该Pod所请求的资源是CPU资源的一半。

但请记住，CPU资源是按每个Pod设置值的比例进行分配的，权重大的Pod会获得比权重小的Pod更多的 CPU 时间。CPU调度的公平性由操作系统内核算法来保证。

CPU资源限制并不是绝对的，Pod可能会使用超出限制的CPU资源而不会被杀死。但节点CPU满负荷运转的最终结果是系统无法承载外部更多的请求，应用延时增加，响应变慢，同时节点会禁止新的Pod创建。

Memory

内存属于不可压缩资源，因为内存资源是进程独占的，这意味k8s对内存使用限制更加严格。

一旦节点可用内存耗尽，或者Pod使用资源超过limits，Pod一定会被杀死并重启。

内存分配的最小单位是字节，1m = 0.001字节。

正常情况下我们会使用 M(Mi), G(Gi) 作为分配单位。 1M = 2^20字节。

怎样控制Container资源分配？

下面是官网上的一个例子：

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"

requests

requests 代表Container向节点申请的资源，节点必须确保有充足的空间满足Pod的requests，否则k8s会将Pod分配到其它节点，如果Pod的资源申请无法被满足，则将会一直陷入失败重启状态。

limits

limits代表Container最高资源使用限制。

当CPU资源使用超过限制时，Pod将被限制使用CPU。对于没有设置limits的 pod ，一旦节点的空闲 CPU 资源耗尽，之前分配的 CPU 资源也会逐渐减少。

而当内存资源使用超过限制时，Pod将被强制重启。