在K8S中，Pod的LivenessProbe 探针的常见方式有哪些?

好的，我们来详细探讨一下 Kubernetes 中 Pod 的 Liveness Probe（存活探针）。

核心概念

Liveness Probe（存活探针） 的目的是判断容器是否正在“健康”地运行。如果探针检测失败，kubelet 会认为容器处于不健康状态（可能死锁、应用无响应），并根据 Pod 的 restartPolicy 策略重启容器。

这是一种非常重要的自我修复机制，确保您的应用在出现不可预见的内部错误时能够自动恢复。

Liveness Probe 的常见探测方式

Kubernetes 主要提供了三种方式来执行存活探测：

1. HTTP GET 探针 (HTTP Get)

这是最常用的一种方式，特别适用于返回 HTTP 响应的应用（如 Web 服务、REST APIs）。

工作原理：kubelet 会向容器内指定 IP、端口和路径发起一个 HTTP GET 请求。
判断成功与否：如果响应的状态码（HTTP Status Code）大于等于 200 且小于 400，则认为探测成功；否则视为失败。

配置示例：
检查 /healthz 路径，端口为 8080。

apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: my-web-app:latest
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:           # 使用 HTTP GET 方式
        path: /healthz   # 请求的路径
        port: 8080       # 请求的端口
        httpHeaders:     # 可选的自定义请求头
        - name: Custom-Header
          value: AwesomeValue
      initialDelaySeconds: 15  # 容器启动后等待15秒再开始探测
      periodSeconds: 10        # 每隔10秒探测一次
      timeoutSeconds: 1        # 探测超时时间，默认为1秒
      failureThreshold: 3      # 连续失败3次才认为最终失败
      successThreshold: 1      # 连续成功1次才认为最终成功（对于liveness必须是1）

2. Exec 探针 (命令行执行)

在容器内部执行一个指定的命令。

工作原理：kubelet 在容器中执行一条命令（例如 cat, curl, 或一个自定义脚本）。
判断成功与否：如果命令的退出状态码（exit code）为 0，则认为探测成功；任何非零状态码都视为失败。

配置示例：
检查容器内是否存在 /tmp/healthy 文件。如果该文件不存在，则 cat /tmp/healthy 命令会返回非零退出码，导致探测失败。

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busybox:latest
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:                   # 使用 Exec 方式
        command:             # 要执行的命令列表
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

3. TCP Socket 探针 (TCP 套接字)

尝试与容器建立一个 TCP 连接。

工作原理：kubelet 尝试与容器指定的端口建立 TCP 连接。
判断成功与否：如果连接能够成功建立，则认为探测成功；如果连接失败（如超时或拒绝连接），则视为失败。

配置示例：
检查容器的 8080 端口是否打开并可以建立连接。这种方式不关心端口上具体是什么应用（HTTP, Redis, MySQL等），只关心端口是否活跃。

apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp
spec:
  containers:
  - name: liveness
    image: my-app:latest
    ports:
    - containerPort: 8080
    livenessProbe:
      tcpSocket:        # 使用 TCP Socket 方式
        port: 8080      # 尝试连接的端口
      initialDelaySeconds: 15
      periodSeconds: 20

4. gRPC 探针 (适用于 gRPC 服务) - v1.24+ Beta

对于实现 gRPC 健康检查协议的服务，这是一种原生且更高效的探测方式。

工作原理：kubelet 使用 gRPC 客户端直接查询容器的 gRPC 健康状态。
判断成功与否：根据 gRPC 健康检查的响应状态（SERVING）来判断。

配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: liveness-grpc
spec:
  containers:
  - name: liveness
    image: my-grpc-app:latest
    ports:
    - containerPort: 9090
    livenessProbe:
      grpc:                 # 使用 gRPC 方式
        port: 9090          # gRPC 服务端口
        service: my-grpc-service # 可选的服务名，用于健康检查
      initialDelaySeconds: 10
      periodSeconds: 5

关键配置参数

所有类型的探针都共享以下重要参数：

参数	说明	默认值
`initialDelaySeconds`	容器启动后，等待多少秒才开始第一次探测。非常重要，必须给应用留出足够的启动时间，否则容器一启动就会被重启。	0
`periodSeconds`	执行探测的频率（每隔多少秒一次）。	10
`timeoutSeconds`	探测等待响应的超时时间。超过此时间则认为探测失败。	1
`successThreshold`	探测失败后，最少需要连续成功多少次才被认定为成功。对于 Liveness 必须是 1。	1
`failureThreshold`	探测失败后，Kubernetes 会重试多少次才最终放弃并重启容器。	3

总结与最佳实践

探测方式	适用场景	优点	缺点
HTTP GET	Web 服务、REST APIs	标准、通用，能检查应用内部状态	需要应用提供特定的健康检查端点
Exec	任何类型应用，无 HTTP 接口	非常灵活，可以通过任何命令/脚本检查	可能增加容器复杂度（需包含shell和工具）
TCP Socket	数据库（MySQL/Redis）、非HTTP服务	简单，不关心应用协议，只检查端口	无法检查应用逻辑是否真正健康
gRPC	gRPC 微服务	原生、高效，适合云原生微服务架构	需要应用实现 gRPC 健康检查协议

重要建议：

务必设置 initialDelaySeconds：这是最常见的配置错误。如果不设置，探针会在容器启动时立即开始，很可能在应用准备好之前就失败，导致容器无限重启。
检查逻辑要轻量：Liveness Probe 应该是一个快速、无副作用的检查，不应消耗大量资源或依赖外部服务（如数据库）。如果外部服务宕机导致检查失败，会触发所有Pod重启，引发雪崩效应。
定义专门的健康检查端点：对于 HTTP 探针，不要使用业务关键端点（如 /）。创建一个专用的、只进行基本状态检查的端点（如 /healthz）。
与 Readiness Probe 区分：Liveness Probe 用于判断是否需要重启容器以恢复问题。Readiness Probe 用于判断Pod是否准备好接收流量。两者通常配合使用。一个应用可能“未就绪”（不接受新流量）但仍然是“存活”的（不需要重启）。

posted @ 2025-08-23 09:03 天道酬勤zjh 阅读(26) 评论(0) 收藏举报

刷新页面返回顶部