cpu/mem 的limit和request都是针对container来讲的，不是针对pod。 0 <= request <= limit

cpu
cpu资源限制的单位m：
    CPU的计量单位叫毫核(m)。一个节点的CPU核心数量乘以1000，得到的就是节点总的CPU总数量。
    如，一个节点有两个核，那么该节点的CPU总量为2000m。

1核，即1000m，假定节点为1核
limits:
    cpu: 100m #等同于0.1
    memory: 1Gi
100/1000，即0.1，换算为百分比 100/1000*100=10% 节点cpu利用率

假定节点为1核，
requests: 
    cpu: "1"
0.5，即50%，1，即100%，2即200%

内存
内存单位：

K、M、G、T、P、E #通常是以1000为换算标准的。
Ki、Mi、Gi、Ti、Pi、Ei #通常是以1024为换算标准的。

三、QOS

request: Initial resource request for CPU and memory 容器需要的最低资源量(CPU,MEM)
limits: Upper limit until we want our application to grow at max 容器运行中所能分配的最大资源量

根据这两个参数的配置，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类容器以确保其运行。

3种QoS优先级从有低到高（从左向右）：
Best-Effort pods -> Burstable pods -> Guaranteed pods