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值时，则可能出现进程挂掉的情况。