k8s实践(五)：容器探针(liveness and readiness probe)

环境说明：

k8s集群部署详见：Centos7.6部署k8s(v1.14.2)集群

k8s学习资料详见：基本概念、kubectl命令和资料分享

一、为什么需要容器探针

如何保持Pod健康

  只要将pod调度到某个节点，Kubelet就会运行pod的容器，如果该pod的容器有一个或者所有的都终止运行(容器的主进程崩溃)，Kubelet将重启容器，所以即使应用程序本身没有做任何特殊的事，在Kubemetes中运行也能自动获得自我修复的能力。

  自动重启容器以保证应用的正常运行，这是使用Kubernetes的优势，不过在某些情况，即使进程没有崩溃，有时应用程序运行也会出错。默认情况下Kubernetes只是检查Pod容器是否正常运行，但容器正常运行并不一定代表应用健康，在以下两种情况下Kubernetes将不会重启容器：

​

• 1.访问Web服务器时显示500内部错误
• 该报错可能是系统超载，也可能是资源死锁，不过此时httpd进程依旧运行，重启容器可能是最直接有效的办法。
• 2.具有内存泄漏的Java应用程序将开始抛出OutOfMemoryErrors
• 此时JVM进程会一直运行，Kubernetes也不会重启容器，但此时对应用来讲是异常的。

此时可以考虑从外部检查应用程序的运行状况：

• Kubemetes可以通过存活探针(liveness probe)检查容器是否还在运行；
• 通过就绪探针(readiness probe)保证只有准备好了请求的Pod才能接收客户端请求。

二、LivenessProbe

1. 概念

  Kubemetes可以通过存活探针(liveness probe)检查容器是否还在运行。可以为pod中的每个容器单独指定存活探针。如果探测失败，Kubemetes将定期执行探针并重新启动容器。

Kubernetes 支持三种方式来执行探针：

• exec：在容器中执行一个命令，如果命令退出码返回0则表示探测成功，否则表示失败
• tcpSocket：对指定的容IP及端口执行一个TCP检查，如果端口是开放的则表示探测成功，否则表示失败
• httpGet：对指定的容器IP、端口及路径执行一个HTTP Get请求，如果返回的状态码在 [200,400)之间则表示探测成功，否则表示失败

2. exec探针

exec类型的探针通过在目标容器中执行由用户自定义的命令来判断容器的监控状态，若命令状态返回值为0则表示“成功”通过检测，其他值则均为“失败”状态。

2.1 创建liveness-exec.yaml

[root@master ~]# more liveness-exec.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness-exec 
  name: liveness-exec 
spec:
  restartPolicy: OnFailure
  containers:
  - name: liveness-exec 
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 600
    livenessProbe: 
      exec:
        command: ["test","-e","/tmp/healthy"]
      initialDelaySeconds: 5    #探测延时时长，第一次探测前等待5秒，默认为0
      periodSeconds: 5          #每5秒执行一次liveness探测,默认值10秒，最小1秒 
      timeoutSeconds: 2         #超长时长，默认为1s,最小值也为1s
      failureThreshold: 3       #处于成功状态时，探测操作至少连续多少次的失败才被视为检测不通过，默认为3，最小为1
[root@master ~]# kubectl apply -f liveness-exec.yaml 
pod/liveness-exec created

2.2 查看Pod

[root@master ~]# kubectl get po -o wide
[root@master ~]# kubectl describe po liveness-exec

pod运行正常，10秒内文件/tmp/healthy还存在，probe检测正常。

第15秒，probe再次检测，由于文件被删，检测失败，此后容器会进行多次重启操作。

3. HTTP探针

基于HTTP的探测(HTTPGetAction)向目标容器发起一个HTTP请求，根据其相应码进行结果判定，响应码如2xx或3xx时表示检测通过。

3.1 创建liveness-http.yaml

[root@master ~]# more liveness-http.yaml                   
apiVersion : v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness-http
    image: nginx
    ports:
    - name: http
      containerPort: 80
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh" ,"-c","echo liveness-http test > /usr/share/nginx/html/health"]
    livenessProbe:
      httpGet:
        path: /health
        port: http
        scheme: HTTP
