Kubernetes——Pod就绪性探测

Pod就绪性探测

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

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

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

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

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

或者：

      livenessProbe:
        httpGet:
          path: /actuator/health
          port: 8293
          scheme: HTTP
        initialDelaySeconds: 60
        timeoutSeconds: 1
        periodSeconds: 5
        successThreshold: 1
        failureThreshold: 30
      startupProbe:
        httpGet:
          path: /actuator/health
          port: 8293
          scheme: HTTP
        initialDelaySeconds: 60
        timeoutSeconds: 1
        periodSeconds: 5
        successThreshold: 1
        failureThreshold: 30