K8S和Docker服务器资源限制(CPU/内存)

前言

本文介绍企业级实践中使用的一套 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 内存资源限制方案，极大的降低服务器因容器或应用资源占用导致的整体崩溃概率。喜欢可以关注我~有问题可以留言或私信我。