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
    resources:
      requests:
        memory: 50Mi
      limits:
        memory: 100Mi
  • 如果容器超过其内存限制,则会被终止。如果可重新启动,则与其他所有类型的运行故障一样,kubelet将重新启动它。
  • 如果一个容器超过其内存要求,那么当节点内存不足时,它的pod可能被逐出。

k8s nodes cpu下限 k8s cpu limit_vim

  • 当资源限制没冲突的时候正常启动
[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
[kubeadm@server1 limit]$

k8s nodes cpu下限 k8s cpu limit_重新启动_02


k8s nodes cpu下限 k8s cpu limit_重新启动_03

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

3. cpu资源限制

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: stress
    args:
    - -c
    - "2"
    resources:
      requests:
        cpu: "5"
      limits:
        cpu: "10"

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

k8s nodes cpu下限 k8s cpu limit_重新启动_04

k8s nodes cpu下限 k8s cpu limit_k8s nodes cpu下限_05

满足要求

[kubeadm@server1 limit]$ vim cpulim.yaml 
[kubeadm@server1 limit]$ cat cpulim.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]$

k8s nodes cpu下限 k8s cpu limit_Pod_06

4. namespace设置资源限制

LimitRange资源限制

apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-memory
spec:
  limits:
 - default:
      cpu: 0.5
      memory: 512Mi
    defaultRequest:
      cpu: 0.1
      memory: 256Mi
    max:
      cpu: 1
      memory: 1Gi
    min:
      cpu: 0.1
      memory: 100Mi
    type: Container

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

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

k8s nodes cpu下限 k8s cpu limit_重新启动_07

ResourceQuota设置配额限制

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:                     硬限制
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

k8s nodes cpu下限 k8s cpu limit_Pod_08


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

4种请求:每个容器必须设置内存请求(memory request),内存限额(memory limit),cpu请求(cpu request)和cpu限额(cpu limit)

资源会统计总的namespace中的资源加以限定,不管是之前创建还是准备创建

上述创建的ResourceQuota对象将在default名字空间中添加以下限制:

  • 所有容器的内存请求总额不得超过1 GiB。
  • 所有容器的内存限额总额不得超过2 GiB。
  • 所有容器的CPU请求总额不得超过1 CPU。
  • 所有容器的CPU限额总额不得超过2 CPU。

5. namespace中pod的配额

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
    pods: "2"

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

k8s nodes cpu下限 k8s cpu limit_重新启动_09

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

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

k8s nodes cpu下限 k8s cpu limit_Pod_10

k8s nodes cpu下限 k8s cpu limit_Pod_11