探针失败后，Kubernetes到底会发生什么?

一句话总览（需要记住）

探针失败后，由 kubelet 根据探针类型采取不同动作：
readiness影响流量，liveness触发重启，startup决定是否启用前两者。

三个探针，各自“失败会发生什么”

1️⃣ Readiness Probe（就绪探针）——不杀进程，只停流量

失败后发生的事：

  • kubelet 将 Pod 标记为 NotReady
  • 对应 Endpoint 从 Service 中移除
  • 流量不再转发到该 Pod
  • 容器 不会被重启

适用场景：

  • 启动慢
  • 依赖外部服务（DB / MQ）
  • 临时过载

👉 这是“保护用户”的探针

2️⃣ Liveness Probe（存活探针）——失败就重启容器

失败后发生的事：

  • kubelet 判定容器“卡死/异常”
  • 直接杀掉容器
  • 按重启策略 重新拉起容器
  • Pod IP 通常不变（容器级重启）

风险点（非常重要）：

  • 如果配置不当：

    • 启动慢 = 被反复杀
    • 形成 CrashLoopBackOff

👉 这是“自愈机制”，但配置错了就是自杀机制

3️⃣ Startup Probe（启动探针）——给“慢启动”兜底

失败后发生的事：

  • 在 startup probe 成功之前：

    • liveness / readiness 都不会生效

  • 如果 startup probe 最终失败：

    • kubelet 会杀容器并重启

适用场景：

  • Java 应用
  • 初始化时间长
  • 冷启动慢的服务

👉 这是防止“启动阶段被 liveness 误杀”

完整时间线（必知必会）

Pod 启动
  ↓
Startup Probe（通过？）
  ↓ 是
Readiness Probe（是否接流量）
  ↓
Liveness Probe（是否该重启）

顺序记忆口诀：

先启动 → 再接流量 → 最后谈生死

kubelet 在这里扮演什么角色？（面试官很爱问）

  • 探针 不是 controller 做的

  • 全部由 kubelet 在 Node 本地执行

  • kubelet：

    • 定期执行探针
    • 根据结果更新 Pod 状态
    • 决定是否杀容器

👉 这是 Node 级行为，不是集群级调度

常见“踩坑场景”（生产必懂）

❌ 只配 liveness，不配 readiness

  • 服务慢了 → 被重启
  • 实际只需要“暂时下线”

❌ liveness 检查业务接口

  • 依赖 DB / Redis
  • 外部抖动 → Pod 被误杀

❌ 没有 startup probe

  • 启动慢
  • 还没 ready 就被杀

准生产级配置原则

Readiness 用来挡流量
Liveness 用来救卡死
Startup 用来保启动

面试回答参考（可以直接用）

“探针由 kubelet 执行。
readiness 失败会将 Pod 从 Service Endpoint 中移除，不会重启容器；
liveness 失败会触发 kubelet 重启容器；
startup probe 用于慢启动场景，在其成功前会屏蔽前两者，防止误判。”

说完这段，至少90% 面试官会表示满意。

拓展：为什么生产环境不能随便配置 liveness probe？

一句话概括

生产环境不能随意配置 liveness probe，因为它具有“杀进程”的强副作用；
必须结合 startup probe 使用，否则在应用启动慢、初始化重、依赖外部资源时，极易触发 CrashLoopBackOff，造成“自杀式重启”。

三种探针的行为差异（理解探针的核心）：

探针类型 失败后会发生什么 影响级别
livenessProbe kubelet 直接杀掉容器，并重启 ❌ 最激进
readinessProbe Pod 被标记为 NotReady，从 Service Endpoints 移除 ⚠️ 不杀进程
startupProbe 在成功前 暂停 liveness / readiness 🛡️ 保护启动期

👉 只有 liveness probe 会杀容器

“启动慢被误杀”是怎么发生的？

典型生产环境事故链路如下：

  1. 应用启动：

    • JVM / Python / Node.js
    • 初始化配置
    • 连数据库 / MQ / ES / Redis

  2. 端口已监听，但服务还不可用

  3. liveness probe 开始探测

  4. 探测失败（超时 / 500）

  5. kubelet 判定：

    “这个容器不健康”

  6. kill 容器

  7. 重启 → 再失败 → 再 kill

  8. 进入 CrashLoopBackOff

⚠️ 这不是 bug，是 kubelet 在“按预先配置的规则正确执行”

为什么说：生产环境“不能随便”用 liveness probe

1️⃣ liveness 的设计初衷不是“判断服务是否可用”

它解决的是这一类问题：

  • 死锁（deadlock）
  • 线程卡死
  • 进程还在，但永远不再对外响应

也就是说：

liveness 是“救火用的最后手段”，不是日常健康检查

2️⃣ 真实生产环境里，“慢 ≠ 死”

现实情况包括：

  • 数据库冷启动
  • 外部依赖波动
  • 大对象缓存加载
  • leader election
  • schema migration

这些情况：

  • readiness 应该失败
  • liveness 不应该失败

startup probe 的“生产级意义”

就绪探针结合启动探针使用，防止部分应用因为启动慢被误杀

这是官方推荐模式（k8s官方有yaml案例），也是大厂通用做法。

正确组合方式（准生产环境模板）

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10   # 最多允许 5 分钟启动

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5

运行机制：

  • 启动阶段：只看 startup

  • 启动完成前：

    • liveness / readiness 全部不生效

  • 启动成功后：

    • liveness 负责“是否该重启”
    • readiness 负责“是否接流量”

生产环境的探针设计原则（记住这 4 条）

✅ 原则 1：先 readiness，后 liveness

80% 的服务，只配 readiness 就够了

✅ 原则 2：liveness ≠ readiness

  • readiness：
    👉 “我现在能不能接流量？”
  • liveness：
    👉 “我是不是已经彻底没救了？”

✅ 原则 3：有启动慢风险，一定加 startup probe

这是生产与实验环境的分水岭

✅ 原则 4：探针本身要“简单、稳定、无副作用”

不应该：

  • 连数据库
  • 查外部 API
  • 做复杂逻辑

总结

生产环境随意配置liveness probe导致在pod启动慢时反复重启，形成CrashLoopBackOff，使用时应该结合启动探针，防止部分应用因为启动慢被误杀。

补一句：

liveness probe 适用于进程已进入稳定运行期后的“不可恢复故障”检测

posted @ 2026-02-05 06:39  Y99017  阅读(7)  评论(0)    收藏  举报