存活探针(Liveness)、就绪探针(Readiness)、启动探针(Startup)、容器钩子

一、探针

1.1、探针类型

LivenessProbe

用于判断容器是否存活（running状态），如果LivenessProbe探针探测到容器不健康，则kubelet杀掉该容器，并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针，则kubelet认为该容器的LivenessProbe探针返回的值永远是“Success”。

ReadinessProbe

用于判断容器是否启动完成（ready状态），可以接收请求。如果ReadinessProbe探针检测到失败，则Pod的状态被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Endpoint。

StartupProbe

指示容器中的应用是否已经启动。如果提供了启动探针(startup probe)，则禁用所有其他探针，直到它成功为止。如果启动探针失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探针，则默认状态为成功Success。

1.2、探针动作

1) ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

livenessProbe:
  exec:
    command: ["cat /tmp/health"]
  initialDelaySeconds: 5
  periodSeconds: 5

2) TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。

livenessProbe:
  tcpSocket:
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 20

3) HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

livenessProbe:
  httpGet:
    # 当没有定义 "host" 时，使用 "PodIP"
    # host: my-host
    # 当没有定义 "scheme" 时，使用 "HTTP" scheme 只允许 "HTTP" 和 "HTTPS"
    # scheme: HTTPS
    path: /index.html
    port: 80
    httpHeaders:
    - name: X-Custom-Header
      value: Awesome
  initialDelaySeconds: 15
  timeoutSeconds: 1

1.3、探针配置

探针有很多配置字段，可以使用这些字段精确的控制存活和就绪检测的行为：

• initialDelaySeconds：容器启动后要等待多少秒后存活和就绪探测器才被初始化，默认是 0 秒，最小值是 0。
• periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
• timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
• successThreshold：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。存活探测的这个值必须是 1。最小值是 1。
• failureThreshold：当 Pod 启动了并且探测到失败，Kubernetes 的重试次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。

HTTP探针可以在 httpGet 上配置额外的字段：

• host：连接使用的主机名，默认是 Pod 的 IP。也可以在 HTTP 头中设置 “Host” 来代替。
• scheme：用于设置连接主机的方式（HTTP 还是 HTTPS）。默认是 HTTP。
• path：访问 HTTP 服务的路径。
• httpHeaders：请求中自定义的 HTTP 头。HTTP 头字段允许重复。
• port：访问容器的端口号或者端口名。如果数字必须在 1 ～ 65535 之间。

对于 HTTP 探测，kubelet 发送一个 HTTP 请求到指定的路径和端口来执行检测。除非 httpGet 中的 host 字段设置了，否则 kubelet 默认是给 Pod 的 IP 地址发送探测。如果 scheme 字段设置为了 HTTPS，kubelet 会跳过证书验证发送 HTTPS 请求。大多数情况下，不需要设置host 字段。这里有个需要设置 host 字段的场景，假设容器监听 127.0.0.1，并且 Pod 的 hostNetwork 字段设置为了 true。那么 httpGet 中的 host 字段应该设置为 127.0.0.1。可能更常见的情况是如果 Pod 依赖虚拟主机，你不应该设置 host 字段，而是应该在 httpHeaders 中设置 Host。

对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接，这意味着你不能在 host 参数上配置 service name，因为 kubelet 不能解析 service name。

1.4、实例

那么官方提供的三种探针我们该如何组合使用呢？

extra_args:
  feature-gates: StartupProbe=true

1) 首先，如果打算部署一个Java SpringBoot项目，我们假定他的项目启动时间为30秒左右，30秒后才能正常提供服务，那么我们就应该在这个时间段设置一个启动探针 StartupProbe。

startupProbe:
  httpGet:
    path: /doc.html
    port: 40017
  initialDelaySeconds: 10
  failureThreshold: 10
  periodSeconds: 5

该容器启动10秒后，startupProbe首先检测，应用程序最多有 50 秒（10次 * 5秒 = 50s）完成启动。一旦startupProbe成功一次，livenessProbe将接管，以对后续运行过程中容器死锁提供快速响应。如果startupProbe从未成功，则容器将在50s后被杀死。

2) 第二步加入就绪探针 ReadinessProbe 用来验证该容器内的服务可以正常提供服务。

readinessProbe:
  httpGet:
    path: /doc.html
    port: 40017
  initialDelaySeconds: 10
  failureThreshold: 3
  periodSeconds: 5

这里我们探测服务的40017端口是否启动监听。经过验证，加上readinessProbe探针基本将宕机时间大幅缩减，readinessProbe会确保服务在你指定的探测命令执行成功的情况下才开始接受请求。
即便是服务的副本数只有1的情况下也不会出现长时间宕机，因为只有新的pod被探活成功，才会去停止旧有的一个pod，也即我们的服务被成功启动前，旧有的pod会一直存在处理请求的。

3) 第三步加入存活探针 LivenessProbe 来对服务的长时间健康检测。

livenessProbe:
  httpGet:
    path: /doc.html
    port: 40017
  failureThreshold: 1
  periodSeconds: 10

livenessProbe的设计是为了在 pod 启动成功后进行健康探测。

二、钩子

2.1、钩子类型

PostStart

这个钩子在创建容器之后立即执行。 但是，不能保证钩子会在容器入口点之前执行。 没有参数传递给处理程序。

PreStop

在容器终止之前是否立即调用此钩子，取决于 API 的请求或者管理事件，类似活动探针故障、资源抢占、资源竞争等等。 如果容器已经完全处于终止或者完成状态，则对 preStop 钩子的调用将失败。 它是阻塞的，同时也是同步的，因此它必须在删除容器的调用之前完成。 没有参数传递给处理程序。

2.2、钩子动作

容器可以通过实现和注册该钩子的处理程序来访问该钩子。 针对容器，有两种类型的钩子处理程序可供实现：

• Exec - 执行一个特定的命令，在容器的 cgroups 和名称空间中。 命令所消耗的资源根据容器进行计算。

lifecycle:
  postStart:
    exec:
      command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
  preStop:
    exec:
      command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]

• HTTP - 对容器上的特定端点执行 HTTP 请求。

lifecycle:
  preStop:
    httpGet:
      path: /prestop
      port: 8080
      scheme: HTTP