健康检查

Kubernetes liveness探针实践：浅探活、深探活与中间派的抉择 背景：从嵌入式看门狗到容器探针 做了10年嵌入式，早期写MCU固件时"健康"这件事是被看门狗强制定义的：主循环喂狗成功=活着，喂不上=复位。边界极其干净——只看"

现象或背景 某次生产环境Pod频繁崩溃，导致服务不可用，影响用户量达到5万，单次故障持续2小时。监控数据显示，Pod在崩溃前CPU使用率长期处于95%以上，内存使用率接近阈值。通过日志分析发现，崩溃前存在大量OOM Killer日志，且系统

背景 做了 10 年嵌入式，早期写 MCU 固件时"健康"这件事是被看狗强制定义的：主循环喂狗成功 = 活着，喂不上 = 复位。边界极其干净——只看"进程/主循环还在不在跑"，不替它检查外设寄存器、DMA、总线有没有挂。 搬到容器化之后，这

【背景】 我在一家中型公司做网络与稳定性，管着一套 60+ 微服务（Java/Go 混合，K8s 1.28，自研 Ingress）。去年经历过一次「健康检查雪崩」： MySQL 主从切换耗时 8 秒，期间所有服务的 /ready 探针（查

结论先行 readiness 探针的职责是"我还能不能接流量"，不是"我的下游还活不活着"。 一旦把下游依赖（Redis、MySQL、下游 RPC）的可达性塞进 readiness 的判定，一个下游 6 秒的抖动，就会让所有 Pod 同时被

先给结论：健康检查探针不是"越探越稳"，探得太深反而可能成为故障放大器。我踩过一次真实的坑，今天想把这个争点摊开聊。 【背景】 我维护一批 K8s 1.27（12 节点、containerd 1.7）的核心服务。去年一次 Redis 抖动约

«结论先行：健康检查通过 = 端口能建连 + 一条 "SELECT 1" 能跑通，这两件事对「业务能不能正常跑」的覆盖度不到 20%。TCP 建连只证明内核网络栈活着，"SELECT 1" 只证明数据库里存在一条不需要锁、不需要连接池排队的

背景 做了 10 年嵌入式，早期写 MCU 固件时"健康"这件事是被看门狗强制定义的：主循环喂狗成功 = 活着，喂不上 = 复位。边界极其干净——只看"进程/主循环还在不在跑"，不替它检查外设寄存器、DMA、总线有没有挂。 搬到容器化之后，