跳转至

容器的健康检查

容器健康检查根据用户需求,检查容器的健康状况。配置后,容器内的应用程序入如果异常,容器会自动进行重启恢复。Kubernetes 提供了存活(Liveness)检查、就绪(Readiness)检查和启动(Startup)检查。

  • 存活检查(LivenessProbe) 可探测到应用死锁(应用程序在运行,但是无法继续执行后面的步骤)情况。 重启这种状态下的容器有助于提高应用的可用性,即使其中存在缺陷。

  • 就绪检查(ReadinessProbe) 可探知容器何时准备好接受请求流量,当一个 Pod 内的所有容器都就绪时,才能认为该 Pod 就绪。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 若 Pod 尚未就绪,会被从 Service 的负载均衡器中剔除。

  • 启动检查(StartupProbe) 可以了解应用容器何时启动,配置后,可控制容器在启动成功后再进行存活性和就绪态检查, 确保这些存活、就绪探测器不会影响应用的启动。 启动探测可以用于对慢启动容器进行存活性检测,避免它们在启动运行之前就被杀掉。

存活和就绪检查

存活检查(LivenessProbe)的配置和就绪检查(ReadinessProbe)的配置参数相似, 唯一区别是要使用 readinessProbe 字段,而不是 livenessProbe 字段。

HTTP GET 参数说明:

参数 参数说明
路径( Path) 访问的请求路径。如: 示例中的 /healthz 路径
端口(Port) 服务监听端口。 如: 示例中的 8080 端口
协议 访问协议,Http 或者Https
延迟时间(initialDelaySeconds) 延迟检查时间,单位为秒,此设置与业务程序正常启动时间相关。例如,设置为30,表明容器启动后30秒才开始健康检查,该时间是预留给业务程序启动的时间。
超时时间(timeoutSeconds) 超时时间,单位为秒。例如,设置为10,表明执行健康检查的超时等待时间为10秒,如果超过这个时间,本次健康检查就被视为失败。若设置为0或不设置,默认超时等待时间为1秒。
超时时间(timeoutSeconds) 超时时间,单位为秒。例如,设置为10,表明执行健康检查的超时等待时间为10秒,如果超过这个时间,本次健康检查就被视为失败。若设置为0或不设置,默认超时等待时间为1秒。
成功阈值(successThreshold) 探测失败后,被视为成功的最小连续成功数。默认值是 1,最小值是 1。存活和启动探测的这个值必须是 1。
最大失败次数(failureThreshold) 当探测失败时重试的次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。

使用 HTTP GET 请求检查

YAML 示例:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz  # 访问的请求路径
        port: 8080  # 服务监听端口
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3  # kubelet 在执行第一次探测前应该等待 3 秒
      periodSeconds: 3   #kubelet 每隔 3 秒执行一次存活探测

按照设定的规则,Kubelet 向容器内运行的服务(服务在监听 8080 端口)发送一个 HTTP GET 请求来执行探测。如果服务器上 /healthz 路径下的处理程序返回成功代码,则 kubelet 认为容器是健康存活的。 如果处理程序返回失败代码,则 kubelet 会杀死这个容器并将其重启。返回大于或等于 200 并且小于 400 的任何代码都标示成功,其它返回代码都标示失败。 容器存活期间的最开始 10 秒中, /healthz 处理程序返回 200 的状态码。 之后处理程序返回 500 的状态码。

使用 TCP 端口检查

TCP 端口参数说明:

参数 参数说明
端口(Port) 服务监听端口。 如: 示例中的 8080 端口
延迟时间(initialDelaySeconds) 延迟检查时间,单位为秒,此设置与业务程序正常启动时间相关。例如,设置为30,表明容器启动后30秒才开始健康检查,该时间是预留给业务程序启动的时间。
超时时间(timeoutSeconds) 超时时间,单位为秒。例如,设置为10,表明执行健康检查的超时等待时间为10秒,如果超过这个时间,本次健康检查就被视为失败。若设置为0或不设置,默认超时等待时间为1秒。

对于提供TCP通信服务的容器,基于此配置,按照设定规则集群对该容器建立TCP连接,如果连接成功,则证明探测成功,否则探测失败。选择TCP端口探测方式,必须指定容器监听的端口。

YAML 示例:

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

此示例同时使用就绪和存活探针。kubelet 在容器启动 5 秒后发送第一个就绪探测。 尝试连接 goproxy 容器的 8080 端口, 如果探测成功,这个 Pod 会被标记为就绪状态,kubelet 将继续每隔 10 秒运行一次检测。

除了就绪探测,这个配置包括了一个存活探测。 kubelet 会在容器启动 15 秒后进行第一次存活探测。 就绪探测会尝试连接 goproxy 容器的 8080 端口。 如果存活探测失败,容器会被重新启动。

执行命令检查

YAML 示例:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5 # kubelet 在执行第一次探测前等待 5 秒
      periodSeconds: 5  #kubelet 每 5 秒执行一次存活探测

periodSeconds 字段指定了 kubelet 每 5 秒执行一次存活探测, initialDelaySeconds 字段指定 kubelet 在执行第一次探测前等待 5 秒。按照设定规则,集群周期性的通过 kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0,kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值,kubelet 会杀死这个容器并重新启动它。

使用启动前检查保护慢启动容器

有些应用在启动时需要较长的初始化时间,需要使用相同的命令来设置启动探测,针对 HTTP 或 TCP 检测,可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对启动需要较长时间的场景。

YAML 示例:

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

如上设置,应用将有最多 5 分钟(30 * 10 = 300s)的时间来完成启动过程, 一旦启动探测成功,存活探测任务就会接管对容器的探测,对容器死锁作出快速响应。 如果启动探测一直没有成功,容器会在 300 秒后被杀死,并且根据 restartPolicy 来 执行进一步处置。

评论