Kubernetes--Pod就绪性探测

小柔逃不掉
126 阅读3分钟

持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第29天，点击查看活动详情

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

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

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

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

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness-exec
  name: 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; do
ne"]
    readinessProbe:
      exec:
        command: ["test", "-e", "/tmp/ready"]
      initialDelaySeconds: 5
      periodSeconds: 5

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

kubectl create -f readiness-exec.yaml
pod/readiness-exec created

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

kubectl get  pods -l test=readiness-exec -w
NAME             READY   STATUS    RESTARTS   AGE
readiness-exec   0/1     Running   0          12s
readiness-exec   1/1     Running   0          41s

另外还可以从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资源中的容器定义就绪性探测机制。其探测机制的定义可以参考前三章Pod探针的定义。

avatar
文章
阅读
粉丝