8. 资源需求与限制

# 资源

CPU：1个单位的CPU相当于虚拟机上的1颗虚拟CPU（vCPU）或物理机上的一个超线程（Hyperthread，或称为一个逻辑CPU），它支持分数计量方式，一个核心（1core）相当于1000个微核心（millicores），因此500m相当于是0.5个核心，即二分之一个核心。 内存：内存的计量方式与日常使用方式相同，默认单位是字节，也可以使用E、P、T、G、M和K作为单位后缀，或Ei、Pi、Ti、Gi、Mi和Ki形式的单位后缀。

# 资源需求

“requests”属性定义其请求的确保可用值，即容器运行时需要的最小配置，如果节点剩余CPU和内存资源不满足pod运行资源需求，则无法调度至该节点上。 示例

- 定义一个Pod中stress容器，确保128Mi的内存及五分之一个CPU核心（200m）资源可用，
- 它运行stress-ng镜像启动一个进程（-m 1）进行内存性能压力测试，满载测试时它也会尽可能多地占用CPU资源
- 另外再启动一个专用的CPU压力测试进程（-c 1）。

![未命名图片.png](/media/202406/4.8.15263800_image1.png)

- 查看资源使用情况

![未命名图片.png](/media/202406/4.8.15263800_image2.png)

- 每个测试进程CPU占用率为25%，内存占用为262m，此两项资源占用量都远超其请求的用量，原因是stress-ng会在可用的范围内尽量多地占用相关的资源

# 资源限制

”limits”属性则用于限制资源可用的最大值，即硬限制，如果pod使用的资源超过该限制，控制器将会杀死该pod。 示例：一个Pod对象，它模拟内存泄漏操作不断地申请使用内存资源，直到超出limits属性中memory字段设定的值而导致“OOMKillled”为止： ![未命名图片.png](/media/202406/4.8.15263800_image3.png)

- Pod资源的默认重启策略为Always，于是在memleak因内存资源达到硬限制而被终止后会立即重启。不过，多次重复地因为内存资源耗尽而重启会触发Kubernetes系统的重启延迟机制，即每次重启的时间间隔会不断地拉长。于是，用户看到的Pod资源的相关状态通常为“CrashLoopBackOff”：

![未命名图片.png](/media/202406/4.8.15263800_image4.png)

# 注意事项
在编写资源清单时，强烈建议添加limits参数，防止pod异常导致占用节点过多资源，从而导致该节点上的其他pod因资源不足而异常退出。 如果只设置limits而未设置requests时，默认的requests值等于limits值。