在Kubernetes中实现优雅退出

 

随着持续部署（Continously Deployment）在项目中的中实使用，之前定期或者固定时间的现优发布节奏变为了随时高频率的发布。这就要求每次发布都应该是雅退零停机部署（Zero Downtime Deployment），否则将会引入bug。中实k8s中有一套完整的现优机制保证我们的应用能够实现零停机部署，本文将重点分析其中的雅退优雅退出部分。

本文需要对k8s的中实架构和核心组件的职责有一定的了解，如不了解可参考 Kubernetes Components。现优

发现问题

对于Kubernetes Deployment的雅退每次部署过程，都是中实新版本的Pod创建、老版本的现优Pod删除的过程。

在这个过程中如果不使用优雅退出，雅退则会引发两个问题：

问题1：可能会出现Pod未将正在处理的中实请求处理完成的情况下被删除，如果该请求不是现优幂等性的，则会导致状态不一致的云服务器雅退bug。 问题2：可能会出现Pod已经被删除，Kubernetes仍然将流量导向该Pod，从而出现用户请求处理失败，带来比较差的用户体验。

分析问题

在Kubernetes Pod 的删除过程中，同时会存在两条并行的时间线，如下图所示，其中一条时间线是网络规则的更新过程，另一条时间线是Pod的删除过程。

当用户执行 kubectl delete pod 命令时，

网络规则生效流程：

Kube-apiserver会收到Pod删除的请求，在Etcd中更新Pod的状态为Terminating； Endpoint Controller将该Pod的ip从Endpoint对象中删除； Kube-proxy根据Endpoint对象的改变更新iptables规则，不再将流量路由到被删除的Pod。

Pod删除流程：

Kube-apiserver 会收到Pod删除的请求，在Etcd中更新Pod的状态为Terminating； Kubelet在节点上清理容器的相关资源，例如存储，网络； Kubelet发送SIGTERM进程给容器，服务器租用如果容器中的进程未做任何配置，则容器立即退出； 如果容器未在默认的30秒时间内退出，Kubelet发送SIGKILL给容器，强制让容器退出。

从Pod的删除过程可以知道，如果不对容器内的进程进行任何配置，容器会立即退出，会导致问题1出现。

由于网络规则的更新和Pod的删除是并行的，所以并不能保证网络规则的更新时间一定会早于Pod的删除时间，所以，有可能出现问题2。

解决问题

如果要解决以上两个问题，我们需要做如下配置

设置容器中进程的优雅退出；

增加preStopHook；

修改terminationGracePeriodSeconds。

配置后的时间线如下图所示：

设置容器中进程的优雅退出

在我们项目中，使用的是Springboot，只需要在Springboot的配置文件中增加配置

server:   shutdown: graceful spring:   lifecycle:     timeout-per-shutdown-phase: 30s 

进行该配置后，香港云服务器Springboot会保证在接收到SIGTERM之后不会再接受新的请求[^1]， 并在超时时间内处理完所有正在处理的请求，如果不能处理完成，也会打印出相应的信息并强制退出。超时时间的具体值应该参考系统中最大允许的请求时长，所以理论上所有的请求都应该在30s内处理完，对于没有在30s内处理完成的请求，我们可以通过监控日志然后发Alert的方式，根据实际情况去处理。通过增加此配置，可以解决问题1。对于使用其它的语言和框架的项目，应该也存在类似的配置。

增加preStopHook

针对问题2，需保证网络规则更新后，也就是说新的流量不再路由到要删除的Pod后，再开始Pod的删除。所以需要在 Kubernetes 的Yaml文件中增加 preStopHook[^3]，让Kubelet接收到Pod删除事件后等待一段时间，给Kube-proxy足够的时间更新iptables网络规则后，再开始删除Pod。

lifecycle:   preStop:     exec:       command: ["sh", "-c", "sleep 10"]  # set prestop hook 

这里在我们项目中设置的10s是参照Springboot官网的配置[^2]。

修改terminationGracePeriodSeconds

参照之前分析的Pod删除的流程，Kubernetes会给容器最大的删除时长是30秒[^3]，如果我们在Spring中优雅退出的超时时长和在Kubernetes中的preStopHook时长大于30s，则可能会出现Springboot还未处理完所有的请求Kubernetes已经开始强制删除容器。所以如果这个时长大于30秒，我们需要修改 terminationGracePeriodSeconds使其大于Springboot的优雅退出超时时间和preStopHook之和

terminationGracePeriodSeconds: 45 

最终Kubernetes中的Yaml文件如下所示：

apiVersion: apps/v1 kind: Deployment metadata:   name: graceful-shutdown-test-exit-graceful-30s spec:   replicas: 2   selector:     matchLabels:       app: graceful-shutdown-test-exit-graceful-30s   template:     metadata:       labels:         app: graceful-shutdown-test-exit-graceful-30s     spec:       containers:         - name: graeceful-shutdonw-test           image: graceful-shutdown-test-exit-graceful-30s:latest           ports:             - containerPort: 8080           lifecycle:             preStop:               exec:                 command: ["sh", "-c", "sleep 10"]  # set prestop hook       terminationGracePeriodSeconds: 45    # terminationGracePeriodSeconds 

可以看出，通过设置Springboot的优雅退出，保证了正在处理的请求能够处理完成，通过设置preStopHook，保证了Pod删除和网络规则更新的时序关系。通过配置terminationGracePeriodSeconds，给了容器中进程足够的时间处理所有的请求。综合以上三个步骤，可以解决之前发现的两个问题。

总结

本文通过结合Kubernetes的优雅退出和Springboot的优雅退出机制，保证在随时高频率部署的情况下，服务也可以正确处理所有的请求，减少了bug的出现，提升了用户的体验。