一、Pod 容器的资源限制
当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。 最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源。
当为 Pod 中的容器指定了 request 资源时，代表容器运行所需的最小资源量，调度器就使用该信息来决定将 Pod 调度到哪个节点上。当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量， 供该容器使用。
如果 Pod 运行所在的节点具有足够的可用资源，容器可以使用超出所设置的 request 资源量。不过，容器不可以使用超出所设置的 limit 资源量。
如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。 类似的，如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配。
官网示例：
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
//Pod 和 容器 的资源请求和限制：
spec.containers[].resources.requests.cpu //定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory //定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu //定义 cpu 的资源上限
spec.containers[].resources.limits.memory //定义内存的资源上限
二、CPU 资源单位
CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes 中的一个 cpu 相当于1个 vCPU（1个超线程）。
Kubernetes 也支持带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的一半 CPU 资源（类似于Cgroup对CPU资源的时间分片）。表达式 0.1 等价于表达式 100m（毫核），表示每 1000 毫秒内容器可以使用的 CPU 时间总量为 0.1*1000 毫秒。
Kubernetes 不允许设置精度小于 1m 的 CPU 资源。
三、内存资源单位
内存的 request 和 limit 以字节为单位。可以以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示， 或者以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表示。
如：1KB=103=1000，1MB=106=1000000=1000KB，1GB=10^9=1000000000=1000MB
1KiB=210=1024，1MiB=220=1048576=1024KiB
PS：在买硬盘的时候，操作系统报的数量要比产品标出或商家号称的小一些，主要原因是标出的是以 MB、GB为单位的，1GB 就是1,000,000,000Byte，而操作系统是以2进制为处理单位的，因此检查硬盘容量时是以MiB、GiB为单位，1GiB=2^30=1,073,741,824，相比较而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte，所以检测实际结果要比标出的少一些。
实例：
apiVersion: v1
kind: Pod
metadata:
name: myapp-demo4
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
resources:
requests:
cpu: "0.25"
memory: "128Mi"
limits:
cpu: "0.5"
memory: "256Mi"
- name: db
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "abc123"
ports:
- containerPort: 80
resources:
requests:
cpu: "250m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "256Mi"
restartPolicy: Always
kubectl describe pod myapp-demo4
当容器中进程尝试使用超出所允许内存量的资源时，系统内核会将尝试申请内存的进程终止， 并引发内存不足（OOM）错误。
限制可以以被动方式来实现（系统会在发现违例时进行干预），或者通过强制生效的方式实现 （系统会避免容器用量超出限制）。不同的容器运行时采用不同方式来实现相同的限制。
kubectl describe node node01 //查看node01节点pod使用资源情况
四、为本地临时性存储设置请求和限制
你可以指定 ephemeral-storage 来管理本地临时性存储。 Pod 中的每个容器可以设置以下属性：
spec.containers[].resources.limits.ephemeral-storage
spec.containers[].resources.requests.ephemeral-storage
ephemeral-storage 的请求和限制是按量纲计量的。 你可以使用一般整数或者定点数字加上下面的后缀来表达存储量：E、P、T、G、M、k。 你也可以使用对应的 2 的幂级数来表达：Ei、Pi、Ti、Gi、Mi、Ki。 例如，下面的表达式所表达的大致是同一个值：
- 128974848
- 129e6
- 129M
- 123Mi
请注意后缀的大小写。如果你请求 400m 临时存储，实际上所请求的是 0.4 字节。 如果有人这样设定资源请求或限制，可能他的实际想法是申请 400Mi 字节（400Mi） 或者 400M 字节。
在下面的例子中，Pod 包含两个容器。每个容器请求 2 GiB 大小的本地临时性存储。 每个容器都设置了 4 GiB 作为其本地临时性存储的限制。 因此，整个 Pod 的本地临时性存储请求是 4 GiB，且其本地临时性存储的限制为 8 GiB。 该限制值中有 500Mi 可供 emptyDir 卷使用。
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
resources:
requests:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
volumeMounts:
- name: ephemeral
mountPath: "/tmp"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
volumeMounts:
- name: ephemeral
mountPath: "/tmp"
volumes:
- name: ephemeral
emptyDir:
sizeLimit: 500Mi
五、总结
Pod 容器的资源限制：
spec.containers.resources.requests.cpu/memory 设置Pod容器创建时需要预留的资源量 容器应用最低配置 <= requests <= limits
spec.containers.resources.limits.cpu/memory 设置Pod容器能够使用的资源量上限，如容器进程内存使用量超出limits.memory会引发OOM
cpu资源量单位： cpu数 1 2 0.1 0.25 毫核 1000m 2000m 100m 250m
内存资源量单位： 整数（默认单位为字节） 2的底数单位（Ki Mi Gi Ti） 10的底数单位（K M G T）
kubectl describe node XXX 查看node节点中 每个pod 或 总的 资源量限制
kubectl describe pod xxx 查看Pod中 每个容器的 资源量限制