随着持续部署(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","sleep10"]#setprestophook
这里在我们项目中设置的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","sleep10"]#setprestophook
- terminationGracePeriodSeconds:45#terminationGracePeriodSeconds
可以看出,通过设置Springboot的优雅退出,保证了正在处理的请求能够处理完成,通过设置preStopHook,保证了Pod删除和网络规则更新的时序关系。通过配置terminationGracePeriodSeconds,给了容器中进程足够的时间处理所有的请求。综合以上三个步骤,可以解决之前发现的两个问题。
总结
本文通过结合Kubernetes的优雅退出和Springboot的优雅退出机制,保证在随时高频率部署的情况下,服务也可以正确处理所有的请求,减少了bug的出现,提升了用户的体验。
原文链接:https://insights.thoughtworks.cn/how-to-stop-kubernetes-elegantly/