Kubernetes学习之资源限额

一、资源需求与限制
　　在Kubernetes上，可由容器或Pod请求或消费的"计算资源"是指CPU和内存（RAM），这也是目前仅有的受支持的两种类型。相比较来说，CPU属于可压缩（compressible）型资源，即资源的使用额度可按需收缩，而内存（当前）则是不可压缩性资源，对其执行收缩操作可能会导致某种程度的问题。
　　目前来说，资源隔离尚且属于容器级别的，CPU和内存资源的配置需要在Pod中的容器上进行，每种资源均可由"requests"属性定义其请求的确保可用值，即容器运行可能用不到这些额度的资源，但是用到时必须要确保有如此多的资源可用，而"limits"属性则用于限制资源可用的最大值，即硬限制。不过，为了表述方便，人们通常仍然把资源配置称作Pod资源的请求和限制，只不过它是指Pod内所有容器上某种类型资源的请求和限制的总和。

　　在Kubernetes系统上，1个单位的CPU相当于虚拟机上的1颗虚拟CPU（vCPU）或物理机上的一个超线程（Hyperthread，或称为一个逻辑CPU），它支持分数计量方式，一个核心（1 core）相当于1000个微核心（millicores），因此500m相当于0.5个核心，即二分之一个核心。内存的计量方式与日常使用方式相同，默认的单位是字节，也可以使用E、P、T、G、M和K作为单位后缀，或Ei、Pi、Ti、Gi、Mi和Ki形式的单位后缀。
　　对于压缩性的资源来说，未定义其请求量以确保其最小可用资源时，它可能会被其他的Pod资源压缩至极低的水平，甚至会达到Pod不能够被调度运行的境地。而对于非压缩型资源来说，内存资源在任何原因导致的紧缺情形下都有可能导致相关进程被杀死。因此，在Kubernetes系统上运行关键性业务相关的Pod时必须使用requests属性为容器定义资源确保可用量。
　　集群中的每个节点都拥有定量的CPU和内存资源，调度Pod时，仅那些被请求资源的余量可容纳当前被调度的Pod的请求量的节点才可作为目标节点。也就是说，Kubernetes的调度器会根据容器的requests属性中定义的资源需求量来判定仅哪些节点可接收运行相关的Pod资源，而对于一个节点的资源来说，每运行一个Pod对象，其requests中定义的请求量都要被预留，直到被所有Pod对象瓜分完毕为止。
　　容器的资源需求仅能达到为其保证可用的最少资源量的目的，它并不会限制容器的可用资源上限，因此对应用程序自身存在Bug等多种原因而导致的系统资源被长时间占用的情况则无计可施，这就需要通过limits属性为容器定义资源的最大可用量。资源分配时，可压缩型资源CPU的控制阈值可自由调节，容器进程无法获得超出其CPU配额的可用时间。不过，如果进程申请分配超出其limits属性定义的硬限制的内存资源时，它将被OOM killer杀死，不过随后可能会被其控制进程所重启，例如，容器进程的Pod对象会被杀死并重启（重启策略为Always或OnFailure时），或者是容器进程的子进程被父进程所重启。

二、资源限制实验

1）编写创建Pod与定义资源限制的yaml文件

]# cat resource_limits.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: memleak
  labels:
    app: memleak
spec:
  containers:
  - name: simmemleak
    image: saadali/simmemleak
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        memory: "64Mi"
        cpu: "1"
      limits:
        memory: "64Mi"
        cpu: "1"

]# kubectl apply -f resource_limits.yaml 
pod/memleak created

2）查看Pod资源信息

]# kubectl get pod -o wide 
NAME      READY   STATUS             RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
memleak   0/1     CrashLoopBackOff   1          10s   10.244.0.97   master   <none>           <none>

]# kubectl describe pods memleak
Name:         memleak
Namespace:    default
Priority:     0
Node:         master/172.16.2.200
Start Time:   Fri, 18 Sep 2020 09:49:00 +0800
Labels:       app=memleak
Annotations:  Status:  Running
IP:           10.244.0.97
IPs:
  IP:  10.244.0.97
Containers:
  simmemleak:
    Container ID:   docker://4de663358d0ff68a11b81a31a6f39dd526135b8e5d825e4ca28f745e2b63ad24
    Image:          saadali/simmemleak
    Image ID:       docker-pullable://saadali/simmemleak@sha256:5cf58299a7698b0c9779acfed15c8e488314fcb80944550eab5992cdf3193054
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Fri, 18 Sep 2020 09:49:50 +0800
      Finished:     Fri, 18 Sep 2020 09:49:50 +0800
    Ready:          False
    Restart Count:  3
    Limits:
      cpu:     1
      memory:  64Mi
    Requests:
      cpu:        1
      memory:     64Mi
    Environment: