【云原生|Kubernetes】07-Pod健康检查和服务可用性检查

【云原生|Kubernetes】07-Pod健康检查和服务可用性检查

前言

这篇文章介绍如何给容器配置存活（Liveness）、就绪（Readiness）和启动（Startup）探针。

Pod探针

Liveness(Pod存活探针)

• kubelet 使用存活探针来确定什么时候要重启容器。 例如，存活探针可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。 重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。
• 存活探针的常见模式是为就绪探针使用相同的低成本 HTTP 端点，但具有更高的 failureThreshold。 这样可以确保在硬性终止 Pod 之前，将观察到 Pod 在一段时间内处于非就绪状态。
• 用于判断容器是否存活（Running状 态），如果LivenessProbe探针探测到容器不健康，则kubelet将杀掉该容 器，并根据容器的重启策略做相应的处理。如果一个容器不包含 LivenessProbe探针，那么kubelet认为该容器的LivenessProbe探针返回的 值永远是Success。

Readiness(Pod服务就绪探针)

• kubelet 使用就绪探针可以知道容器何时准备好接受请求流量，当一个 Pod 内的所有容器都就绪时，才能认为该 Pod 就绪。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。
• 用于判断容器服务是否可用（Ready状 态），达到Ready状态的Pod才可以接收请求。对于被Service管理的 Pod，Service与Pod Endpoint的关联关系也将基于Pod是否Ready进行设 置。如果在运行过程中Ready状态变为False，则系统自动将其从Service 的后端Endpoint列表中隔离出去，后续再把恢复到Ready状态的Pod加回 后端Endpoint列表。这样就能保证客户端在访问Service时不会被转发到 服务不可用的Pod实例上。

Startup(启动探针)

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

定义Liveness存活探针

• Exec探针: Exec探针是一种通过在容器内部运行命令并检查其退出代码来检测容器是否处于活动状态的Liveness存活探针；
• http探针：HTTP存活探针是一种用于检测Web服务器是否处于活动状态的探针；
• TCP探针：TCP存活探针是一种用于检测TCP端口是否处于活动状态的探针；

EXec探针

1. 在这个配置文件中，可以看到 Pod 中只有一个 Container。 periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。 kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.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
      periodSeconds: 5

• periodSeconds : 指定了 kubelet 应该每 5 秒执行一次存活探测;
• initialDelaySeconds: 指定了kubelet 在执行第一次探测前应该等待 5 秒；
• timeoutSeconds: 探针执行超时时间，单位为秒。如果探针在指定的时间内没有返回结果，则认为探针失败。默认值为1;
• successThreshold: 探针成功的阈值。如果连续多少次探针成功，则认为容器处于活动状态。默认值为1;
• failureThreshold: 针失败的阈值。如果连续多少次探针失败，则认为容器不处于活动状态。默认值为3。

解析:

1. 当容器启动时，执行如下的命令:

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"

2. 这个容器生命的前 30 秒，/tmp/healthy 文件是存在的。 所以在这最开始的 30 秒内，执行命令 cat /tmp/healthy 会返回成功代码。 30 秒之后，执行命令 cat /tmp/healthy 就会返回失败代码。
3. 在 30 秒内，查看 Pod 的事件;输出结果表明还没有存活探针失败：

kubectl describe pod liveness-exec
ype    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  11s   default-scheduler  Successfully assigned default/liveness-exec to node01
  Normal  Pulling    9s    kubelet, node01    Pulling image "registry.k8s.io/busybox"
  Normal  Pulled     7s    kubelet, node01    Successfully pulled image "registry.k8s.io/busybox"
  Normal  Created    7s    kubelet, node01    Created container liveness
  Normal  Started    7s    kubelet, node01    Started container liveness

4. 35 秒之后，再来看 Pod 的事件;在输出结果的最下面，有信息显示存活探针失败了，这个失败的容器被杀死并且被重建了。

kubectl describe pod liveness-exec
Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  57s                default-scheduler  Successfully assigned default/liveness-exec to node01
  Normal   Pulling    55s                kubelet, node01    Pulling image "registry.k8s.io/busybox"
  Normal   Pulled     53s                kubelet, node01    Successfully pulled image "registry.k8s.io/busybox"
  Normal   Created    53s                kubelet, node01    Created container liveness
  Normal   Started    53s                kubelet, node01    Started container liveness
  Warning  Unhealthy  10s (x3 over 20s)  kubelet, node01    Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
  Normal   Killing    10s                kubelet, node01    Container liveness failed liveness probe, will be restarted

5. 再等 30 秒，确认这个容器被重启了;输出结果显示 RESTARTS 的值增加了 1。 请注意，一旦失败的容器恢复为运行状态，RESTARTS 计数器就会增加 1：

