OpenShift aPaaS v3失效的活动性探测与失效的就绪性探测

如果pod活跃度探测池中的探测失败，而pod就绪度探测池中的探测失败，会发生什么情况？

活跃度探测和就绪度探测之间没有什么区别。但其中一个主要区别是，准备就绪探测失败会将pod从池中移除，但不会重新启动。另一方面，发生故障的活动性探测器将pod从池中移除并重新启动pod

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness-vs-readiness
  name: liveness-vs-readiness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; touch /tmp/liveness; sleep 999999
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/liveness
      initialDelaySeconds: 5
      periodSeconds: 5
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

让我们创建这个pod并在操作中显示它：oc create-f liveness-vs-readiness.yaml

当我们在吊舱内执行操作时，输出吊舱状态。名称前面的数字与pod内执行的操作相关：

 oc get pods -w
NAME                         READY     STATUS    RESTARTS   AGE
[1] liveness-vs-readiness-exec   1/1       Running   0         44s
[2] liveness-vs-readiness-exec   0/1       Running   0         1m
[3] liveness-vs-readiness-exec   1/1       Running   0         2m
[4] liveness-vs-readiness-exec   0/1       Running   1         3m
    liveness-vs-readiness-exec   1/1       Running   1         3m

容器内的操作：

[root@default ~]# oc rsh liveness-vs-readiness-exec 
# [1] we rsh to the pod and do nothing. Pod is healthy and live
# [2] we remove health probe file and see that pod goes to notReady state
# rm /tmp/healthy 
# 
# [3] we create health file. Pod goes into ready state without restart
# touch /tmp/healthy
# 
# [4] we remove liveness file. Pod goes into notready state and is restarted just after that
# rm /tmp/liveness 
# command terminated with exit code 137