[root@master ~]# kubectl apply -f liveness-http.yaml       
pod/liveness-http created

3.2 查看Pod

[root@master ~]# kubectl get po -o wide                                
NAME            READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES
liveness-http   1/1     Running   0          5s    10.244.2.206   node02   <none>           <none>
[root@master ~]# curl 10.244.2.206/health
liveness-http test

3.3 删除测试页面health

[root@master ~]# kubectl exec -it liveness-http rm  /usr/share/nginx/html/health  

探测失败，返回码404，重启容器。

4. TCP探针

基于TCP的存活性探测(TCPSocketAction)用于向容器的特定端口发起TCP请求并尝试建立连接，连接成功即为通过检测。

4.1 创建liveness-tcp.yaml

```bash

root@master ~# more liveness-tcp.yaml             

apiVersion: v1

kind: Pod

metadata:

  labels:

test: liveness

  name: liveness-tcp

spec:

  containers:

- name: liveness-tcp
    image: nginx
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      tcpSocket:
        port: http
root@master ~# kubectl apply -f liveness-tcp.yaml 
pod/liveness-tcp created
root@master ~# kubectl get po -o wideundefinedNAME           READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES
liveness-tcp   1/1     Running   0          4s    10.244.2.217   node02   <none>           <none>
root@master ~# curl 10.244.2.217:80![](https://ask.qcloudimg.com/http-save/yehe-6211241/klgg8ey8l8.png)

### 4.2 修改默认端口

```javascript

root@master ~# kubectl exec -it liveness-tcp -- sed -i 's/^ *listen 80/ listen 81/g' /etc/nginx/conf.d/default.conf如果kubectl exec在容器内执行命令时如果带参数则需加上'--'加载nginxroot@master ~# kubectl exec -it liveness-tcp -- nginx -s reload

apiVersion: v1

kind: Pod

metadata:

labels:

test: liveness-exec 

name: liveness-exec

spec:

restartPolicy: OnFailure

containers:

• name: liveness-exec image: busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: "test","-e","/tmp/healthy" initialDelaySeconds: 5 #探测延时时长，第一次探测前等待5秒，默认为0 periodSeconds: 5 #每5秒执行一次liveness探测,默认值10秒，最小1秒 timeoutSeconds: 2 #超长时长，默认为1s,最小值也为1s failureThreshold: 3 #处于成功状态时，探测操作至少连续多少次的失败才被视为检测不通过，默认为3，最小为1 root@master ~# kubectl apply -f readiness-exec.yaml pod/readiness-exec created5. 查看Podroot@master ~# kubectl get po readiness-exec -wundefinedNAME READY STATUS RESTARTS AGE readiness-exec 0/1 ContainerCreating 0 2s readiness-exec 0/1 Running 0 3s readiness-exec 1/1 Running 0 9s readiness-exec 0/1 Running 0 24s

'-w'选项可以监视pod资源变动，刚开始尽管pod处于Running状态，但知道就绪探测命令执行成功后pod资源才ready

刚开始处于'预热'阶段，pod为running状态但不可用；当10秒后（initialDelaySeconds + periodSeconds），readinessprobe开始第一次探测，成功后pod处于ready状态，45秒后（sleep30 + periodSeconds * failureThreshold）探测失败，pod再次为running但not ready状态。

6. 与livenessprobe区别

• 如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据Pod的restartPolicy自动执行正确的操作。
• 如果您希望容器在探测失败时被杀死并重新启动，那么请指定一个存活探针，并指定restartPolicy为Always或OnFailure。
• 如果要仅在探测成功时才开始向 Pod 发送流量，请指定就绪探针。在这种情况下，就绪探针可能与存活探针相同，但是spec中的就绪探针的存在意味着Pod将在没有接收到任何流量的情况下启动，并且只有在探针探测成功后才开始接收流量。
• 两种探测的配置方法完全一样，支持的配置参数也一样，既可单独探测又可结合者一起执行。

本文所有脚本和配置文件已上传github：https://github.com/loong576/k8s-liveness-and-readiness-probe.git