kubectl get pod liveness-exec
NAME            READY     STATUS    RESTARTS   AGE
liveness-exec   1/1       Running   1          1m

HTTP探针

1. 另外一种类型的存活探测方式是使用 HTTP GET 请求。 下面是一个 Pod 的配置文件，其中运行一个基于 registry.k8s.io/liveness 镜像的容器。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

• 在这个配置文件中，你可以看到 Pod 也只有一个容器。 periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。 kubelet 会向容器内运行的服务（服务在监听 8080 端口）发送一个 HTTP GET 请求来执行探测。 如果服务器上 /healthz 路径下的处理程序返回成功代码，则 kubelet 认为容器是健康存活的。 如果处理程序返回失败代码，则 kubelet 会杀死这个容器并将其重启。
• 返回大于或等于 200 并且小于 400 的任何代码都标示成功，其它返回代码都标示失败。

解析：

1. 可以访问 server.go 阅读服务的源码。 容器存活期间的最开始 10 秒中，/healthz 处理程序返回 200 的状态码。 之后处理程序返回 500 的状态码。

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    duration := time.Now().Sub(started)
    if duration.Seconds() > 10 {
        w.WriteHeader(500)
        w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
    } else {
        w.WriteHeader(200)
        w.Write([]byte("ok"))
    }
})

2. kubelet 在容器启动之后 3 秒开始执行健康检测。所以前几次健康检查都是成功的。 但是 10 秒之后，健康检查会失败，并且 kubelet 会杀死容器再重新启动容器。
3. 10 秒之后，通过查看 Pod 事件来确认存活探针已经失败，并且容器被重新启动了。

TCP探针

1. 第三种类型的存活探测是使用 TCP 套接字。 使用这种配置时，kubelet 会尝试在指定端口和容器建立套接字链接。 如果能建立连接，这个容器就被看作是健康的，如果不能则这个容器就被看作是有问题的。

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

• 如你所见，TCP 检测的配置和 HTTP 检测非常相似。 下面这个例子同时使用就绪和存活探针。kubelet 会在容器启动 5 秒后发送第一个就绪探针。 探针会尝试连接 goproxy 容器的 8080 端口。 如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次探测。
• 除了就绪探针，这个配置包括了一个存活探针。 kubelet 会在容器启动 15 秒后进行第一次存活探测。 与就绪探针类似，存活探针会尝试连接 goproxy 容器的 8080 端口。 如果存活探测失败，容器会被重新启动。

gRPC探针

• 特性状态：Kubernetes v1.24 [beta]

• 如果你的应用实现了 gRPC 健康检查协议， kubelet 可以配置为使用该协议来执行应用存活性检查。 你必须启用 GRPCContainerProbe 特性门控 才能配置依赖于 gRPC 的检查机制。

1. 这个例子展示了如何配置 Kubernetes 以将其用于应用程序的存活性检查。 类似地，你可以配置就绪探针和启动探针。

apiVersion: v1
kind: Pod
metadata:
  name: etcd-with-grpc
spec:
  containers:
  - name: etcd
    image: registry.k8s.io/etcd:3.5.1-0
    command: [ "/usr/local/bin/etcd", "--data-dir",  "/var/lib/etcd", "--listen-client-urls", "http://0.0.0.0:2379", "--advertise-client-urls", "http://127.0.0.1:2379", "--log-level", "debug"]
    ports:
    - containerPort: 2379
    livenessProbe:
      grpc:
        port: 2379
      initialDelaySeconds: 10

• 要使用 gRPC 探针，必须配置 port 属性。 如果要区分不同类型的探针和不同功能的探针，可以使用 service 字段。 你可以将 service 设置为 liveness，并使你的 gRPC 健康检查端点对该请求的响应与将 service 设置为 readiness 时不同。 这使你可以使用相同的端点进行不同类型的容器健康检查（而不需要在两个不同的端口上侦听）。 如果你想指定自己的自定义服务名称并指定探测类型，Kubernetes 项目建议你使用使用一个可以关联服务和探测类型的名称来命名。
• 与 HTTP 和 TCP 探针不同，gRPC 探测不能使用按名称指定端口， 也不能自定义主机名。

使用命名端口

• 对于 HTTP 和 TCP 存活检测可以使用命名的 port（gRPC 探针不支持使用命名端口）。

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

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port

定义startup启动探针

有时候，会有一些现有的应用在启动时需要较长的初始化时间。 要这种情况下，若要不影响对死锁作出快速响应的探测，设置存活探测参数是要技巧的。 技巧就是使用相同的命令来设置启动探测，针对 HTTP 或 TCP 检测，可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对糟糕情况下的启动时间。

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 来执行进一步处置。

