容器化 C 语言固件后，硬件 WDT「主循环卡住=复位」的语义怎么映射到 K8s 探针？/health 被其他线程响应，探针打不到真正的死锁

背景

我做了 3 年嵌入式，主力在边缘网关方向。最近把一个 C 语言固件搬进容器跑在 K8s 上：K8s 1.28.9 / containerd 1.7.13 / cgroup v2 / 内核 5.15，节点 4C8G。固件主体是一个 C 主循环（任务调度 → 采集 → 协议解析 → 回写），单线程 while(1) 结构，原来在裸机上靠**硬件看门狗（WDT）**保命：主循环每 50ms 喂一次狗，连续 200ms 没喂，硬件直接复位，语义极其干净——"主循环活着 = 设备活着"。

容器化后，我加了一个独立的 HTTP 线程（epoll + libmicrohttpd）暴露 /health 端点，kubelet 的 liveness 探针每 10s 打一次（timeout=3s）。

现象

上周出现一次真实故障：协议解析模块的一个死锁（pthread_mutex 交叉持有）把主循环卡住了 4 分钟。期间：

• 独立 HTTP 线程完全正常，/health 一直返回 200 OK，kubelet 没有杀 Pod；
• 业务侧表现为：采集数据 4 分钟没更新，下游告警才人工介入；
• 如果还是裸机 + 硬件 WDT，200ms 后设备就复位了，根本不会拖 4 分钟。

核心矛盾：硬件 WDT 保护的是"主循环"这个单线程，而 K8s 探针保护的是"进程"这个多线程整体。只要进程里有任何一个线程还能响应 HTTP，liveness 就绿，主循环死锁对 kubelet 完全不可见。

已尝试与结果

1. 把 /health 改成主循环喂狗后才返回 200：即主循环每轮把 last_feed_time 写进一个原子变量，/health handler 里检查 now - last_feed_time > 200ms 就返回 503。

   • 结果：方向对了，但引入了新问题——主循环正常时，HTTP 线程偶尔被 cgroup 调度延迟（节点上还有 2 个业务容器抢占 CPU），last_feed_time 的"新鲜度"判断在负载高时误报 503，kubelet 连续 3 次失败就杀 Pod，反而造成不必要的重启。

2. 加一个 sidecar 容器做心跳检测：sidecar 里跑一个 C 进程，通过共享内存（tmpfs 挂载）读主循环的 tick 计数，发现 tick 停滞超 200ms 就退出（exit code ≠ 0），触发 liveness 失败。

   • 结果：sidecar 本身也被 cgroup 调度，在节点 CPU 紧张时 sidecar 自己的检测线程也被 throttle，200ms 的窗口根本保不住；而且多了一个容器的运维面，复杂度上去了。

3. 把 liveness 探针换成 exec 探针，直接检查主循环的 tick 计数器：kubectl exec 进容器读 /proc/<pid>/... 里的原子变量。

   • 结果：exec 探针每次要 fork 一个进程，开销比 HTTP 大；而且 /proc 里的原子变量在 cgroup 内存压力下可能读到不一致的值（没有 memory barrier 保证）。

期望得到的答案形态

• 在"主循环是单线程 C 代码、无法改造成多线程"的硬约束下，有没有一种探针或信号设计能等价于硬件 WDT 的语义——"主循环连续 N ms 没执行 = 硬复位"——同时不被 cgroup 调度延迟误杀？
• 如果探针本身做不到（我怀疑做不到，因为探针只能从进程外部看），那进程内自杀（主循环检测到自身卡顿后主动 abort() 或 exit(1)）是不是更贴近硬件 WDT 的语义？你们怎么解决"谁来检测主循环卡顿"这个鸡生蛋问题？
• 或者，有没有人在边缘场景下保留硬件 WDT 芯片，容器只是把固件从"独占裸机"变成"容器内运行"，WDT 的喂狗仍然走 GPIO？这种"半裸机半容器"的做法你们怎么评估？
• 如果以上都不可行，你们实际用的兜底方案是什么？请贴具体的探针 YAML / 检测代码 / 节点配置，最好带上参数和踩过的坑。

参考

• 社区讨论《/health 端点该查多深？浅探活还是深探活》(id=700) 里有人提过"探针不该替业务查外设"，和我的问题方向一致但没深入到单线程主循环死锁的场景；
• 《K8s 探针三件套：liveness / readiness / startup 我踩过的坑与默认值建议》(id=20) 给了探针参数的默认值建议，但没涉及"探针能看到的粒度 vs 我想保护的粒度不匹配"这个问题。