4.7 Pod 就绪性探测

Pod 对象启动后，容器应用通常需要一段时间才能完成其初始化过程，例如加载配置或数据，甚至有些程序需要运行某类预热过程，若在此阶段完成之前即接入客户端的请求，势必会因为等待太久而影响用户体验。因此，应该避免于 Pod 对象启动后立即让其处理客户端请求，而是等待容器初始化工作执行完成并转为“就绪”状态，尤其是存在其他提供相同服务的 Pod 对象的场景更是如此。

与存活性探测机制类似，就绪性探测使用来判断容器就绪与否的周期性（默认周期为10秒钟）操作，它用于探测容器是否已经初始化完成并可服务于客户端请求，探测操作返回“success”状态时，即为传递容器已经“就绪”的信号。

与存活性探测机制相同，就绪性探测也支持 Exec、HTTP GET和TCP Socket 三种探测方式，且各自的定义机制也都相同。但与存活性探测触发的操作不同的是，探测失败时，就绪性探测不会杀死或重启容器以保证其健康性，而是通知其尚未就绪，并触发依赖于其就绪状态的操作（例如，从 Service 对象中移除此 Pod 对象）以确保不会由客户端请求接入此 Pod 对象。不过，即便是在运行过程中，Pod 就绪性探测依然有其价值所在，例如 Pod A 依赖到的 Pod B 因网络故障等原因而不可用时，Pod A 上的服务应该转为未就绪状态，以免无法向客户端提供完整的响应。

将容器定义中的 livenessProbe 字段替换为 readlinessProbe 即可定义出就绪性探测的配置，一个简单的示例如下面的配置清单（readiness-exec.yaml）所示，它会在 Pod 对象创建完成 5 秒钟后使用 test -e /tmp/ready 命令来探测容器的就绪性，命令执行成功即为就绪，探测周期为5秒钟：

apiVersion: v1
kind: Pod
metadata:
  name: readiness-exec
  labels:
    test: readiness-exec
spec:
    containers:
    - name: readiness-demo
      image: busybox
      args: ["/bin/sh", "-c", "while true; do rm -f /tmp/ready; sleep 30; touch /tmp/ready; sleep 300; done"]
    readinessProbe:
      exec: 
        command: ["test", "-e", "/tmp/ready"]
      initialDelaySeconds: 5
      periodSeconds: 5

首先，使用“kubectl create”命令将资源配置清单定义的资源创建到集群中：

**[terminal]
**[delimiter $ ]**[command kubectl create -f readiness-exec.yaml]
pod/readiness-exec created

接着，运行“kubectl get -w”命令监视其资源变动信息，由如下命令结果可知，尽管Pod对象处于“Running”状态，但直到就绪探测命令执行成功后，Pod资源才转为“就绪” ：

**[terminal]
**[delimiter $ ]**[command kubectl get pods -l test=readiness-exec -w]
NAME             READY   STATUS    RESTARTS   AGE
readiness-exec   0/1     Running   0          25s
readiness-exec   1/1     Running   0          33s

另外，还可以从 Pod 对象的详细信息中得到类似如下的表示其已经处于就绪状态的信息片段：

Ready:          True
Restart Count:  0
Readiness:      exec [test -e /tmp/ready] delay=5s timeout=1s period=5s #success=1 #failure=3

这里需要特别提醒读者的是，未定义就绪性探测的Pod对象在Pod进入“Running”状态后将立即就绪，在容器需要时间进行初始化的场景中，在应用真正就绪之前必然无法正常响应客户端请求，因此，生产实践中，必须为关键性Pod资源中的容器定义就绪性探测机制。其探测机制的定义请参考4.6节中的定义。