定义Readiness就绪探针

• 有时候，应用会暂时性地无法为请求提供服务。 例如，应用在启动时可能需要加载大量的数据或配置文件，或是启动后要依赖等待外部服务。 在这种情况下，既不想杀死应用，也不想给它发送请求。 Kubernetes 提供了就绪探针来发现并缓解这些情况。 容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。
• 注意：
  • 就绪探针在容器的整个生命周期中保持运行状态；
  • 存活探针不等待就绪性探针成功。 如果要在执行存活探针之前等待，应该使用 initialDelaySeconds 或 startupProbe。
  • 就绪探针的配置和存活探针的配置相似。 唯一区别就是要使用 readinessProbe 字段，而不是 livenessProbe 字段。
• 就绪和存活探测可以在同一个容器上并行使用。 两者共同使用，可以确保流量不会发给还未就绪的容器，当这些探测失败时容器会被重新启动。

• LivenessProbe和ReadinessProbe均可配置以下三种实现方式。
  • EXec探针；
  • TCP探针
  • http探针

实现方式跟上面Liveness存活探针设置一样。

探针设置参数

全局参数

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

• initialDelaySeconds：容器启动后要等待多少秒后才启动启动、存活和就绪探针， 默认是 0 秒，最小值是 0。

• periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。

• timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。

• successThreshold：探针在失败后，被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。

• failureThreshold：探针连续失败了 failureThreshold 次之后， Kubernetes 认为总体上检查已失败：容器状态未就绪、不健康、不活跃。 对于启动探针或存活探针而言，如果至少有 failureThreshold 个探针已失败， Kubernetes 会将容器视为不健康并为这个特定的容器触发重启操作。 kubelet 会考虑该容器的 terminationGracePeriodSeconds 设置。 对于失败的就绪探针，kubelet 继续运行检查失败的容器，并继续运行更多探针； 因为检查失败，kubelet 将 Pod 的 Ready 状况设置为 false。

• terminationGracePeriodSeconds：为 kubelet 配置从为失败的容器触发终止操作到强制容器运行时停止该容器之前等待的宽限时长。 默认值是继承 Pod 级别的 terminationGracePeriodSeconds 值（如果不设置则为 30 秒），最小值为 1。

HTTP 探测参数

HTTP Probes允许针对 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。

