Kubernetes之探针probe_修改pod的 livenessprobe

deployment只保证pod的状态为running。如果pod状态是running，但是里面丢失了文件，导致用户不能访问数据，则deployment是不管用的，此时就需要probe来检测pod是否正常工作。
probe是定义在容器里的，可以理解为容器里加的一个装置，来探测容器是不是正常工作，分为liveness probe和readiness probe。

liveness probe

liveness探测到某个pod运行有问题的话，就会通过重启pod来解决问题，重启即为把旧的pod删除，然后创建出来一个新的同名的pod。

command探测方式

该方式就是，在容器内部执行一条命令，如果这个命令的返回值为0，即命令正确执行了，则认为容器是正常的，如果返回值非0，则认为容器出现了问题，然后通过重启来解决问题。

• 创建liveness1.yaml文件并修改，修改后内容如下

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: liveness1
  name: liveness1
spec:
  terminationGracePeriodSeconds: 5
  containers:
  - image: busybox
    imagePullPolicy: IfNotPresent
    name: liveness1
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy;sleep 20;rm -rf /tmp/healthy;sleep 1000
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
      successThreshold: 1
      failureThreshold: 3
      timeoutSeconds: 10
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

pod启动后，会创建/tmp/healthy，20秒后删除它，然后等待1000秒之后终止。
定义了livenessProbe，探测/tmp/healthy是否存在。如果该文件不存在，命令执行失败，返回值为零，则认为容器出问题了。

参数：
initialDelaySeconds：pod启动多少秒内不探测
periodSeconds：探测间隔时间
successThreshold：探测失败后，最少连续探测多少次才被认定成功
failureThreshold：探测失败后连续探测次数。
设置了terminationGracePeriodSeconds为5秒，默认30秒删除等待时间太长不利于观察。

• 创建pod并查看pod的运行情况

kubectl apply -f liveness1.yaml
kubectl get pod
kubectl exec liveness1 -- ls /tmp/
1
2
3

pod创建后，可以看到文件夹，20s后看不到文件夹，探测三次后，pod在40s后自动重启，以此类推。

httpGet探测方式

该方式指的是HTTP协议的数据包能否通过指定端口访问到指定文件，如果能访问到，则认为容器是正常的，如果访问不到，则认为pod是不正常的。

• 创建liveness2.yaml文件，内容如下

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: liveness2
  name: liveness2
spec:
  terminationGracePeriodSeconds: 5
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: liveness2
    livenessProbe:
      successThreshold: 1
      failureThreshold: 3
      initialDelaySeconds: 5
      periodSeconds: 5
      httpGet:
        path: /index.html
        port: 80
        scheme: HTTP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

• 创建pod，并查看状态

kubectl apply -f liveness2.yaml
kubectl get pod
kubectl exec liveness2 -- ls /usr/share/nginx/html
# 删除文件进行测试
kubectl exec liveness2 -- rm /usr/share/nginx/html/index.html
kubectl get pod
kubectl exec liveness2 -- ls /usr/share/nginx/html
1
2
3
4
5
6
7

删除文件后，探测不到文件，pod重启，重启后，该文件存在。

tcpSocket探测方式

• 创建liveness3.yaml文件，内容如下

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: liveness3
  name: liveness3
spec:
  terminationGracePeriodSeconds: 5
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: liveness3
    livenessProbe:
      successThreshold: 1
      failureThreshold: 3
      initialDelaySeconds: 5
      periodSeconds: 5
      tcpSocket:
        port: 808
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

• 创建pod，并查看状态

kubectl apply -f liveness3.yaml
kubectl get pod
1
2

nginx默认使用的80端口，而我们探测是808，探测失败后，连续探测3次失败(15S)后重新启动pod，+5s删除时间，20秒后重启。

readiness probe

readiness探测和liveness探测类似，只是处理方式不一样。readiness探测到pod有问题之后并不会重启，只是service接收到请求后不再转发到此pod。

• 创建三个具有相同标签run=app的pod

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: app
  name: pod1
spec:
  containers:
  - name: c1
    image: nginx
    imagePullPolicy: IfNotPresent
    lifecycle:
      postStart:
        exec:
          command: ["/bin/bash","-c","touch /tmp/healthy"]
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

• 创建pod

kubectl apply -f readiness1.yaml
sed 's/pod1/pod2/' readiness1.yaml | kubectl apply -f -
sed 's/pod1/pod3/' readiness1.yaml | kubectl apply -f -
kubectl get pod --show-labels
1
2
3
4

• 修改每个pod默认页面

kubectl exec -ti pod1 -- bash
echo 111 > /usr/share/nginx/html/index.html
kubectl exec -ti pod2 -- bash
echo 222 > /usr/share/nginx/html/index.html
kubectl exec -ti pod3 -- bash
echo 333 > /usr/share/nginx/html/index.html
1
2
3
4
5
6

• 创建一个服务，并查看服务，过去IP

kubectl expose --name=readiness0 pod pod1 --port=80
kubectl get service
1
2

• 访问服务，由于三个pod标签相同，请求被负载均衡到三个pod。

curl 10.245.249.86
1

• 删除readiness3的测试文件，探测失败后pod3状态不再为ready

kubectl exec -it pod3 -- rm /tmp/healthy
kubectl exec -it pod3 -- ls /tmp
kubectl get pod
# 再次访问服务，已不再把请求转发给pod3了
curl 10.245.249.86
1
2
3
4
5

pod3状态是不健康的