【最详细】Kubernetes探针介绍、应用与最佳实践

概述

Kubernetes（简称 k8s）中的探针（Probes）是用于检测容器健康状态的重要机制，它帮助 Kubernetes 决定何时将 Pod 加入服务流量、何时重启容器，以及何时从服务中剔除不可用的实例。

一、探针种类、方法与使用场景

1. 探针种类（Probe Types）

Kubernetes 提供了三种类型的探针：

(1) livenessProbe（存活探针）

• 作用：判断容器是否仍在运行。
• 行为：如果探针失败，kubelet 会杀死容器，并根据重启策略（restartPolicy）决定是否重启。
• 典型场景：应用陷入死锁、内存泄漏、无限循环等无法自行恢复的状态。

(2) readinessProbe（就绪探针）

• 作用：判断容器是否准备好接收流量。
• 行为：如果探针失败，Pod 的 IP 地址会从所有 Service 的 Endpoints中移除，即不再接收新请求。
• 典型场景：应用启动较慢（如加载大模型、连接数据库）、依赖外部服务未就绪等、应用短暂不可用时避免影响流量。

(3) startupProbe（启动探针，v1.16+ 引入）

• 作用：判断容器是否已成功启动。
• 行为：在 startupProbe 成功之前，liveness 和 readiness 探针不会执行。
• 典型场景：启动时间很长的应用（如 Java 应用、大型 ML 模型加载），避免因启动慢被误杀。

⚠️ 注意：三种探针可以同时配置，但 startupProbe 优先级最高，在其成功前其他探针不生效。

2. 探针检测方法（Handler Types）

每种探针都支持以下三种检测方式：

3. 探针关键参数

initialDelaySeconds:5# 容器启动后等待多少秒才开始探测periodSeconds:10# 探测间隔（秒）timeoutSeconds:5# 探测超时时间successThreshold:1# 连续成功多少次才算通过（liveness 必须为1）failureThreshold:3# 连续失败多少次才算失败

• 对于 livenessProbe，successThreshold 必须为 1。
• 对于 readinessProbe，可设为>1，用于容忍短暂失败。

二、探针使用案例

1. livenessProbe（存活探针）

livenessProbe:httpGet:path:/liveport:8080initialDelaySeconds:15# 容器启动后等待多少秒才开始探测periodSeconds:20# 探测间隔（秒）timeoutSeconds:5# 单次探测超时时间failureThreshold:3# 连续失败多少次才判定为“不存活”successThreshold:1# 成功阈值（liveness 必须为 1）

参数详解：

⚠️ 注意：

• liveness 接口必须轻量、只读、无外部依赖
• 避免在 liveness 中检查数据库、Redis、下游服务
• 合理设置failureThreshold：太小，网络抖动导致误杀；太大，故障恢复慢。
• 配合日志和监控

🔹 只关心“我还能不能活”，不关心“我能不能干活”。
🔹 失败 = 重启，所以必须谨慎设计失败条件。
🔹 它是最后的安全网，不是日常健康检查。

2. readinessProbe（就绪探针）

readinessProbe:httpGet:path:/readyport:8080initialDelaySeconds:5# 容器启动后延迟多少秒开始探测periodSeconds:10# 探测间隔（秒）timeoutSeconds:3# 单次探测超时时间failureThreshold:3# 连续失败多少次才判定为“未就绪”successThreshold:1# 连续成功多少次才算“就绪”（可 >1）

参数详解：

场景 ：数据库暂时不可用 → Pod 不接收流量

⚠️ 注意：

• 检查所有关键外部依赖：DB、Redis、Config Server、认证服务等。
• 使用短连接或连接池 ping：避免长期占用连接。
• 设置合理的 successThreshold（如 2）：防止因网络抖动频繁进出 Ready 状态。
• 配合 preStop hook 实现优雅下线：

lifecycle:preStop:exec:command:["/bin/sh","-c","sleep 10"]# 先 sleep，同时让 readiness 失败

• 监控 NotReady Pod 数量：通过 Prometheus 报警。

🔹 “能跑 ≠ 能干” —— Running 不等于 Ready。
🔹 流量开关由 readiness 控制，不是由容器是否启动决定。
🔹 它是服务网格、滚动更新、弹性伸缩的基石。

3. startupProbe（启动探针）

