2026-06-22

今日主题

• K8s Pod 三探针区分
• 缓存三大问题区分
• K8s 为何区分 Liveness 和 Readiness
• K8s Startup 探针何时是刚需

新增认知

K8s Pod 三探针区分

• Liveness 失败重启容器，Readiness 失败只摘流量不重启：这是三类探针中最易混淆的核心区分点。Liveness 判定容器"已死"，
  需要重启恢复；Readiness 判定容器"暂时没就绪"（如加载配置、依赖外部服务超时），此时只从 Service Endpoints 摘掉流量，容器不重启，
  恢复后自动加回。Startup 仅启动阶段运行，成功后退出，把接力棒交给 Liveness/Readiness，
  避免慢启动应用（Java JVM 预热）被 Liveness 误判重启。前置条件：Pod 配置了对应探针。

缓存三大问题区分

• 穿透 vs 击穿 vs 雪崩按影响范围递增：穿透是数据"根本不存在"（恶意攻击或查不存在的 ID），击穿是"单个热点 key 过期瞬间"被打穿，
  雪崩是"大量 key 同时过期"导致请求全部打到 DB。口诀：
  穿透挡一下（缓存空值/布隆过滤器）、击穿锁住点（互斥锁 setnx）、雪崩分散开（过期时间加随机值）。前置条件：缓存 + DB 架构，缓存作为 DB 前置挡板。

K8s 为何区分 Liveness 和 Readiness

• Liveness 和 Readiness 不可合并因为恢复动作不同：Liveness 判定容器"已死"（死锁、内存泄漏、进程假死），恢复动作是"重启"；
  Readiness 判定容器"暂时不能服务"（加载配置、依赖 DB 超时、缓存预热），恢复动作是"摘流量不重启"。两者是不同维度的故障判定，合并会导致：
  只有 Liveness 时慢启动应用 CrashLoopBackOff 永远起不来；只有 Readiness 时内存泄漏等不可恢复故障无法自愈。关键场景：
  滚动更新零停机部署需要 Readiness 做流量级别控制（新 Pod 未就绪前不接入流量），Liveness 失败重启无法实现这种平滑过渡。前置条件：
  Pod 配置了对应探针。

K8s Startup 探针何时是刚需

• Startup 探针仅慢启动应用需要：启动快（<30s）的应用如 Go/Node 不需要，Liveness + Readiness 足够。
  慢启动应用（Java/Python ML/大型应用启动 >1min）是刚需，否则陷入两难：
  Liveness failureThreshold 调小（如 30s）会导致启动期间被误判重启→CrashLoopBackOff；
  调大（如 5min）会导致运行时死锁恢复慢。initialDelaySeconds 方案的副作用是启动快时也要白等。
  Startup 探针的机制是启动期间只跑 Startup，Liveness/Readiness 暂停，Startup 成功后 Liveness 接管，实现两全：
  启动慢不被误杀，运行时死锁快速恢复。前置条件：慢启动应用 + 配置了 Liveness 探针。