Kubernetes Pod终止机制疑问及请求Socket报错问题解决咨询

你遇到的Socket错误，核心原因是Kubernetes Pod终止流程中，Service端点移除与容器TERM信号发送的时序没有严格的先后保障，具体细节如下：

• 当你删除Pod（或触发滚动更新/缩容）时，Pod会被标记为Terminating状态，此时两个独立的操作会并行执行：

  1. kubelet组件：立即向容器发送TERM信号，启动优雅停机倒计时（由terminationGracePeriodSeconds控制）。
  2. Endpoint Controller组件：检测到Pod状态变化，将其从Service的端点列表中移除，随后kube-proxy更新节点的iptables规则，停止向该Pod转发流量。

• 由于这两个操作没有同步机制，可能出现kubelet先发送TERM信号，而Pod还未从Service端点中移除的情况：此时你的应用收到TERM信号后，会停止接受新的连接，但Service的流量仍然会被路由到这个Pod，导致新的请求无法建立连接，最终出现Socket错误。

• 另外，在Kubernetes 1.16版本中，当Pod进入Terminating状态后，readiness探针会被直接判定为失败（忽略实际探针结果），但这个状态同步到Endpoint Controller和kube-proxy更新iptables的过程存在延迟，进一步放大了时序问题的影响。

针对这个问题，我们可以通过以下两种方式来修复：

1. 添加PreStop钩子延迟TERM信号发送 #

在Pod的容器配置中添加preStop钩子，让kubelet在发送TERM信号前等待一段时间，确保Pod已经从Service端点中移除，iptables规则更新完成。示例配置如下：

containers:
- name: service
  image: host.org/images/grace:v0.1
  # 其他配置保持不变
  lifecycle:
    preStop:
      exec:
        command: ["sleep", "5"] # 等待5秒，可根据实际环境调整时长

这个延迟时间需要根据你的集群规模调整：集群节点越多、kube-proxy更新iptables的耗时越长，需要的等待时间就越长（一般3-10秒足够）。

2. 优化应用的优雅停机逻辑 #

配合PreStop钩子，让应用主动控制readiness探针的状态，确保流量完全停止后再开始处理现有连接：

• 在你的Go应用中添加一个状态标志（比如shuttingDown），当收到PreStop钩子的触发信号（比如调用一个自定义的/shutdown端点）时，将该标志设为true。
• 修改/health端点的逻辑：当shuttingDown为true时，返回非200状态码，让readiness探针失败，触发Kubernetes将Pod从Service端点中移除。
• 在PreStop钩子中，先调用/shutdown端点，再等待足够时间，最后让应用开始关闭服务器、处理完现有连接后退出。

示例应用逻辑调整：

var shuttingDown = false

func main() {
    http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        if shuttingDown {
            w.WriteHeader(http.StatusServiceUnavailable)
            return
        }
        w.WriteHeader(http.StatusOK)
    })

    http.HandleFunc("/shutdown", func(w http.ResponseWriter, r *http.Request) {
        shuttingDown = true
        w.WriteHeader(http.StatusOK)
    })

    // 其他端点逻辑...

    // 处理TERM信号
    sigChan := make(chan os.Signal, 1)
    signal.Notify(sigChan, syscall.SIGTERM)
    go func() {
        <-sigChan
        // 等待现有连接处理完成
        server.Shutdown(context.Background())
        os.Exit(0)
    }()

    server.ListenAndServe()
}

对应的PreStop钩子配置：

preStop:
  exec:
    command: ["curl", "-XPOST", "http://localhost:10002/shutdown", "&&", "sleep", "5"]

修改配置后重新部署，再次执行测试二：使用wrk发起请求并删除Pod，应该不会再出现Socket错误。如果仍有少量错误，可以适当延长PreStop钩子的等待时间。

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