Kubernetes在terminationGracePeriodSeconds阶段能否发起出站请求？

这个现象完全符合Kubernetes的设计预期，核心原因是Pod终止流程中网络规则更新和进程信号通知是并行触发的，和本地杀进程的逻辑存在本质差异。 #

根因说明 #

Kubernetes在处理Pod删除请求时，会并行触发两个独立的流程：

• 网络层面：立刻通知kube-proxy、CNI插件更新节点上的iptables/ipvs规则，以及集群内的Endpoint列表，直接拦截该Pod所有新发起的入站/出站TCP连接，仅保留已经建立成功的活跃连接可以正常通信。
• 进程层面：通知kubelet执行容器终止流程：先执行配置的preStop钩子，再给容器内1号进程发送SIGTERM信号触发优雅关闭，等待terminationGracePeriodSeconds时长后如果进程仍未退出，就发送SIGKILL强制终止进程。

你两个测试场景的差异本质就是本地杀进程和K8s删Pod的逻辑不同：

• 本地执行kill pid发送SIGTERM时，操作系统不会修改任何网络规则，只要进程还在运行，就可以正常发起新的网络连接，因此测试可以正常拿到Google的响应。
• K8s环境下，请求接口后立刻删Pod，sleep阶段属于原有逻辑执行，不需要新建网络连接，因此可以正常跑完打印Done Sleeping；等到执行OkHttp请求时需要新建TCP连接，此时网络规则已经完成更新，新连接被拦截，就会抛出Connection refused异常。

解决方案 #

如果你的业务场景需要在优雅关闭阶段正常发起新的外部请求，可以通过添加preStop钩子解决，核心思路是延迟SIGTERM信号的发送时间，等网络规则更新完成后再触发应用的优雅关闭，配置示例如下：

spec:
  containers:
  - name: spring-boot-demo
    image: your-spring-boot-image
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "sleep 3"]
    terminationGracePeriodSeconds: 30

preStop的sleep时长根据你集群kube-proxy的规则更新延迟调整即可，一般3~5秒就可以覆盖绝大多数场景，注意sleep时长要算在terminationGracePeriodSeconds的总时长内，避免优雅关闭时间不足。

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