liveness探针

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

«结论先行：容器里 Java 服务「CPU 监控很绿、P99 偶发飙高、liveness 偶发被杀」，第一嫌疑不是 GC 本身，而是 JDK 的 CPU 预算假设（按宿主核数派生 GC/JIT 线程）和内核 CFS 的实际配额（cpu.ma

«结论先行：探针误杀不只有"GC 停顿"和"连接池死锁"两种根因，嵌入式场景下还有一种更隐蔽的——节点 eMMC 慢盘的 fsync 抖动，把探针 HTTP handler 阻塞在同步落盘上，响应时间冲过 "timeoutSeconds"（

背景 10 年 SRE，最近接手一个 K8s 1.28（containerd 1.7，节点 16C64G）上的 Go 1.21 网关服务，4 副本、单副本峰值 QPS 约 2k，主要工作是转发 + 一些带 30~60s 长连接的任务。 现象