startupProbe:httpGet:path:/startupport:8080initialDelaySeconds:0# 容器启动后多久开始第一次探测（秒）periodSeconds:5# 探测间隔（秒）timeoutSeconds:2# 单次探测超时时间（秒）failureThreshold:10# 允许连续失败的最大次数

参数详解：

• 只要在这 60 秒内有一次探测成功，startupProbe 就算通过，之后 livenessProbe 和 readinessProbe才会开始工作。
• 如果 startupProbe 在其最大容忍时间（即 initialDelaySeconds + periodSeconds × failureThreshold）后仍然探测失败，Kubernetes 会认为容器“启动失败”，并按照 Pod 的重启策略（restartPolicy）进行处理——通常是杀死容器并重新创建（重启）

⚠️ 注意：

• startup 接口必须轻量：只检查“是否初始化完成”，不要连数据库。
• 合理设置容忍时间（留足余量），宁可多给，不要少给
• 所有启动时间 > 30 秒的应用都应配置 startupProbe。
• 不要在 startupProbe 中做 readiness 的事（如检查 DB），那是 readinessProbe 的职责。
• 监控 startupProbe 失败事件：可通过 Prometheus 抓取kube_pod_container_status_waiting_reason{reason=“CrashLoopBackOff”} 或事件日志。

🔹 startupProbe 成功前，liveness 和 readiness 不生效。
🔹 startup 接口只关心“我启好了没”，不关心“我能干活吗”。
🔹 宁可多给几秒，也不要让 Pod 死在黎明前。

三、探针接口设计最佳实践

下面从 三种探针的特性出发，系统性地阐述 健康检查接口的最佳实践设计方法。

1. 探针目标与接口职责对照表

2. 每种探针对应接口的设计最佳实践

Liveness Probe 接口（/live 或 /health/live）

✅ 应该做：

• 仅检查应用自身是否处于可运行状态：主线程未阻塞、内存未 OOM、无死锁
• 最好是一个纯内存操作，不涉及 I/O。
• 即使外部依赖（如 DB）宕机，只要应用本身还能运行（比如有重试队列），就应返回成功。
• Liveness 只对不可恢复错误返回失败（如死锁）。

❌ 不应该做：

• 连接数据库、调用外部 API。
• 因外部服务不可用而返回失败（这会导致不必要的重启）。

示例（最简形式）：

# 检查内部状态标志（如后台线程是否存活）：ifnotbackground_worker.is_alive():returnjsonify({"error":"worker dead"}),500

⚠️ 极简即可！甚至可以直接返回 200，因为如果进程挂了，根本不会响应。

Readiness Probe 接口（/ready 或 /health/ready）

✅ 应该做：

• 验证所有关键外部依赖是否可用：数据库连接池是否能获取连接、Redis 是否可 ping、下游微服务是否可达（谨慎使用）
• 返回 200 仅当所有依赖就绪，可安全接收流量。
• Readiness 对暂时不可用返回失败（如 DB 连接池满）。
• /ready 返回 200 但 body 是 {“ok”: false}，K8s 仍认为就绪（只看状态码）

❌ 不应该做：

• 检查非关键依赖（如日志服务、监控上报）。
• 执行写操作或修改状态。
• 因单点依赖失败导致整个应用不可用（可考虑降级逻辑）。

示例（最简形式）：

@app.route('/ready')defreadiness_check():try:# 检查数据库db.session.execute(text("SELECT 1"))# 检查 Redisredis_client.ping()returnjsonify({"status":"ready"}),200exceptExceptionase:app.logger.warning(f"Readiness check failed:{e}")returnjsonify({"error":"dependencies not ready"}),503

⚠️ 注意：避免在 readiness 中做“全链路健康检查”，否则容易引发级联故障。

Startup Probe 接口（/startup 或 /started）

✅ 应该做：

• 检查应用主进程是否已完全初始化（例如：模型加载完毕、配置解析完成）。
• 返回成功仅当内部初始化逻辑完成。
• 轻量、快速、无外部依赖。

❌ 不应该做：

• 连接数据库、调用外部服务。
• 执行耗时操作（如全表扫描）。

示例（最简形式）：

@app.route('/startup')defstartup_check():ifapp.config.get('INIT_DONE'):returnjsonify({"status":"started"}),200else:returnjsonify({"error":"still initializing"}),503

💡 提示：可在init或 before_first_request 中设置 INIT_DONE = True。

反面案例 vs 正确做法