Pod处于Terminated状态时仍提供流量的可行性及相关疑问

疑问1：需求是否可行？ #

完全可行，但需要调整滚动更新策略、就绪探针配置，同时正确理解Kubernetes的Pod终止与流量调度逻辑。

你观察到Terminated状态的Pod仍有流量进入，通常是这几个原因：

• 端点同步延迟：Service的端点控制器将Pod状态同步到EndpointSlice需要时间，这段窗口内旧Pod还在流量转发列表中
• 客户端长连接：已建立的长连接不会因Pod状态变更立即断开，仍会持续传递流量
• 负载均衡器会话保持：外部负载均衡器的会话规则可能会将流量转发到已标记终止的Pod

要实现「新Pod稳定就绪后再终止旧Pod」，核心是调整滚动更新的surge和unavailable参数——你当前配置surge: 0意味着不会提前启动新Pod，直接终止旧Pod，这正是请求超时的根源。

疑问2：terminationGracePeriodSeconds的意义？ #

Pod进入Terminated状态后，Kubernetes会先向容器发送SIGTERM信号触发优雅关闭，terminationGracePeriodSeconds是这段优雅关闭的等待时长：

• 宽限期内，容器可以继续处理已接收的存量请求，完成后自行退出
• 若宽限期结束容器仍未退出，Kubernetes会发送SIGKILL强制终止
• 注意：Pod被标记为Terminated后会被移出Service端点列表（不再接收新请求），但已建立的连接不受影响，宽限期就是给容器处理这些存量请求的缓冲时间，而非允许接收新流量。

配置调整建议 #

针对你的需求，修改配置如下：

# 滚动更新策略：先启动新Pod，再终止旧Pod，确保无服务中断
strategy:
  type: RollingUpdate
  maxSurge: 20%  # 允许临时启动超过期望副本数20%的新Pod，可根据集群资源调整
  maxUnavailable: 0%  # 严格禁止旧Pod在新Pod就绪前终止

# 优化就绪探针：缩短等待和探测周期，快速确认Pod就绪状态
container:
  port: 8080
  readinessProbe:
    enabled: true
    initialDelaySeconds: 30  # 容器启动后30秒开始探测，根据应用实际启动时间调整
    periodSeconds: 10  # 每10秒探测一次，及时发现Pod就绪
    httpGet:
      path: /healthz  # 确保应用有合法的健康检查端点
      port: 8080

# 保留优雅关闭宽限期，确保旧Pod能处理完存量请求
terminationGracePeriodSeconds: 240

补充说明 #

• maxUnavailable: 0% 保证任何时刻可用副本数都不低于期望值，彻底避免因旧Pod提前终止导致的服务缺口
• 就绪探针的延迟和周期需匹配应用实际启动速度，过长的等待会拖慢滚动更新效率
• 建议在应用中监听SIGTERM信号，收到信号后停止接收新请求，同时处理完存量请求再退出，进一步提升优雅关闭效果

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