干货!K8S之Pod资源控制+健康检查(探针)

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

  • 在容器中不一定需要创建虚拟硬件,是以进程的方式进行管理,共享宿主机内核资源
  • 在容器使用时,并没有对其硬件做出限制和瓶颈,出于安全考虑,需要对容器资源进行限制
  • 参考官方文档:参考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
##5757   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在使用时会产生访问流量,统计日志流量会有误差
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 像素格子 设计师: CSDN官方博客
应支付0元
点击重新获取
扫码支付

支付成功即可阅读