pod健康检查详解（liveness，readiness，滚动更新）

环境介绍

主机	IP地址	服务
master	192.168.1.21	k8s+httpd+nginx
node01	192.168.1.22	k8s
node02	192.168.1.23	k8s

基于[ http://www.javashuo.com/article/p-wzdhboob-dy.html]() 的实验继续进行

1、Pod的liveness和readiness探针

　　Kubelet使用liveness probe（存活探针）来肯定什么时候重启容器。例如，当应用程序处于运行状态但没法作进一步操做，liveness探针将捕获到deadlock，重启处于该状态下的容器，使应用程序在存在bug的状况下依然可以继续运行下去
　　Kubelet使用readiness probe（就绪探针）来肯定容器是否已经就绪能够接受流量。只有当Pod中的容器都处于就绪状态时kubelet才会认定该Pod处于就绪状态。该信号的做用是控制哪些Pod应该做为service的后端。若是Pod处于非就绪状态，那么它们将会被从service的load balancer中移除。

Probe支持如下三种检查方法：

<1>exec-命令

在用户容器内执行一次命令，若是命令执行的退出码为0，则认为应用程序正常运行，其余任务应用程序运行不正常。

livenessProbe:
    exec:
      command:
      - cat
      - /home/laizy/test/hostpath/healthy

<2>TCPSocket

将会尝试打开一个用户容器的Socket链接（就是IP地址：端口）。若是可以创建这条链接，则认为应用程序正常运行，不然认为应用程序运行不正常。

livenessProbe:
tcpSocket:
   port: 8080

<3>HTTPGet

调用容器内Web应用的web hook，若是返回的HTTP状态码在200和399之间，则认为应用程序正常运行，不然认为应用程序运行不正常。每进行一次HTTP健康检查都会访问一次指定的URL。

httpGet: #经过httpget检查健康，返回200-399之间，则认为容器正常
    path: / #URI地址
    port: 80 #端口号
    #host: 127.0.0.1 #主机地址
    scheme: HTTP #支持的协议，http或者https
  httpHeaders：’’ #自定义请求的header

参数说明

initialDelaySeconds：容器启动后第一次执行探测是须要等待多少秒。

periodSeconds：执行探测的频率。默认是10秒，最小1秒。

timeoutSeconds：探测超时时间。默认1秒，最小1秒。

successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是1。对于liveness必须是1。最小值是1。

探针探测的结果有如下三者之一：

Success：Container经过了检查。
Failure：Container未经过检查。
Unknown：未能执行检查，所以不采起任何措施。

1. LivenessProbe（活跃度）

（1）编写一个livenss的yaml文件

[root@node02 ~]# vim livenss.yaml
kind: Pod
apiVersion: v1
metadata:
  name: liveness
  labels:
    test: liveness
spec:
  restartPolicy: OnFailure
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/test; sleep 60; rm -rf /tmp/test; sleep 300
    livenessProbe:              #存活探测
      exec:                     #经过执行命令来检查服务是否正常
        command:                #命令模式
        - cat
        - /tmp/test
      initialDelaySeconds: 10    #pod运行10秒后开始探测
      periodSeconds: 5           #检查的频率，每5秒探测一次

该配置文件给Pod配置了一个容器。periodSeconds 规定kubelet要每隔5秒执行一次liveness probe。initialDelaySeconds 告诉kubelet在第一次执行probe以前要的等待10秒钟。探针检测命令是在容器中执行 cat /tmp/healthy 命令。若是命令执行成功，将返回0，kubelet就会认为该容器是活着的而且很健康。若是返回非0值，kubelet就会杀掉这个容器并重启它。

（2）运行一下

[root@master ~]# kubectl apply -f liveness.yaml

（3）查看一下

[root@master ~]# kubectl get pod -w

Liveness活跃度探测，根据探测某个文件是否存在，来肯定某个服务是否正常运行，若是存在则正常，负责，它会根据你设置的Pod的重启策略操做Pod。

2. Readiness（敏感探测、就绪性探测）

ReadinessProbe探针的使用场景livenessProbe稍有不一样，有的时候应用程序可能暂时没法接受请求，好比Pod已经Running了，可是容器内应用程序还没有启动成功，在这种状况下，若是没有ReadinessProbe，则Kubernetes认为它能够处理请求了，然而此时，咱们知道程序还没启动成功是不能接收用户请求的，因此不但愿kubernetes把请求调度给它，则使用ReadinessProbe探针。
ReadinessProbe和livenessProbe可使用相同探测方式，只是对Pod的处置方式不一样，ReadinessProbe是将Pod IP:Port从对应的EndPoint列表中删除，而livenessProbe则Kill容器并根据Pod的重启策略来决定做出对应的措施。
ReadinessProbe探针探测容器是否已准备就绪，若是未准备就绪则kubernetes不会将流量转发给此Pod。
ReadinessProbe探针与livenessProbe同样也支持exec、httpGet、TCP的探测方式，配置方式相同，只不过是将livenessProbe字段修改成ReadinessProbe。

（1）编写一个readiness的yaml文件

[root@master ~]# vim readiness.yaml 
kind: Pod
apiVersion: v1
metadata:
  name: readiness
  labels:
    test: readiness
spec:
  restartPolicy: Never
  containers:
  - name: readiness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/test; sleep 60; rm -rf /tmp/test; sleep 300
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/test
      initialDelaySeconds: 10
      periodSeconds: 5

（2）运行一下

[root@master ~]# kubectl apply -f readiness.yaml

（3）查看一下

[root@master ~]# kubectl get pod -w

3. 总结liveness和readiness探测

（1）liveness和readiness是两种健康检查机制，k8s将两种探测采起相同的默认行为，即经过判断容器启动进程的返回值是否为零，来判断探测是否成功。

（2）两种探测配置方法彻底同样，不一样之处在于探测失败后的行为。

​ liveness探测是根据重启策略操做容器，大多数是重启容器。

​ readiness则是将容器设置为不可用，不接收Service转发的请求。

（3）两种探测方法可建议独立存在，也能够同时存在。用livensess判断是否须要重启，实现自愈；用readiness判断容器是否已经准备好对外提供服务。

2、 检测的应用

1. 在scale(扩容/缩容) 中的应用。

（1）编写一个readiness的yaml文件

[root@master ~]# vim hcscal.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: web
spec:
  replicas: 3
  template: 
    metadata:
      labels:
        run: web
    spec:
      containers:
      - name: web
        image: httpd
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            scheme: HTTP   #探测的协议
            path: /healthy  #访问的目录
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 5

---
kind: Service
apiVersion: v1
metadata:
  name: web-svc
spec:
  type: NodePort
  selector:
    run: web
  ports:
  - protocol: TCP
    port: 90
    targetPort: 80
    nodePort: 30321

在配置文件中，使用httpd镜像，建立出一个Pod，其中periodSeconds字段指定kubelet每5秒执行一次探测，initialDelaySeconds字段告诉kubelet延迟等待10秒，探测方式为向容器中运行的服务发送HTTP GET请求，请求8080端口下的/healthz, 任何大于或等于200且小于400的代码表示成功。任何其余代码表示失败。

（2） httpGet探测方式有以下可选的控制字段

host：要链接的主机名，默认为Pod IP，能够在http request head中设置host头部。
scheme: 用于链接host的协议，默认为HTTP。
path：http服务器上的访问URI。
httpHeaders：自定义HTTP请求headers，HTTP容许重复headers。
port： 容器上要访问端口号或名称。

（3）运行一下

[root@master ~]# kubectl apply -f readiness.yaml

（4）查看一下

[root@master ~]# kubectl get pod -w

[root@master ~]# kubectl get pod -o wide

[root@master ~]# kubectl get service -o wide

（5）访问一下

[root@master ~]# curl  10.244.1.21/healthy

（6）pod在指定目录建立一个文件

[root@master ~]# kubectl exec web-69d659f974-7s9bc touch /usr/local/apache2/htdocs/healthy

（7）查看一下

[root@master ~]# kubectl get pod -w

2. 在更新过程当中的使用

（1）编写一个readiness的yaml文件

[root@master ~]# vim app.v1.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 10; touch /tmp/healthy; sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

（2）运行一下并记录版本信息

[root@master ~]# kubectl apply -f readiness.yaml --record

查看一下

[root@master ~]# kubectl rollout history deployment app

（3）查看一下

[root@master ~]# kubectl get pod -w

3.升级一下Deployment

（1）编写一个readiness的yaml文件

[root@master ~]# cp app.v1.yaml app.v2.yaml

[root@master ~]# vim app.v2.yaml 

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000        #修改命令
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

（2）运行一下并记录版本信息

[root@master ~]# kubectl apply -f readiness.yaml --record

查看一下

[root@master ~]# kubectl rollout history deployment app

（3）查看一下

[root@master ~]# kubectl get pod -w

（4）再次升级一下deployment

<1> 编写一个readiness的yaml文件

[root@master ~]# cp app.v1.yaml app.v3.yaml

[root@master ~]# vim app.v2.yaml 

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000        #修改命令

<2> 运行一下并记录版本信息

[root@master ~]# kubectl apply -f readiness.yaml --record

查看一下

[root@master ~]# kubectl rollout history deployment app

<3> 查看一下

[root@master ~]# kubectl get pod -w

4. 回滚v2版本

[root@master ~]# kubectl rollout undo deployment app --to-revision=2

查看一下

[root@master ~]# kubectl get pod

（1）编写一个readiness的yaml文件

[root@master ~]# vim app.v2.yaml 
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  strategy:
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 2
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

参数介绍

minReadySeconds:

Kubernetes在等待设置的时间后才进行升级
若是没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了
若是没有设置该值，在某些极端状况下可能会形成服务服务正常运行

maxSurge:

升级过程当中最多能够比原先设置多出的POD数量
例如：maxSurage=1，replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD，整个升级过程当中最多会有5+1个POD。

maxUnavaible:

升级过程当中最多有多少个POD处于没法提供服务的状态
当maxSurge不为0时，该值也不能为0
例如：maxUnavaible=1，则表示Kubernetes整个升级过程当中最多会有1个POD处于没法服务的状态。

（2） 运行一下并记录版本信息

[root@master ~]# kubectl apply -f app.v2.yaml --record

查看一下

[root@master ~]# kubectl rollout history deployment app

（3） 查看一下

[root@master ~]# kubectl get pod -w

3、小实验

1）写一个Deployment资源对象，要求2个副本，nginx镜像。使用Readiness探测，自定义文件/test是否存在，容器开启以后10秒开始探测，时间间隔为10秒。

（1）编写一个readiness的yaml文件

[root@master yaml]# vim nginx.yaml

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: web
spec:
  replicas: 2
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - name: readiness
        image: 192.168.1.21:5000/nginx:v1
        readinessProbe:
          exec:
            command:
            - cat
            - /usr/share/nginx/html/test
          initialDelaySeconds: 10
          periodSeconds: 10

（2）运行一下并记录版本信息

[root@master ~]# kubectl apply -f nginx.yaml --record

查看一下

[root@master ~]# kubectl rollout history deployment web

（3）查看一下

[root@master ~]# kubectl get pod -w

2）在运行以后两个Pod里，进入一个Pod，建立文件/test。

[root@master yaml]# kubectl exec -it web-864c7cf7fc-gpxq4  /bin/bash
root@web-68444bff8-xm22z:/# touch /usr/share/nginx/html/test

查看一下

[root@master yaml]# kubectl get pod -w

3）建立一个Service资源对象，跟上述Deployment进行关联，运行以后，查看Service资源详细信息，确认EndPoint负载均衡后端Pod。

（1）编写service的yaml文件

[root@master yaml]# vim nginx-svc.yaml
kind: Service
apiVersion: v1
metadata:
  name: web-svc
spec:
  type: NodePort
  selector:
    run: web
  ports:
  - protocol: TCP
    port: 90
    targetPort: 80
    nodePort: 30321

（2）执行一下

[root@master yaml]# kubectl apply -f nginx-svc.yaml

（3）给两个pod刚更改页面

查看一下pod

[root@master yaml]# kubectl get pod -o wide

更改页面

[root@master yaml]# kubectl exec -it  web-864c7cf7fc-gpxq4  /bin/bash
root@web-864c7cf7fc-gpxq4:/# echo "123">/usr/share/nginx/html/test
root@web-864c7cf7fc-gpxq4:/# exit

[root@master yaml]# kubectl exec -it  web-864c7cf7fc-pcrs9   /bin/bash
root@web-864c7cf7fc-pcrs9:/# echo "321">/usr/share/nginx/html/test
root@web-864c7cf7fc-pcrs9:/# exit

4）观察状态以后，尝试将另外一个Pod也写入/test文件，而后再去查看SVC对应的EndPoint的负载均衡状况。

（1）查看一下service

[root@master yaml]# kubectl get service

（2）访问一下

[root@master ~]# curl 192.168.1.21:30321/test

5）经过httpGet的探测方式，从新运行一下deployment资源，总结对比一下这两种Readiness探测方式。

（1）修改deployment的yaml文件

[root@master yaml]# vim nginx.yaml 
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: web
spec:
  replicas: 2
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - name: readiness
        image: 192.168.1.21:5000/nginx:v1
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /usr/share/nginx/html/test
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10

（2）执行一下

[root@master yaml]# kubectl apply -f nginx.yaml

（3）查看一下pod

[root@master yaml]# kubectl get pod -w

maxSurge：此参数控制滚动更新过程当中，副本总数超过预期数的值。能够是整数，也能够是百分比，默认是1。因此如今是3台pod

（4）访问一下

[root@master yaml]# curl 192.168.1.21:30321/test

6）总结对比liveness和readiness探测的相同和不一样之处，以及它们的使用场景。

<1>readiness和liveness的核心区别

实际上readiness 和liveness 就如同字面意思。readiness 就是意思是否能够访问，liveness就是是否存活。若是一个readiness 为fail 的后果是把这个pod 的全部service 的endpoint里面的改pod ip 删掉，意思就这个pod对应的全部service都不会把请求转到这pod来了。可是若是liveness 检查结果是fail就会直接kill container，固然若是你的restart policy 是always 会重启pod。

<2>什么样才叫readiness／liveness检测失败呢?

实际上k8s提供了3中检测手段，

http get 返回200-400算成功，别的算失败
tcp socket 你指定的tcp端口打开，好比能telnet 上
cmd exec 在容器中执行一个命令 推出返回0 算成功。
每中方式均可以定义在readiness 或者liveness 中。好比定义readiness 中http get 就是意思说若是我定义的这个path的http get 请求返回200-400之外的http code 就把我从全部有个人服务里面删了吧，若是定义在liveness里面就是把我kill 了。

<3>readiness和readiness的使用环境

好比若是一个http 服务你想一旦它访问有问题我就想重启容器。那你就定义个liveness 检测手段是http get。反之若是有问题我不想让它重启，只是想把它除名不要让请求到它这里来。就配置readiness。

注意，liveness不会重启pod，pod是否会重启由你的restart policy（重启策略）控制。

参考：
https://www.jianshu.com/p/16a375199cf2