一、Docker资源配额

1、Docker资源配额简介

Docker默认没有对容器进行硬件资源的限制，当容器负载过高时会尽可能占用宿主机资源。Docker基于Linux内核提供的cgroups功能，可以限制容器在运行时使用的资源，比如内存、CPU、IO、网络等。

在Linux系统上，如果Linux内核探测到当前宿主机已经没有可用内存使用，会抛出一个OOME(Out Of Memory Exception:内存异常 )，并且会开启killing去杀掉一些进程。

一旦发生OOME，任何进程都有可能被杀死，包括Docker daemon，因此，Docker特地调整了Docker daemon的OOM_Odj优先级，以免被杀掉，但容器的优先级并未被调整。

经过Linux系统内部复杂计算后，每个系统进程都会有一个OOM_Score得分，OOM_Odj越高，得分越高，得分最高的进程优先被kill掉。

Docker在启动容器时可以调整OOM_Odj，也可以指定重要容器禁止被OMM杀掉，在启动容器时使用–oom-kill-disable=true指定。

2、cgroup简介

Control Groups是Linux内核提供的一种可以限制、记录、隔离进程组所使用物理资源(如CPU、Memory、磁盘IO等等) 的机制，被LXC、Docker等项目用于实现进程资源控制。cgroup是提供将进程进行分组化管理的功能和接口的基础结构，用于实现IO或内存配控制等具体的资源管理功能。cgroup实现的资源管理功能称为cgroup子系统，如下：

（1）blkio，设置限制每个块设备的输入输出控制，如磁盘、光盘、USB等。

（2）cpu，使用调度程序为cgroup任务提供CPU访问。

（3）cpuacct，产生cgroup任务的CPU资源报告。

（4）cpuset，对于多核心CPU，会为cgroup任务分配单独CPU和内存。

（5）devices，允许或拒绝cgroup任务对设备的访问。

（6）freezer，暂停和恢复cgroup任务。

（7）memory，设置每个cgroup的内存限制以及产生内存资源报告。

（8）net_cls，标记每个网络包以供cgroup方便使用。

（9）ns，命名空间子系统。

（10）perf_event，增加对每个group的监测跟踪的能力，即可以监测属于某个特定的group的所有线程以及运行在特定CPU上的线程。

二、Docker内存配额

1、Docker内存限额

Docker提供的内存限制功能如下：

（1）容器能使用的内存和交换分区大小。

（2）容器的核心内存大小。

（3）容器虚拟内存的交换行为。

（4）容器内存的软性限制。

（5）是否杀死占用过多内存的容器。

（6）容器被杀死的优先级。

2、Docker内存限制参数

（1）memory

-m,--memory，内存限制，格式为数字加单位，单位可以为b,k,m,g，最小为4M。

--memory-swap，内存+交换分区大小总限制，必须比memory设置的大。

如果不设置memory和memory-swap，Docker容器默认可以用完宿主机的所有内存和swap分区。Docker容器用尽宿主机的所有内存和swap分区超过一段时间后，会被宿主机系统杀死。

如果memory设置一个不小于4M的值n，不设置memory-swap或将memory-swap设置为 0，则Docker容器能使用的内存大小为 n，能使用的交换分区大小也为 n，Docker默认容器交换分区的大小和内存相同；如果在Docker容器中运行一个一直不停申请内存的程序，Docker容器最终能占用的内存大小为2n；如果memory设置为a，memory-swap设置为b，则Docker容器能使用的内存大小为a，Docker容器能使用的swap分区大小为b-a；如果memory设置a，memory-swap设置为-1，则Docker容器能使用的内存大小为a，不限制Docker容器使用swap分区大小。

--memory-reservation，内存的软性限制。

Memory reservation 是一种软性机制，不保证任何时刻容器使用的内存不会超过memory-reservation限定值，只确保容器不会长时间占用超过memory-reservation限制的内存大小。虽然Docker容器最多可以使用memory的内存大小，但在宿主机内存资源紧张时，在系统的下次内存回收时，系统会回收容器的部分内存页，强迫容器的内存占用回到memory-reservation的大小。

默认情况下，未设置memory-reservation值，其值与memory限定值相同。如果memory-reservation设置为0，则等同于没有设置。

（2）OOM killer

--oom-kill-disable，是否阻止OOM killer杀死容器，默认未设置。

默认情况下，在出现out-of-memory(OOM)错误时，OOM killer进程会杀死Docker容器内的进程来释放内存。通过设置--oom-kill-disable选项来禁止OOM killer杀死容器内进程。确保只有在使用memory选项时才使用oom-kill-disable选项禁用OOM killer。如果没有设置memory选项，但禁用OOM-killer，可能会造成出现OOM错误时，通过杀死宿主机进程获取更多内存。

