Kubernetes多久将Terminating状态Pod从Endpoints移除及preStop合理配置

这个sleep配置的核心作用是等待Kubernetes控制面完成Endpoint/EndpointSlice的更新，确保所有流量入口（kube-proxy、Ingress、服务发现组件）都已经把待销毁Pod从转发列表中剔除，不会再有新请求发到该Pod之后，再触发Spring Boot的优雅下线逻辑。合理的时长只需要覆盖你所在集群的Endpoint更新全链路传播延迟即可，不会额外增加不必要的Pod终止耗时。

不同集群场景的参考值 #

• 小型集群（节点数<50，单可用区，无多层流量转发）：Endpoint传播延迟普遍在1~3秒，sleep设置为2~5秒即可满足需求
• 中大型集群（节点数≥50，跨可用区部署，配置了多层Ingress/自定义服务发现组件）：Endpoint传播延迟通常在5~8秒，sleep设置为8~10秒足够覆盖绝大多数场景
• 若需要精准取值，可自行测试集群实际传播延迟：创建服务关联多个Pod，持续请求Service地址的同时删除其中一个Pod，统计从Pod开始销毁到不再有请求流入该Pod的时长，就是你需要的最小sleep时长。

配套优化建议，避免额外耗时 #

• 提前在Spring Boot配置文件中开启优雅下线功能，配置server.shutdown=graceful，同时设置spring.lifecycle.timeout-per-shutdown-phase为业务允许的最长请求处理时间。
• 要和Pod的terminationGracePeriodSeconds参数配合使用：terminationGracePeriodSeconds的取值应当等于「preStop sleep时长 + 业务允许的最长请求处理耗时」，避免请求还没处理完就被K8s强制销毁。举个例子，如果preStop睡5秒，业务最长请求需要20秒处理完成，那terminationGracePeriodSeconds设置为25秒即可。
• 若你的集群使用IPVS模式的kube-proxy、开启了EndpointSlice特性，Endpoint传播延迟会比默认iptables模式低1~2秒，可以适当下调sleep时长，无需保留冗余。
• 无需盲目设置10秒以上的sleep时长，除非你实际测试过当前集群的Endpoint传播延迟确实超过10秒，否则只会无谓增加发布过程的等待时间。

当kubelet启动优雅关闭流程的同时，控制平面会将正在关闭的Pod从匹配选择器的Service对应的Endpoints（若启用了EndpointSlice则也包含）对象中移除。

你可以在Pod spec的preStop hook中添加sleep配置，具体时长可根据自身业务场景按需调整。

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