共计 1131 个字符，预计需要花费 3 分钟才能阅读完成。
文本翻译自: https://itnext.io/how-do-you-gracefully-shut-down-pods-in-kub…
当你执行 kubectl delete pod 时，pod 被删除，endpoint 控制器从 service 和 etcd 中删除该 pod 的 IP 地址和端口。
你能够应用 kubectl describe service 察看到这一点。
但远不止如此！
多个组件都会同步变更至本地 endpoint 列表：
- kube-proxy 通过本地 endpoint 列表来编写 iptables 规定
- CoreDNS 应用 endpoint 重新配置 DNS
Ingress 控制器、Istio 等也是如此。
所有这些组件都将（最终）删除以前的 endpoint，这样就再也没有流量能够达到它了。
同时，kubelet 也收到了变动的告诉，并删除了 pod。
当 kubelet 在其余组件之前删除 pod 时会产生什么？
可怜的是，你会遇到停机， 因为 kube-proxy、CoreDNS、ingress 控制器等组件仍在应用该 IP 地址来路由流量。
所以，你能够做什么？
期待！
如果在删除 Pod 之前期待足够长的工夫，航行中的流量依然能够解析，并且能够将新流量调配给其余 Pod。
你应该如何期待？
当 kubelet 删除一个 pod 时，它会经验以下步骤：
- 触发
preStop钩子（如果有）。 - 发送
SIGTERM。 - 发送
SIGKILL信号（默认 30 秒后）。
你能够应用 preStop 挂钩来插入人工提早。
你能够在你的应用程序中监听 SIGTERM 信号并期待。
此外，你能够优雅地进行该过程并在期待实现后退出。
Kubernetes 给你 30 秒的工夫来这样做（时长可配置）。
你应该期待 10 秒、20 秒还是 30 秒？
没有繁多的答案。
尽管流传 endpoint 可能只须要几秒钟，但 Kubernetes 不保障任何工夫，也不保障所有组件将同时实现。
如果你想摸索更多，这里有一些链接：
- https://learnk8s.io/graceful-shutdown
- https://freecontent.manning.com/handling-client-requests-prop…
- https://kubernetes.io/docs/concepts/workloads/pods/pod/#termi…
- https://medium.com/tailwinds-navigator/kubernetes-tip-how-to-…
- https://medium.com/flant-com/kubernetes-graceful-shutdown-ngi…
- https://www.openshift.com/blog/kubernetes-pods-life
