Kubernetes计算资源管理--requests和limits(续2)

Kubernetes版本： 1.5.4
实验环境： Ubuntu 14.04 64bit
Docker版本： 1.26

(续) 上文已经对Kubernetes中requests参数的作用，也对docker和cgroup中对应的参数设置进行了说明。本文将对Kubernetes中
limits参数的作用进行分析。

1、对CPU资源的limit实验
(利用stress工具，进行压力测试)
pod cpu-ram-demo31的配置：



执行： docker
exec -it --privileged=true 57db /bin/bash
然后在容器中启动stress命令：

stress --vm 1 --vm-bytes 1000M

查看pod的状态：



CPU使用量在0.8核，说明limit参数的作用为限定cpu使用量的上限。

2、对memory资源的limit实验
pod cpu-ram-demo32的配置：



创建一个requests为1G，limit为2G的pod。
在执行stress压测到1.9G是进程运行正常。



查看容器的状态：



继续加大内存的使用量，超过2G后，进程则运行异常



3、对CPU资源的抢占实验
创建3个pod，pod的配置信息分别为：







容器启动后的信息：



步骤1：在pod cpu-demo-41中启动压测命令，pod的状态信息：



步骤2：在pod cpu-demo-42中启动压测命令，pod的状态信息：



此时cpu-demo-41的状态还是保持不变：



步骤3：在pod cpu-demo-43中启动压测，pod的状态信息：





删除pod cpu-demo-41， 创建cpu-demo-44， 其配置如下：



启动pod cpu-demo-44的压力测试后，cpu-demo-44的状态为：



说明： pod直接CPU发生抢占的时候，安装requests的值对CPU进行分配。

4、对Memory资源的抢占实验

创建三个pod，分别的配置如下：







三个pod依次启动压力测试后：

第一个pod使用内存5G，使用正常

第二个pod使用内存2G，使用正常

第三个pod使用内存1G，出现stress进程crash的情况。

重复执行该过程，发现第二个pod和第三个pod的进程都有可能出现挂掉的情况。

替换第二个pod(cpu-ram-demo522),替换的配置如下：



重复上述实验，则只会出现第三个pod挂掉的情况。

说明： 在memory出现抢占的情况下，requests的值设置小于limit值时，则可能出现进程挂掉的情况。