docker CPU限制参数

Option	Description
--cpus=<value>	Specify how much of the available CPU resources a container can use. For instance, if the host machine has two CPUs and you set --cpus="1.5", the container is guaranteed at most one and a half of the CPUs. This is the equivalent of setting --cpu-period="100000" and --cpu-quota="150000". Available in Docker 1.13 and higher.
--cpu-period=<value>	Specify the CPU CFS scheduler period, which is used alongside--cpu-quota. Defaults to 100 micro-seconds. Most users do not change this from the default. If you use Docker 1.13 or higher, use --cpusinstead.
--cpu-quota=<value>	Impose a CPU CFS quota on the container. The number of microseconds per --cpu-period that the container is limited to before throttled. As such acting as the effective ceiling. If you use Docker 1.13 or higher, use --cpus instead.
--cpuset-cpus	Limit the specific CPUs or cores a container can use. A comma-separated list or hyphen-separated range of CPUs a container can use, if you have more than one CPU. The first CPU is numbered 0. A valid value might be 0-3 (to use the first, second, third, and fourth CPU) or 1,3 (to use the second and fourth CPU).
--cpu-shares	Set this flag to a value greater or less than the default of 1024 to increase or reduce the container’s weight, and give it access to a greater or lesser proportion of the host machine’s CPU cycles. This is only enforced when CPU cycles are constrained. When plenty of CPU cycles are available, all containers use as much CPU as they need. In that way, this is a soft limit. --cpu-shares does not prevent containers from being scheduled in swarm mode. It prioritizes container CPU resources for the available CPU cycles. It does not guarantee or reserve any specific CPU access.

①   --cpus指示容器可以使用的CPU数量。改参数指定的是百分比，并不是具体的个数。比如：主机有4个逻辑CPU，限制容器—cpus=2，那么该容器最多可以使用的CPU时间是200%，但是4个CPU分配的时间可能是每个CPU各50%，而不一定是有其中2个CPU使用100%，而另2个CPU使用0%。

--cpus是docker 1.13之后才出来的参数，目的是替代--cpu-period和--cpu-quota两个参数，从而使配置更简单。

②   --cpu-period表示的是设置CPU时间周期，默认值是100000，单位是us，即0.1s。

③   --cpu-quota指示容器可以使用的最大的CPU时间，配合--cpu-period值使用。如果—cpu-quota=200000，即0.2s。那就是说在0.1s周期内改容器可以使用0.2s的CPU时间，显然1个CPU是无法满足要求的，需要至少2个CPU才能满足。

④   --cpuset-cpus设置容器具体可以使用哪些个CPU。如--cpuset-cpus=”0,1,2”或者--cpuset-cpus=”0-2”，则容器会使用第0-2个CPU。

⑤   --cpu-shares，容器使用CPU的权重，默认值是1024，数值越大权重越大。该参数仅当有多个容器竞争同一个CPU时生效。对于单核CPU，如果容器A设置为--cpu-shares=2048，容器B设置为--cpus-shres=1024，仅当两个容器需要使用的CPU时间超过整个CPU周期的时候，容器A会被分配66%的CPU时间，容器B被分配33%的CPU时间，大约是2:1；对于多核CPU，仅当多个容器竞争同一个CPU的时候该值生效。

kubernetes对CPU限制

第一种：资源对象LimitRange限制POD和Container的资源

apiVersion: v1
kind: LimitRange
metadata:
  name: mylimits
spec:
  limits:
  - max:
      cpu: "2"
      memory: 1Gi
    min:
      cpu: 200m
      memory: 6Mi
    type: Pod

  - default:
      cpu: 300m
      memory: 200Mi
    defaultRequest:
      cpu: 200m
      memory: 100Mi
    max:
      cpu: "2"
      memory: 1Gi
    min:
      cpu: 100m
      memory: 3Mi
type: Container

第二种：定义pod时候限制资源

spec:
  containers:
  - image: gcr.io/google_containers/serve_hostname
   imagePullPolicy: Always
   name: kubernetes-serve-hostname
   resources:
     limits:
       cpu: "1"
       memory: 512Mi
     requests:
       cpu: "1"
       memory: 512Mi

如果两者都配置?

先匹配pod里的，再匹配namespace里。

有些时候, 我们大部分容器遵循一个规则就好, 但有一小部分有特殊需求, 这个时候, 小部分的就需要单独在容器的配置文件中指定. 这里有一点要注意的是, 单独在容器中配置的参数是不能大于指定的k8s资源限制, 否则会报错, 容器无法启动

