如何让Kubernetes中长时间运行的应用在收到SIGTERM后完成请求

核心结论 #

可以让Pod暂停终止直至当前长调用完成，但无法绕过Kubernetes的terminationGracePeriodSeconds硬限制——如果调用时长超过这个值，最终还是会收到SIGKILL被强制终止。下面是具体的实现方案和应对超时时长的思路：

1. 基础优雅关闭实现（针对.NET应用） #

对于你的.NET中间件，结合Kubernetes的终止流程，正确的处理步骤是：

• 捕获SIGTERM信号：Kubernetes在Pod终止时会先发送SIGTERM，此时Pod会被从Service的端点列表中移除，不再接收新请求。
• 利用IApplicationLifetime.ApplicationStopping注册关闭回调：在回调中执行以下操作：
  1. 立即停止接收新请求（比如关闭HTTP监听端口、拒绝新的WCF连接）。
  2. 维护一个请求计数器（比如用Interlocked类跟踪正在执行的请求数量），等待计数器降至0（即所有在途长调用完成）。
  3. 计数器归0后，主动调用IHostApplicationLifetime.StopApplication()退出进程。

示例代码片段（伪代码）：

public void Configure(IApplicationBuilder app, IHostApplicationLifetime lifetime)
{
    var activeRequests = 0;

    // 拦截请求，计数+1
    app.Use(async (context, next) =>
    {
        Interlocked.Increment(ref activeRequests);
        try
        {
            await next();
        }
        finally
        {
            Interlocked.Decrement(ref activeRequests);
        }
    });

    // 注册关闭回调
    lifetime.ApplicationStopping.Register(() =>
    {
        Console.WriteLine("收到终止信号，等待在途请求完成...");
        // 循环等待所有请求完成
        while (Interlocked.CompareExchange(ref activeRequests, 0, 0) > 0)
        {
            Thread.Sleep(100);
        }
        Console.WriteLine("所有请求已完成，准备退出");
    });
}

2. 处理调用时长超过terminationGracePeriodSeconds的情况 #

如果你的长调用时长无法预估，或可能超过设置的宽限期，有以下几种应对思路：

• 设置足够大的terminationGracePeriodSeconds：这是最直接的方案。比如如果你的长调用最长可能持续1小时，就把值设为3600（单位：秒）。但要注意：如果应用出现无响应的情况，Kubernetes会等待这个时长后才会强制清理Pod，可能影响集群的弹性伸缩效率。
• 异步化长请求：把原本同步等待的长调用改为异步投递（比如通过消息队列），应用只负责发送请求，不等待执行结果。这样Pod终止时就没有在途的长请求需要等待，从根源上解决问题。
• 请求幂等设计：如果无法避免同步等待，确保所有长请求都是幂等的——即使Pod被SIGKILL强制终止，后续重试该请求也能得到正确结果，不会产生副作用。

3. 关于IApplicationLifetime.ApplicationStopping的疑问 #

是的，即使你用ApplicationStopping延迟关闭，最终还是会收到SIGKILL。因为terminationGracePeriodSeconds是Kubernetes对Pod终止流程的硬限制：从Pod被标记为Terminating开始，到发送SIGKILL的总时长不会超过这个值。你的应用在ApplicationStopping中的阻塞等待，只是延迟了进程退出的时间，但无法突破这个限制。

内容的提问来源于stack exchange，提问作者davincikuo