如何实现K8s中Pod的优雅启停？

Question

在Kubernetes中，如何确保Pod优雅终止时正在处理的请求不被中断？常见问题是容器收到SIGTERM信号后立即停止，导致连接骤断、请求失败。尽管配置了terminationGracePeriodSeconds和preStop钩子，部分应用仍未能完成正在进行的请求处理。如何结合健康检查、关闭前等待及连接 draining 机制，实现真正无损的优雅停机？

Answer 1

一、Pod优雅终止的基本机制与常见问题

Kubernetes中，当一个Pod被删除时，API Server会将其状态标记为Terminating，并发送SIGTERM信号给容器主进程。默认情况下，容器在收到SIGTERM后有30秒的宽限期（可通过terminationGracePeriodSeconds配置），超时则发送SIGKILL强制终止。

然而，许多应用在接收到SIGTERM后立即停止服务，未等待正在进行的请求完成，导致客户端请求中断或连接重置。即使设置了preStop钩子和延长宽限期，若应用自身不具备优雅关闭能力，仍无法实现真正的无损下线。

常见问题包括：

• 应用未监听SIGTERM信号，直接退出
• HTTP服务器未关闭新连接接入但继续处理旧请求
• 负载均衡器或Ingress控制器未及时感知Pod失活状态
• 长连接（如gRPC、WebSocket）未主动通知对端即将关闭

二、从信号处理到应用层优雅关闭

要实现真正无损停机，必须在应用层配合Kubernetes的生命周期管理。以下是以Go语言为例的典型处理模式：

package main

import (
    "context"
    "net/http"
    "os"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        // 模拟耗时请求
        time.Sleep(10 * time.Second)
        w.Write([]byte("OK"))
    })

    server := &http.Server{Addr: ":8080", Handler: mux}

    go func() {
        if err := server.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            log.Fatalf("Server failed: %v", err)
        }
    }()

    c := make(chan os.Signal, 1)
    signal.Notify(c, syscall.SIGTERM)
    <-c

    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    if err := server.Shutdown(ctx); err != nil {
        server.Close()
    }
}

上述代码通过监听SIGTERM信号触发server.Shutdown()，停止接收新请求，并等待活跃连接完成处理，是实现应用层优雅关闭的关键。

三、结合preStop钩子与健康检查实现连接Draining

Kubernetes提供了preStop生命周期钩子，可在容器终止前执行一段命令或延迟操作。结合服务端点移除与连接draining机制，可有效避免流量进入即将终止的Pod。

机制	作用	配置示例
preStop Hook	在SIGTERM前执行延迟或清理操作	exec: command: ["sh", "-c", "sleep 10"]
readinessProbe	控制Pod是否加入Service Endpoints	HTTP检查路径/healthz
livenessProbe	决定容器是否存活，影响重启策略	TCP或HTTP探测
terminationGracePeriodSeconds	设置最大优雅终止时间	60秒

四、完整无损滚动更新流程设计

通过组合多种机制，构建完整的优雅终止流程。以下是基于Nginx反向代理与gRPC服务的典型场景流程图：

graph TD
    A[Deployment Rolling Update Triggered] --> B[Kubernetes creates new Pod]
    B --> C[New Pod passes readinessProbe]
    C --> D[Add to Service Endpoints]
    D --> E[Old Pod receives SIGTERM]
    E --> F[preStop hook: sleep 5s or call /shutdown]
    F --> G[Set /healthz → failure]
    G --> H[Endpoint controller removes old Pod]
    H --> I[Active requests continue processing]
    I --> J[Within grace period, finish ongoing work]
    J --> K[Container exits cleanly]
    

该流程确保：新Pod就绪后再终止旧Pod；通过健康检查主动“摘流”；利用preStop延迟等待连接draining；最终在宽限期内完成所有请求。

五、高级场景：长连接与gRPC服务的优雅关闭

对于gRPC等长连接服务，需支持GRACEFUL_SHUTDOWN语义。服务端应：

1. 监听SIGTERM信号
2. 拒绝新的Stream创建
3. 通知客户端即将关闭（可通过GOAWAY帧）
4. 等待现有Stream完成或超时
5. 调用GracefulStop()

Kubernetes侧应配置足够长的terminationGracePeriodSeconds（如60~120秒），并使用preStop配合健康探针快速摘除流量。

六、验证与监控建议

为确保优雅终止机制生效，建议实施以下验证手段：

• 通过日志确认应用收到SIGTERM并进入关闭流程
• 监控指标中增加“正在处理请求数”维度
• 使用Prometheus记录container_terminated_reason
• 在CI/CD中模拟滚动更新并注入长请求进行测试
• 利用eBPF工具（如Pixie）跟踪Pod生命周期与连接状态

同时，可定义SLO指标衡量“滚动更新期间错误率”，作为无损发布的客观依据。