所属技术领域：
pod
|名词定义|
Readiness 指针用来判断这个容器是否启动完成，即 pod 的 condition 是否 ready。如果探测的一个结果是不成功，那么此时它会从 pod 上 Endpoint 上移除，也就是说从接入层上面会把前一个 pod 进行摘除，直到下一次判断成功，这个 pod 才会再次挂到相应的 endpoint 之上。
|技术特点|
readinessprobe使用场景
Pod对象启动后，容器应用通常需要一段时间才能完成其初始化过程，例如加载配置或数据，甚至有些程序需要运行某类的预热过程，若在此阶段完成之前接入客户端的请求，势必会因为等待太久而影响用户体验，这时就需要就绪探针。
如果没有将就绪探针添加到pod中，它们几乎会立即成为服务端点。如果应用程序需要很长时间才能开始监听传入连接，则在服务启动但尚未准备好接收传入连接时，客户端请求将被转发到该pod。因此，客户端会看到"连接被拒绝"类型的错误。
机制
与存活探针机制相同，就绪探针也支持Exec、HTTP GET和TCP Socket三种探测方式，且各自的定义机制相同，将容器定义中的livenessProbe字段名替换为readinessProbe即可定义出就绪探测的配置，这里不再赘述。
创建readiness-exec.yaml
本文以exec方式为例实践
[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 readiness-exec.yaml
pod/readiness-exec created
查看Pod
[root@master ~]# kubectl get po readiness-exec -w
NAME 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状态。
与livenessprobe区别
如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据Pod的restartPolicy自动执行正确的操作。
如果您希望容器在探测失败时被杀死并重新启动，那么请指定一个存活探针，并指定restartPolicy为Always或OnFailure。
如果要仅在探测成功时才开始向 Pod 发送流量，请指定就绪探针。在这种情况下，就绪探针可能与存活探针相同，但是spec中的就绪探针的存在意味着Pod将在没有接收到任何流量的情况下启动，并且只有在探针探测成功后才开始接收流量。
两种探测的配置方法完全一样，支持的配置参数也一样，既可单独探测又可结合着者一起执行。