--oom-score-adj，容器被OOM killer杀死的优先级，范围是[-1000, 1000]，默认为0，值越大越容易被kill。

--memory-swappiness，用于设置容器的虚拟内存控制行为。值为0~100之间的整数。

（3）kernel memory

--kernel-memory，核心内存限制，最小为4M。

核心内存和用户内存不同的地方在于核心内存不能被交换出，因此Docker容器可以通过消耗太多内存来堵塞一些系统服务。核心内存包括：stack pages（栈页面）、slab pages、socket memory pressure、tcp memory pressure。

可以通过设置核心内存限制来约束核心内存。例如，每个进程都要消耗一些栈页面，通过限制核心内存，可以在核心内存使用过多时阻止新进程被创建。

核心内存和用户内存并不是独立的，必须在用户内存限制的上下文中限制核心内存。

假设用户内存的限制值为U，核心内存的限制值为K。有三种可能地限制核心内存的方式：

U != 0，不限制核心内存，是默认的标准设置方式

K < U，核心内存是用户内存的子集，每个cgroup的内存总量被过度使用，可以设置K，groups总数就不会超过总内存。

K > U，核心内存的变化也会导致用户计数器的变化，容器核心内存和用户内存都会触发回收行为。

docker run -it -m 500M --kernel-memory 50M ubuntu:16.04 /bin/bash

启动容器，Docker容器的进程最多能使用500M内存、50M核心内存。

docker run -it --kernel-memory 50M ubuntu:16.04 /bin/bash

没用设置用户内存限制，Docker容器中的进程可以使用尽可能多的内存，但最多能使用50M核心内存。

（4）Swappiness

默认情况下，Docker容器的内核可以交换出一定比例的匿名页，使用memory-swappiness参数进行设置。--memory-swappiness可以设置为从 0到100。0表示关闭匿名页面交换。100表示所有的匿名页都可以交换。默认情况下，如果设置--memory-swappiness，则从父进程继承而来。

docker run -it --memory-swappiness=0 ubuntu:16.04 /bin/bash

memory-swappiness设置为0可以保持容器的工作集，避免交换代理的性能损失。

三、Docker CPU配额

1、Docker CPU限制

默认情况，所有Docker容器可以平等地使用宿主机CPU资源并且没有限制。

Docker提供的CPU资源限制选项可以在多核系统上限制容器能利用哪些 CPU。而Docker容器最多能使用CPU时间有两种限制方式：一是有多个CPU 密集型的容器竞争CPU时，设置各个容器能使用CPU时间相对比例；二是以绝对的方式设置容器在每个调度周期内最多能使用的CPU时间。

Docker可以通过-c或--cpu-shares设置容器使用CPU的权重。如果不指定，默认值为1024。

2、CPU限制参数

docker run与CPU限制相关选项如下：

--cpuset-cpus="" 允许使用的CPU集，值可以为0-3,0,1

-c,--cpu-shares=0   CPU权重

--cpu-period=0      限制CPU CFS周期，范围从100ms~1s，即[1000, 1000000]

--cpu-quota=0       限制CPU CFS配额，必须不小于1ms，即大于等于1000

--cpuset-mems=""   允许在上执行的内存节点（MEMs），只对NUMA系统有效

--cpus=value   指定容器可以使用的CPU资源量。如果主机有两个CPU并且设置 --cpus="1.5"，则容器最多可以使用1.5个CPU，

--cap-add=sys_nice 开启Docker容器CAP_SYS_NICE功能，允许容器引发进程良好值，设置实时调度策略，设置CPU亲和性以及其他操作。

--cpu-rt-runtime=<value> 容器可以在Docker守护程序的实时调度程序周期内以实时优先级运行的最大微秒数，需要开启CAP_SYS_NICE功能 。

--ulimit rtprio=<value> 容器允许的最大实时优先级，需要开启CAP_SYS_NICE功能。

docker run --it --cpu-rt-runtime=950000 --ulimit rtprio=99  --cap-add=sys_nice ubuntu

实时调度程序运行容器，需要运行docker daemon，并将--cpu-rt-runtime设置为每个运行时间段为实时任务保留的最大微秒数。默认周期为1000000微秒（1秒），设置--cpu-rt-runtime=950000可确保使用实时调度程序的容器每1000000微秒可运行950000微秒，并保留至少50000微秒用于非实时任务。