PS: 对于一些java项目, 必须设置java虚拟机的参数, 而且这个参数不能大于容器设置的限定值, 否则容器会因为内存过大不停的重启

 

其中：

limits.cpu  <==>  --cpu-quota         # docker inspect中的CpuQuota值

requests.cpu  <==>  --cpu-shares     # docker inspect中的CpuShares值

实验对比

测试工具stress介绍

root@ustress-77b658748b-7856l:/# stress --help

`stress' imposes certain types of compute stress on your system

 

Usage: stress [OPTION [ARG]] ...

 -?, --help         show this help statement

     --version      show version statement

 -v, --verbose      be verbose

 -q, --quiet        be quiet

 -n, --dry-run      show what would have been done

 -t, --timeout N    timeout after N seconds

     --backoff N    wait factor of N microseconds before work starts

 -c, --cpu N        spawn N workers spinning on sqrt()  #启动N个进程，每个进程最多占满一个CPU

 -i, --io N         spawn N workers spinning on sync()

 -m, --vm N         spawn N workers spinning on malloc()/free()

     --vm-bytes B   malloc B bytes per vm worker (default is 256MB)

     --vm-stride B  touch a byte every B bytes (default is 4096)

     --vm-hang N    sleep N secs before free (default none, 0 is inf)

     --vm-keep      redirty memory instead of freeing and reallocating

 -d, --hdd N        spawn N workers spinning on write()/unlink()

     --hdd-bytes B  write B bytes per hdd worker (default is 1GB)

 

Example: stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s

 

Note: Numbers may be suffixed with s,m,h,d,y (time) or B,K,M,G (size).

创建一个测试镜像

FROM ubuntu:latest

RUN apt-get update && \

        apt-get install stress

 

docker build -t reg.99bill.com/99bill/ustress .

创建一个kubernetes中deployment对象

apiVersion: apps/v1

kind: Deployment

metadata:

  labels:

    appname: ustress

    version: 0.0.6

  name: ustress

  namespace: default

spec:

  replicas: 1

  selector:

    matchLabels:

      appname: ustress

  template:

    metadata:

      labels:

        appname: ustress

        version: 0.0.6

    spec:

      containers:

      - image: reg.99bill.com/99bill/u-stress:latest

        name: ustress

        command: ['sh', '-c', 'stress -c 4']

        resources:

          limits:

            cpu: 2   #实验修改值

            memory: 1G

          requests:

            cpu: 1   #实验修改值

            memory: 500M

      terminationGracePeriodSeconds: 0

      nodeName: 192.168.112.10

      nodeSelector:

注：

①   command: ['sh', '-c', 'stress -c 4'] 表示开启4个占用CPU的stress进程

②   limits.cpu: 2 对应docker中"CpuQuota": 200000,  "CpuPeriod": 100000默认值

③   requests.cpu：1对应docker中"CpuShares": 1024,

测试一：

limits.cpu: 4

requests.cpu: 0.5

 

结果验证：

1. 查看docker容器参数值：

docker inspect e22896246184

 

512 = 0.5 * 1024

400000 = 4 * 100000

2. docker stats查看容器CPU使用率

由于设置了CPUQuota是CpuPeriod的4倍，所以容器可以使用400% CPU

3. 使用top查看进程与CPU

使用top命令查看4个stress进程，每个占用100% CPU，总400%，可以看到有4个CPU被跑满。

实验二：

limits.cpu: 6

requests.cpu: 0.5

1. 查看docker容器参数值：

 

512 = 0.5 * 1024

600000 = 6 * 100000

2. docker stats查看容器CPU使用率

容器可以使用600%的CPU，现在只用400%

3. 使用top查看进程与CPU

实验三：

limits.cpu: 1

requests.cpu: 0.5

1. 查看docker容器参数值：

docker inspect e22896246184

 

512 = 0.5 * 1024

100000 = 1 * 100000

2. docker stats查看容器CPU使用率

使用时间等于CpuPeriod，占用100%

3. 使用top查看进程与CPU

从下图可以看到，有4个CPU分别使用25%，加起来是100%。所以limits.cpu：1并不一定表示容器只会占用1个CPU，而表示的是容器最多可以使用的CPU时间的比例。

实验四：

limits.cpu: 0.5

requests.cpu: 0.5

1. 查看docker容器参数值

2. docker stats查看容器CPU使用率

3. 使用top查看进程与CPU

 

1. k8s容器资源限制

k8s采用request和limit两种限制类型来对资源进行分配

• request(资源需求)：即运行pod的节点必须满足运行pod的最基本需求才能运行pod。
• limit(资源限制)：即运行pod期间，可能内存使用量会增加，那最多能使用多少内存，这就是资源限额。

资源类型：

• CPU的单位是核心数，内存的单位是字节。
• 一个容器申请0.5各CPU，就相当于申请1个CPU的一半，可以加个后缀m表示千分之一的概念。比如说100m的CPU，100豪的CPU和0.1个CPU都是一样的。

内存单位：

• K，M，G，T，P，E #通常是以1000为换算标准的。
• Ki，Mi，Gi，Ti，Pi，Ei #通常是以1024为换算标准的。

2. 内存资源限制实例

[kubeadm@server2 limit]$ cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
 - name: memory-demo
    image: stress
    args:
    - --vm
    - "1"
    - --vm-bytes
    - 200M           // 容器使用200M
    resources:
      requests:      //资源需求，下限
        memory: 50Mi
      limits:        //资源限制，上限
        memory: 100Mi

[kubeadm@server1 limit]$ kubectl get pod
NAME                                      READY   STATUS             RESTARTS   AGE
memory-demo                               0/1     CrashLoopBackOff   3          106s

因为容器需要200M，超出了最大限制100Mi，所以容器无法运行。

• 如果容器超过其内存限制，则会被终止。如果可重新启动，则与其他所有类型的运行故障一样，kubelet将重新启动它。
• 如果一个容器超过其内存要求，那么当节点内存不足时，它的pod可能被逐出。

• 当资源限制没冲突的时候正常启动

[kubeadm@server1 limit]$ vim pod.yaml 
[kubeadm@server1 limit]$ cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-demo
    image: k8s/stress
    args:
    - --vm
    - "1"
    - --vm-bytes
    - 200M
    resources:
      requests:
        memory: 50Mi
      limits:
        memory: 300Mi    //将最大限制改为300mi，容器可以正常运行
[kubeadm@server1 limit]$

资源限制内部机制使用的是cgroup类型
目录： /sys/fs/cgroup/systemd

3. cpu资源限制

[kubeadm@server1 limit]$ cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: stress
    args:
    - -c
    - "2"            //容器需要2个cpu
    resources:
      requests:           //至少需要5个cpu
        cpu: "5" 
      limits:
        cpu: "10"     //最大限制10个cpu

[kubeadm@server1 limit]$ kubectl apply -f pod.yaml 
pod/cpu-demo created

[kubeadm@server1 limit]$ kubectl get pod -o wide
NAME                                      READY   STATUS    RESTARTS   AGE     IP             NODE      NOMINATED NODE   READINESS GATES
cpu-demo                                  1/1     Running   0          4m58s   10.244.2.124   server4   <none>           <none>
[root@server4 ~]# top   // server4上的两个cpu跑满了,CPU 使用率过高，不会被杀死
（top--->1）

top - 16:41:55 up  6:37,  1 user,  load average: 3.77, 2.69, 1.54
Tasks: 172 total,   4 running, 168 sleeping,   0 stopped,   0 zombie
%Cpu0  : 98.7 us,  0.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.7 hi,  0.3 si,  0.0 st
%Cpu1  : 98.3 us,  0.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.7 hi,  0.3 si,  0.0 st
KiB Mem :  2045672 total,   784128 free,   293728 used,   967816 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  1520056 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                      
21204 root      20   0    7312    100      0 R  98.3  0.0   5:29.21 stress                                                                       
21203 root      20   0    7312    100      0 R  97.0  0.0   5:29.84 stress 

调度失败是因为申请的CPU资源超出集群节点所能提供的资源
但CPU 使用率过高，不会被杀死
满足要求

[kubeadm@server1 limit]$ vim pod.yaml 
[kubeadm@server1 limit]$ cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: k8s/stress
    args:
    - -c
    - "2"
    resources:
      requests:
        cpu: "1"
      limits:
        cpu: "2"
[kubeadm@server1 limit]$

4. namespace设置资源限制

LimitRange资源限制：

apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-memory
spec:
  limits:
 - default:            //默认使用0.5个cpu，512mi内存
      cpu: 0.5
      memory: 512Mi
    defaultRequest:       //默认要求0.1个cpu和256mi内存
      cpu: 0.1
      memory: 256Mi
    max:                //最大2个cpu和1gi内存
      cpu: 1
      memory: 1Gi
    min:               //最小0.1个cpu和100mi内存
      cpu: 0.1
      memory: 100Mi
    type: Container

[kubeadm@server1 limit]$ kubectl apply -f limitrange.yaml 
limitrange/limitrange-memory created

[kubeadm@server1 limit]$ kubectl get limitranges 
NAME                CREATED AT
limitrange-memory   2020-05-08T08:52:10Z

[kubeadm@server1 limit]$ kubectl describe limitranges 
Name:       limitrange-memory
Namespace:  default
Type        Resource  Min    Max  Default Request  Default Limit  Max Limit/Request Ratio
----        --------  ---    ---  ---------------  -------------  -----------------------
Container   cpu       100m   2    100m             500m           -
Container   memory    100Mi  1Gi  256Mi            512Mi          -

注意：LimitRange 在 namespace 中施加的最小和最大内存限制只有在创建和更新 Pod 时才会被应用。改变 LimitRange 不会对之前创建的 Pod 造成影响。

LimitRange - default xx会自动对没有设置资源限制的pod自动添加限制
ResourceQuota设置配额限制

[kubeadm@server1 limit]$ cat quota.yaml 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: "1"   // 要求cpu1个     即cpu要求不得超过1个cpu
    requests.memory: 1Gi  // 要求内存1gi    即内存要求不得超过1Gi
    limits.cpu: "2"  // cpu限制2个          即cpu限制不得超过2个cpu
    limits.memory: 2Gi // 内存限制2gi       即内存限制不得超过2Gi

[kubeadm@server1 limit]$ kubectl apply -f quota.yaml 
resourcequota/mem-cpu-demo created

[kubeadm@server1 limit]$ kubectl get resourcequotas 
NAME           AGE   REQUEST                                     LIMIT
mem-cpu-demo   13s   requests.cpu: 0/1, requests.memory: 0/1Gi   limits.cpu: 0/2, limits.memory: 0/2Gi

[kubeadm@server1 limit]$ kubectl describe resourcequotas 
Name:            mem-cpu-demo
Namespace:       default
Resource         Used  Hard
--------         ----  ----
limits.cpu       0     2
limits.memory    0     2Gi
requests.cpu     0     1
requests.memory  0     1Gi

一旦设置配额后，后续的容器必须设置请求（4种请求都设置），当然，这只是在rq设置的defult的namespace中

4种请求：每个容器必须设置内存请求（memory request），内存限额（memory limit），cpu请求（cpu request）和cpu限额（cpu limit）

资源会统计总的namespace中的资源加以限定，不管是之前创建还是准备创建
创建的ResourceQuota对象将在default名字空间中添加以下限制：

• 每个容器必须设置内存请求（memory request），内存限额（memory limit），cpu请求（cpu
  request）和cpu限额（cpu limit）。
• 所有容器的内存请求总额不得超过1 GiB。
• 所有容器的内存限额总额不得超过2 GiB。
• 所有容器的CPU请求总额不得超过1 CPU。
• 所有容器的CPU限额总额不得超过2 CPU。

5. namespace中pod的配额

[kubeadm@server1 limit]$ cat podquata.yaml 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
    pods: "2"        //2个pod

设置Pod配额以限制可以在namespace中运行的Pod数量。

[kubeadm@server1 limit]$ kubectl apply -f podquata.yaml 
resourcequota/pod-demo created

[kubeadm@server1 limit]$ kubectl describe resourcequotas pod-demo // 当前只有一个pod
Name:       pod-demo
Namespace:  default
Resource    Used  Hard
--------    ----  ----
pods        1     2

[kubeadm@server1 limit]$ cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: test
    image: nginx

//创建一个pod
[kubeadm@server1 limit]$ kubectl apply -f pod.yaml 
pod/test created

[kubeadm@server1 limit]$ cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: test1
spec:
  containers:
  - name: test1
    image: nginx

//再创建一个pod时，会发生错误，因为在当前的namespace中限制两个pod
[kubeadm@server1 limit]$ kubectl apply -f pod.yaml 
Error from server (Forbidden): error when creating "pod.yaml": pods "test1" is forbidden: exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2

当然，以上设定对应相对的namespace，其它的namespace没有影响

为了后续不受影响，删除相应的设定

6. namespace的创建、使用和删除

创建namespace

kubectl create namespace test  // 创建test的namespace

运行yaml文件时指定namespace

kubectl apply -f pod.yaml -n test  // 在test的namespace中运行pod.yaml为文件

删除namespace

kubectl delete namespaces test // 删除名为test的namespace

7. 清除资源限制和配额

[kubeadm@server1 limit]$ kubectl delete -f limitrange.yaml 
limitrange "limitrange-memory" deleted

[kubeadm@server1 limit]$ kubectl delete -f podquata.yaml 
resourcequota "pod-demo" deleted

[kubeadm@server1 limit]$ kubectl delete -f quota.yaml 
resourcequota "mem-cpu-demo" deleted