各位大佬好，我最近碰到一个挺棘手的问题，想请大家帮忙支支招：

问题背景 #

我维护着一个部署在Kubernetes上的FastAPI服务，主要有两个端点：

• 核心的文档处理端点：负责处理从几页小文档到超大型复杂文档的任务，流程里包含GenAI相关的文档分片、嵌入向量生成等操作，10页文档大概要2-5分钟，复杂文档甚至要30分钟以上，整个处理pipeline是完全支持并发调用和函数执行的
• 健康检查端点：专门给Kubernetes的健康检查脚本check.sh调用

核心问题 #

K8s里的check.sh会频繁ping健康检查端点，但它的超时时间只设了2秒。当服务在全力处理超大复杂文档的时候，健康检查请求经常没办法在2秒内得到响应，直接触发超时。连续三次超时后，K8s就会把Pod给重启了，导致正在处理的大文档直接中断，带来不少损失。

已尝试的方案（但没解决问题） #

我之前想通过中间件把健康检查请求和核心请求做隔离，还给核心请求加了信号量控制并发，代码大概是这样的：

if path.startswith("/document_processing/health"):
    return await call_next(request)
if path.startswith("/document_processing"):
    with tracer.start_as_current_span("acquire_heavy_semaphore"):
        async with heavy_semaphore:
            return await call_next(request)

但加了这段中间件后，问题还是没改善——大文档处理时健康检查依然会超时，Pod该重启还是重启。

想请教大家的点 #

1. 有没有大佬能帮我分析下，为什么这段中间件没起作用？是不是我哪里的逻辑写得有问题？
2. 有没有其他可行的方案，能让健康检查请求在服务忙碌时也能快速响应，避免Pod被K8s误杀？比如是不是Kubernetes的健康检查配置需要调整？或者FastAPI这边还有什么其他优化方向？