• 针对 HTTP 探针，kubelet 除了必需的 Host 头部之外还发送两个请求头部字段： User-Agent 和 Accept。这些头部的默认值分别是 kube-probe/{{ skew currentVersion >}} （其中 1.27 是 kubelet 的版本号）和 */*。

你可以通过为探测设置 .httpHeaders 来重载默认的头部字段值；例如：

livenessProbe:
  httpGet:
    httpHeaders:
      - name: Accept
        value: application/json

startupProbe:
  httpGet:
    httpHeaders:
      - name: User-Agent
        value: MyUserAgent

也可以通过将这些头部字段定义为空值，从请求中去掉这些头部字段。

livenessProbe:
  httpGet:
    httpHeaders:
      - name: Accept
        value: ""

startupProbe:
  httpGet:
    httpHeaders:
      - name: User-Agent
        value: ""

TCP探针参数

对于 TCP 探测而言，kubelet 在节点上（不是在 Pod 里面）发起探测连接， 这意味着你不能在 host 参数上配置服务名称，因为 kubelet 不能解析服务名称。

TCP探针可以针对tcpSocket配置的字段进行配置。以下是可以在tcpSocket字段中使用的可选参数：

• host：要检测的TCP端口所在的主机。如果未指定该参数，则默认为Pod所在的主机。
• port：要检测的TCP端口号。
• sourceIPAddress：指定用于建立TCP连接的源IP地址。
• sourcePort：指定用于建立TCP连接的源端口。

livenessProbe:
  tcpSocket:
    host: my-host
    port: 8080
    sourceIPAddress: 10.0.0.1

探针层面的 terminationGracePeriodSeconds

• 在 1.21 发行版之前，Pod 层面的 terminationGracePeriodSeconds 被用来终止存活探测或启动探测失败的容器。 这一行为上的关联不是我们想要的，可能导致 Pod 层面设置了 terminationGracePeriodSeconds 时容器要花非常长的时间才能重新启动。
• 在 1.21 及更高版本中，用户可以指定一个探针层面的 terminationGracePeriodSeconds 作为探针规约的一部分。 当 Pod 层面和探针层面的 terminationGracePeriodSeconds 都已设置，kubelet 将使用探针层面设置的值。
• 探针层面的 terminationGracePeriodSeconds 不能用于就绪态探针。

什么是terminationGracePeriodSeconds

• 在Kubernetes中，terminationGracePeriodSeconds是一个用于控制Pod中容器终止行为的参数。当Pod中的一个容器被终止时，Kubernetes将等待一段时间来允许该容器完成尽可能多的工作，然后再强制终止该容器。terminationGracePeriodSeconds参数指定了Kubernetes要等待的时间长度，以秒为单位。

• 如果在terminationGracePeriodSeconds时间内，容器仍未终止，则Kubernetes将发送SIGKILL信号来强制终止该容器，并释放该容器持有的所有资源。

• 在探测器（livenessProbe、readinessProbe等）的情况下，如果容器在执行探测器时失败，则Kubernetes会杀死该容器，并在terminationGracePeriodSeconds时间后尝试重新启动该容器。如果容器在探测器超时之前重新启动，则可以避免在探测器失败时终止该容器。

• 在探针层面添加terminationGracePeriodSeconds参数，可以确保在探测器失败时，Kubernetes等待一段时间来允许容器完成尽可能多的工作，以确保系统的可靠性。例如，如果在容器的livenessProbe中指定了一个较长的检测周期，那么在检测失败时，Kubernetes将等待一段时间，以便容器可以完成尽可能多的工作，然后再强制终止该容器。

示例：

1. 在这个示例中，Pod的terminationGracePeriodSeconds参数被设置为3600秒，但是在容器的livenessProbe中，被重载为60秒。

2. 此外，在该示例中，容器test中的端口被设置为8080，并且在livenessProbe中使用了HTTP探测器来检查容器的健康状况。如果HTTP探测器在60秒内无法访问/healthz路径，则认为容器处于不健康状态，将触发重启操作。

3. 需要注意的是，在livenessProbe中再次设置terminationGracePeriodSeconds参数，将覆盖Pod级别的terminationGracePeriodSeconds参数，即容器将使用livenessProbe中设置的terminationGracePeriodSeconds参数。该示例中，容器的terminationGracePeriodSeconds参数被设置为60秒，这意味着如果容器在60秒内未能正常终止，则Kubernetes将发送SIGKILL信号来强制终止容器，并释放容器持有的所有资源。

   通过在Pod和容器级别设置terminationGracePeriodSeconds参数，可以确保Pod和容器在终止时能够完成尽可能多的工作，并避免数据丢失或其他不良影响。在实际应用中，可以根据不同的需求，适当调整terminationGracePeriodSeconds参数的值，以确保系统的稳定性和可靠性。

spec:
  terminationGracePeriodSeconds: 3600  # Pod 级别设置
  containers:
  - name: test
    image: ...

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

    livenessProbe:
      httpGet:
        path: /healthz
        port: liveness-port
      failureThreshold: 1
      periodSeconds: 60
      # 重载 Pod 级别的 terminationGracePeriodSeconds
      terminationGracePeriodSeconds: 60

额外说明

从 Kubernetes 1.25 开始，默认启用 ProbeTerminationGracePeriod 特性。 选择禁用此特性的用户，请注意以下事项:

• ProbeTerminationGracePeriod 特性门控只能用在 API 服务器上。 kubelet 始终优先选用探针级别 terminationGracePeriodSeconds 字段 （如果它存在于 Pod 上）。

• 如果你已经为现有 Pod 设置了 terminationGracePeriodSeconds 字段并且不再希望使用针对每个探针的终止宽限期，则必须删除现有的这类 Pod。

• 当你（或控制平面或某些其他组件）创建替换 Pod，并且特性门控 ProbeTerminationGracePeriod 被禁用时，即使 Pod 或 Pod 模板指定了 terminationGracePeriodSeconds 字段， API 服务器也会忽略探针级别的 terminationGracePeriodSeconds 字段设置。
  nGracePeriod` 特性。 选择禁用此特性的用户，请注意以下事项:

• ProbeTerminationGracePeriod 特性门控只能用在 API 服务器上。 kubelet 始终优先选用探针级别 terminationGracePeriodSeconds 字段 （如果它存在于 Pod 上）。

• 如果你已经为现有 Pod 设置了 terminationGracePeriodSeconds 字段并且不再希望使用针对每个探针的终止宽限期，则必须删除现有的这类 Pod。

• 当你（或控制平面或某些其他组件）创建替换 Pod，并且特性门控 ProbeTerminationGracePeriod 被禁用时，即使 Pod 或 Pod 模板指定了 terminationGracePeriodSeconds 字段， API 服务器也会忽略探针级别的 terminationGracePeriodSeconds 字段设置。