其中--cpuset-cpus用于设置容器可以使用的 CPU核。

-c,--cpu-shares用于设置多个容器竞争CPU时，各个容器能分配到的CPU权重。

--cpu-period和--cpu-quata用于绝对设置容器能使用 CPU 时间。

docker run -it --cpuset-cpus="1,3" ubuntu:14.04 /bin/bash

容器中的进程可以在cpu 1和cpu 3上执行。

docker run -it --cpuset-cpus="0-2" ubuntu:14.04 /bin/bash

容器中的进程可以在 cpu 0、cpu 1 及 cpu 2上执行。

docker run -it --cpuset-mems="1,3" ubuntu:14.04 /bin/bash

容器中的进程只能使用内存节点1和3上的内存

在多核系统上，CPU时间权值是在所有CPU核上计算的。即使某个容器的 CPU 时间限制少于100%，也能使用各个CPU核的100%时间。

四、Docker磁盘IO配额

Docker对磁盘IO的控制需要依赖宿主机设备，主要参数如下：

--device-read-bps 限制设备上的读速度（bytes per second），单位可以是kb、mb或者gb。

--device-read-iops 通过每秒读IO次数来限制指定设备的读速度。

--device-write-bps 限制设备的写速度（bytes per second），单位可以是kb、mb或者gb。

--device-write-iops 通过每秒写IO次数来限制指定设备的写速度。

--blkio-weight      容器默认磁盘IO的加权值，有效值范围为10-100。

--blkio-weight-device 针对特定设备的IO加权控制,其格式为DEVICE_NAME:WEIGHT

docker run -tid –name disk1 –device-write-bps /dev/sda:1mb ubuntu:stress

五、Docker容器空间配额

docker使用devicemapper作为存储驱动时，默认每个容器和镜像的最大大小为10G。在docker daemon启动时可以使用dm.basesize来指定，但会导致Docker Host上的所有本地镜像和容器都被清理掉，使用aufs或者overlay等其它存储驱动时，没有限制。

多用户或者多团队共享集群时，管理员可以通过资源配额的方式来管理各个团队或者用户可使用资源的额度。

ResourceQuota对象用于定义资源配额。可以限制对象数量，也可以限制计算资源。

资源配额有如下工作方式：

​ 1、不同团队在各自命名空间下工作。软性约束

​ 2、每个命名空间都可以有自己的一个或多个ResourceQuota对象，由集群管理员创建。

​ 3、在命名空间中创建资源如Pod、Service时，如果超过配额，请求会报错

​ 4、命名空间下计算资源被启用时，cpu memeory ，必须同时有请求值request和约束值limit。准入控制器LimitRanger可以为未设置计算资源需求的Pod设置默认值

1、启用资源配额

一般是默认启用。

API服务器的命令行标识 --enable-admission-plugins=中包含 ResourceQuota时，表示启用

2、资源配额分类

2.1命名空间的计算资源配额

可以对命名空间限定其可使用的计算资源总量。 均为非终止状态下Pod

资源配额名	描述
limits.cpu	cpu总量
limits.memory	内存限额
requests.cpu 或者 cpu	cpu需求总量
requests.memory 或者 memory	内存需求总量
hugepages-<size>	针对指定尺寸的巨页请求总数

2.2、扩展资源的资源配额

k8s 1.10版本中增加了对扩展资源的支持

扩展资源：kubernetes.io域名之外的标准资源名称，非kubernetes内置资源。集群管理员颁布之后，用户在Pod中请求

• 节点级扩展资源，绑定到节点

• 集群层面的扩展资源，由调度器扩展程序管理

扩展资源不可超量分配，仅允许使用 requests.前缀的配额项。

例如GPU，此处限制总数为4

requests.nvidia.com/gpu: 4

2.3、存储资源配额

requests.storage: 所有PVC
persistentvolumeclaims: 该命名空间中允许的PVC总量
<storage-class-name>.storageclass.storage.k8s.io/requests.storage: 相关持久卷申领时可请求的最大总和
<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims:  可存在的持久卷总数

# 例如
gold.storageclass.storage.k8s.io/requests.storage: 500Gi

k8s 1.8版本中

requests.ephemeral-storage: 命名空间下所有Pod中临时存储请求总和
limits.ephemeral-storage: 命名空间下所有Pod中临时存储限制总和
ephemerral-storage: 和request.xxx相同

2.4、对象数量配额

针对命名空间内部的资源，进行数量限制。

语法：

count/<resource>.<group>: 非核心组的资源
count/<resource>: 核心组的资源

示例：

