前言
本文介绍企业级实践中使用的一套 K8S 或 Docker 的 CPU 内存资源限制方案，如果不对这些资源进行限制，瞬时的 CPU 或内存升高对服务器宕机风险会非常高，甚至服务器出现长时间假死不响应等现象。
注：只对容器里的 Java 程序进行限制如 -Xmx 的作用不是特别大，仍可能因为堆外内存申请导致资源限制失效，进而影响服务器。
正文
一、内存
（一）Docker容器限制
修改 yaml 文件方法：
demo-service.yaml
containers:
- image: 192.168.10.5:8082/demo:1-0-0
resource:
limits:
memory: 1024Mi # 1Gi
docker 启动加参数方法：
（1）使用 docker openjdk:8 启动 springboot.jar 包
docker run -d \
-p 8080:8080 \
--memory 256M \
openjdk:8 \
java -jar /tmp/untitled-1.0-SNAPSHOT.jar
注：可使用 yaml 文件方法也可以在 docker run 命令里直接限制，本例容器内存限制为256MiB，每次 http 请求向静态 ArrayList 对象中添加一个约一万字节大小的对象
（2）使用 python requests 连续发起请求
requests.get(url="http://localhost:8080/heap")
（3）当请求数量到达8000多时，内存使用趋于用尽，直到使用达到使用量达到99.99%时，SpringBoot抛出OOM异常
docker stats截图：
spring boot 运行日志截图：
java.lang.OutOfMemoryError: Java heap space
同时，客户端（python）抛出异常：
ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
tcp 连接被关闭，且未获得 http 响应
（4）再次尝试请求，结果与最后一次请求完全相同
连接成功，服务器处理请求，请求过程中发生OOM异常，http连接被直接断开，不发送响应。
（5）尝试请求其他接口，结果与上述接口完全相同
（二）Pod限制
测试过程：
只限制Pod内存，不限制Container内存时，Pod启动不成功
（三）K8S限制
方法：
limitrange.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: demo-1-0-0-limitrange
spec:
limits:
- type: Pod
max:
memory: 1Gi
- type: Container
max:
memory: 1Gi
测试过程：
使用 limitrange 后：
kubectl describe pod demo
二、CPU
（一）Docker
docker run -itd --cpu-period=100000 --cpu-quota=200000 centos:7
# cpu-period(微秒)内，最多可使用cpu-quota(微秒)运行该容器
# 多核情况下，若cpu-period<cpu-quota，则容器进程可以完全占用多个CPU。
# 测试代码(Kotlin)
for (i in 0 until 5) {
thread(start = true) {
while (true) {
println(i)
Thread.sleep(10)
}
}
}
（二）K8S
apiVersion: v1
kind: LimitRange
metadata:
name: demo-1-0-0-limitrange
spec:
limits:
- type: Pod
max:
cpu: '2'
memory: 1Gi
- type: Container
max:
cpu: '2'
memory: 1Gi
defaultRequest: # 默认请求资源量
cpu: '0'
kubectl describe pod demo
docker inspect demo
附：资源类型说明
cpu: '2'
> 2核，等价于 '2000m' 或 '2000000n' (m微秒 n纳秒 即200%)
memory: '1024Mi'
> 1024MiB = 1024 * 1024 KiB = 1024 * 1024 * 1024 Byte
> 1MB = 1000KB = 1000000 Byte
- max 请求资源上限
- min 请求资源下限
- defaultRequest 默认请求资源量
> 不设置defaultRequest时，按default分配，可能会直接分配最大限制量
总结
对服务器资源进行一个提前合理的规划是非常有必要的，当然系统资源的监控预警软件也是必不可少的，本文介绍企业级实践中使用的一套 K8S 或 Docker 的 CPU 内存资源限制方案，极大的降低服务器因容器或应用资源占用导致的整体崩溃概率。喜欢可以关注我~有问题可以留言或私信我。