一、为什么要进行容器资源限制

• 在容器中不一定需要创建虚拟硬件，是以进程的方式进行管理，共享宿主机内核资源
• 在容器使用时，并没有对其硬件做出限制和瓶颈，出于安全考虑，需要对容器资源进行限制
• 参考官方文档：参考K8S官方文档，点此跳～～～

二、pod的资源控制

• 在Docker中，主要是利用linux内核提供的Cgroup机制来管理CPU、内存和blkio
• 在k8s中可以在yaml中对其进行限制：

Pod的每个容器可以指定以下一项或多项：

'//resources表示资源限制字段'
'//requests表示基本资源'
'//limits表示资源上限，即这个pod最大能用到多少资源'

spec.containers[].resources.limits.cpu	'//CPU上限'
spec.containers[].resources.limits.memory	'//内存上限'
spec.containers[].resources.requests.cpu	'//创建时分配的基本CPU资源'
spec.containers[].resources.requests.memory	'//创建时分配的基本内存资源'
注意：requests<=limits  
尽管只能在单个容器上指定请求和限制，但是谈论Pod资源请求和限制很方便。特定资源类型的 Pod资源请求/限制是Pod中每个Container的该类型资源请求/限制的总和。

示例：

以下Pod具有两个容器。每个容器都有0.25 cpu的请求和64MiB的内存。每个容器的限制为0.5 cpu和128MiB的内存。即该pod限制cpu为1个核心数，内存为256MiB。

[root@k8s_master ~]# vim pod1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
 - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:                       ##资源控制
      requests:
        memory: "64Mi"         
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
 - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

• 执行创建，并查看资源限制情况

##创建2个容器
[root@k8s_master ~]# kubectl apply -f pod1.yaml 

##查看容器分配到哪个节点
[root@k8s_master ~]# kubectl get pods -o wide
NAME       READY   STATUS             RESTARTS   AGE    IP            NODE           NOMINATED NODE
frontend   1/2     CrashLoopBackOff   5          8m7s   172.17.50.3   192.168.5.20   <none>

##查看资源限制
[root@k8s_master ~]# kubectl describe nodes 192.168.5.20

三、pod重启策略

• Always：当容器终止退出后，总是重启容器，默认策略
• OnFailure：当容器异常退出（退出状态码非0）时，重启容器
• Never：当容器终止退出，从不重启容器。
• （注意：k8s中不支持重启Pod资源，只有删除重建）

查看pod资源的重启策略：

使用kubectl edit 命令可以输出其资源的yaml文件，查看重启策略restartPolicy。

[root@k8s_master ~]# kubectl edit pod frontend
##57行
    57   restartPolicy: Always

四、pod健康检查又称为探针（Probe）

当后端pod资源出现问题时，采用一系列策略对其进行操作

4.1、两种策略：

• livenessProbe: 如果检查失败，将杀死容器，根据Pod的restartPolicy来操作。
• ReadinessProbe :如果检查失败，kubernetes会把Pod从service endpoints中剔除。
  （注意：）规则可以同时定义

4.2、Probe支持三种检查方法：

• httpGet: 发送http请求，返回200-400范围状态码为成功。
• exec: 执行Shell命令返回状态码是0为成功。
• tcpSocket: 发起TCP Socket建立成功

参考官方文档：参考K8S官方文档，点此跳～～～～～～～～～

示例1：exec方式

• 创建一个pod资源，在配置文件中，您可以看到Pod具有单个Container。
• 该periodSeconds字段指定kubelet应该每5秒执行一次活动性探测。该initialDelaySeconds字段告诉kubelet在执行第一个探测之前应等待5秒钟。为了执行探测，kubelet cat /tmp/healthy在目标容器中执行命令
• 如果命令成功执行，则返回0，并且kubelet认为该容器处于活动状态且健康。如果命令返回非零值，则kubelet将杀死容器并重新启动它。

##创建pod资源，定义yaml文件
[root@k8s_master ~]# vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
 - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
 ##生成资源
 [root@k8s_master ~]# kubectl apply -f pod2.yaml     

• 容器启动时，它将执行以下命令

/bin/bash -c touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy

• 查看liveness-exec资源状态，显然根据策略重启了5次

[root@k8s_master ~]# kubectl get pods 
NAME            READY   STATUS             RESTARTS   AGE
liveness-exec   0/1     CrashLoopBackOff   5          8m16s

示例2：httpGet方式

• 在配置文件中，您可以看到Pod具有单个容器。
• 该periodSeconds字段指定kubelet应该每3秒执行一次活动性探测。该initialDelaySeconds字段告诉kubelet在执行第一个探测之前应等待3秒。
• 为了执行探测，kubelet将HTTP GET请求发送到在容器中运行并正在侦听端口8080的服务器。
• 如果服务器/healthz路径的处理程序返回成功代码，则kubelet会认为该容器处于活动状态并且运行状况良好。
• 如果处理程序返回失败代码，则kubelet将杀死容器并重新启动它。
• 任何大于或等于200且小于400的代码均表示成功。其他任何代码均指示失败。
• 在容器/healthz处于活动状态的前10秒钟中，处理程序返回状态200。此后，处理程序返回状态500。
  
• 容器启动后三秒钟，kubelet将开始执行运行状况检查。因此，前几次健康检查将成功。
• 但是10秒钟后，运行状况检查将失败，并且kubelet将终止并重新启动容器

示例3：tcpSocket方式

• 第三种类型的活动性探针使用TCP套接字。

• 使用此配置，kubelet将尝试在指定端口上打开容器的套接字。

• 如果可以建立连接，则认为该容器运行状况良好，如果不能建立连接，则视为故障。
  

• 如您所见，TCP检查的配置与HTTP检查非常相似。此示例同时使用了就绪和活跃度探针

• 容器启动后5秒钟内，kubelet将发送第一个就绪探测器。这将尝试连接到goproxy端口8080上的容器。

• 如果探测成功，则Pod将标记为就绪。kubelet将继续每10秒运行一次此检查。

• 除了就绪探针之外，此配置还包括活动探针。容器启动后15秒钟，kubelet将运行第一个活动探针

• 就像就绪探针一样，这将尝试goproxy在端口8080上连接到 容器。如果活动探针失败，则将重新启动容器。

4.3、探针使用总结

• 在现网中esec方式用的多但是占资源
• tcpsocket和http在使用时会产生访问流量，统计日志流量会有误差