# 内置资源
count/persistentvolumeclaims
count/services
count/secrets
count/configmaps
count/replicationcontrollers
count/resourcequotas: 命名空间中允许存在的ResourceQuota总数上限
count/deployments.apps
count/replicasets.apps
count/statefulsets.apps
count/jobs.batch
count/cronjobs.batch

# 自定义资源
count/widgets.example.com

3、操作实践

3.1、建立计算资源配额

创建命名空间

kubectl create namespace test

创建并编写计算资源配额配置文件

vi compute-resource.yaml

文件内容

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.nvidia.com/gpu: 4

应用文件

kubectl create -f ./compute-resource.yaml --namespace=test

如下命令均可查看命名空间配额

kubectl describe namespace test

kubectl describe quota compute-resource --namespace=test

kubectl get quota --namesapce=test

可以看到命名空间中已有ResourceQuota对象

3.2、创建存储容量配额

kubectl create quota storage-quota --hard=bronze.storageclass.storage.k8s.io/requests.storage=100Gi --namespace=test

3.3、创建对象数量配额

可以通过kubectl命令创建

kubectl create quota object-counts --hard=count/deployment.apps=1,count/replicasets.apps=2,count/pods=3 --namespace=test

可以通过yaml文件创建

vi object-counts.yaml 创建文件

文件内容

apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "4"
    pods: "4"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
    services.loadbalancers: "2"

应用文件

kubectl create -f ./object-counts.yaml --namespace=test

查看配额

命令同上，此处不再赘述

4、API接口

获取命名空间配额详情

# namespace-name: 命名空间名称
# quota-name: 配额名称 如上方提到的 compute-resource  object-count等

url = /api/v1/namespaces/{namespace-name}/resourcequotas/{quota_name}

修改配额 查询下patch的用法，自行拼接配额数据即可

kubectl patch xxx

Docker资源配额和数据持久化

Docker可以对容器使用的资源（CPU、内存、IO）进行配额控制，Docker对于所有资源的分配都是通过cgroup来进行的资源配额。
cgroup是Control Groups的缩写，是Linux内核提供的一种可以限制、记录、隔离进程所使用的物理资源（cpu、内存、IO）的一种技术，被LXC、docker等很多项目用于实现进程对应资源的控制。

指定容器在哪几个core上运行

指定容器在cpu0，1上运行

docker run -itd --name docker10 --cpuset-cpus 0,1 --cpu-shares 512 centos /bin/bash

给容器实例分配512权重的cpu使用份额

docker run --help | grep cpu-shares
# 查看配置份额的帮助命令
cpu 配额参数：-c,--cpu-shares int

CPU shares (relative weight)在创建容器时指定容器所使用的CPU份额值。cpu-shares的值不能保证可以获得1个vcpu或者多少Ghz的cpu资源，仅仅只是一个弹性的加权值。默认每个docker容器的cpu份额值都是1024.在同一个cpu核心上，同时运行多个容器时，容器的cpu加权的效果才能体现出来。
例如：两个容器A、B的cpu份额分别为1000和500，结果会怎么样？
情况1：A和B正常运行，占用同一个CPU，在cpu进行时间片分配的时候，容器A比容器B多一倍的机会获得CPU的时间片。
情况2：分配的结果取决当时其他容器的运行状态。比如容器A的进程一直是空闲的，那么容器B是可以获取比容器A更多的CPU时间片的；比如主机上只运行了一个容器，即使它的cpu份额只有50，它也可以独占整个主机的cpu资源。

cgroups只在多个容器同时争抢同一个cpu资源是，cpu配额才会生效。因此，无法单纯根据某个容器的cpu份额来确定有多少cpu资源分配给它，资源分配结果取决于同时运行的其他容器的cpu分配和容器中进程运行情况。

给容器实例分配512权重的cpu使用份额

docker run -it --cpu-shares 512 centos /bin/bash
cat /sys/fs/cgroup/cpu/cpu.shares

容器资源内存配额

允许容器使用的内存上限为128M：

docker run -it -m 128m centos
cat /sys/fs/cgroup/memory/memory.limit_in_bytes

容器资源IO配额

可以有效的防止某个docker容器吃光你的磁盘I/O资源
限制容器实例对磁盘的最该写入速度为1MB/s

mkdir -p /var/www/html/
docker run -it -v /var/www/html/:/var/www/html --device /dev/sda:/dev/sda --device-write-bps /dev/sda:1mb centos /bin/bash
time dd if=/dev/sda of=/var/www/html/test.out bs=1M count=50 oflag=direct,nonblock