K8s探针配置AI服务：别让健康检查成为摆设

这个帖子说到点子上了，尤其是GPU显存泄漏导致进程还在但推理已经崩了的情况，我这边也碰到过类似的坑。当时排查了半天，发现进程状态正常，但模型返回的latency从50ms飙到2s，最终定位到显存碎片化导致cudaMalloc失败后fallback到CPU回退逻辑，但health check的/healthz根本没覆盖到这个路径。

补充一点，就绪探针的阈值设计其实比检测逻辑本身更考验功力。推理队列深度设多少合适？不同模型、不同batch size下差异很大，设得太紧容易误杀，设得太松又失去意义。我们现在的做法是把探针和业务SLA挂钩——比如P99延迟超过300ms就认为不健康，这样探针状态直接反映了用户感知。另外，自定义探针里建议加上显存利用率监控，显存占用超过90%且持续上升趋势时主动标记NotReady，比等到OOM kill再重启要干净得多。

启动探针这块确实容易被忽略。像LLM模型加载动不动几十G，加上tokenizer和kv cache初始化，冷启动时间能拖到五分钟。startupProbe的failureThreshold和periodSeconds配得合理，就能避免k8s过早kill掉还在加载的pod。不过有个小坑，如果用了init container预加载模型，startupProbe的计时是从init container完成后开始的，这个时间点要算清楚。

还有个细节，探针的timeoutSeconds不要太短。AI服务的推理latency本身就有波动，设个1秒的timeout碰到模型冷启动阶段基本必挂。我们一般设到10-15秒，配合initialDelaySeconds给足模型预热时间，这样探针误报率能降不少。