3.2.5 滚动更新
rollingUpdate
应用中的一下yaml参数对于pod在被滚动更新过程中的行为有非常大的影响，比如rollingUpdate中maxSurge和maxUnavailable，其中前者是可以理解为应用最大副本数=设置副本数*（1+maxSurge），应用最小副本数=设置副本数*（1-maxUnavailable），结果为向上取整。如果maxUnavailable:0，表明要等新建立的pod ready后，才会去删除老的pod，该情况下会对整个集群的资源要求比较高。
Kubernetes 集群中，业务通常采用 Deployment + LoadBalancer 类型 Service 的方式对外提供服务，这种架构部署和运维都十分简单方便，但是在应用更新或者升级时可能会存在服务中断，引发线上问题。 在更新应用过程中涉及新建pod和删除pod以及相关的节点或pod加入到SLB的后端的过程。所以需要分开进行分析：
新建pod
如果引起服务中断的是新建pod，这是因为对于k8s来说，pod running后，就会被加到svc的后端，也就是SLB的后端中，此时如果pod 内承接业务请求的应用还未就绪，那么就会引起相关的业务中断。所以需要给pod设置相关的readiness探针，让pod内的应用完全就绪后才会被加入到svc后端中。
被删除的pod
如果发现引起业务服务中的是被删除的老pod。这是因为对于k8s来说， 在删除过程中需要对多个对象（如 Endpoint、ipvs/iptables、SLB）进行状态同步，这些同步操作是异步执行的。在pod被删除的时候，pod会被置于terminating状态，从相关的svc移除，不再承接新流量，但是依然可以处理老的流量请求。但是由于是异步进行的，所以存在相关pod已经收到了SIGTERM的信号，被终止，但是还未被从SLB后端移除，造成了流量被发送到了deleted的pod上，所以针对这种情况，建议使用PreStop，使pod收到了SIGTERM后不要马上终止，确保被SLB转发而来的流量请求依然可以被处理。 但是需要注意PreStop的时间不可以超过 terminationGracePeriodSeconds ，如果到达了 terminationGracePeriodSeconds 时间，PreStop还未执行完毕，pod依然会被马上强制终止。
iptables/ipvs
对于SLB 转发流量到后端pod，整个链路是从SLB->node->POD。 所以存在相关的ipvs/iptable规则已经被删除，但是pod还未完全从SLB后端移除，此时流量被转发到后端node时候已经没有了相关的转发规则了。 Cluster 模式下 kube-proxy 会在所有的 Node 的 上配置相关的转发工艺则，如果当前 Node 没有业务 pod，则该请求会被转发给其他 Node，因此不会存在服务中断 。 Local 模式下，kube-proxy 仅仅会在有后端pod的node上配置转发规则。当 Node 上只有一个 pod 且状态变为 terminating 时，iptables/ipvs 会将该 pod 记录移除。此时请求转发到这个 node 时，无对应的 iptables/ipvs 记录，导致请求失败。这个问题可以通过原地升级来避免，即保证更新过程中 Node 上至少有一个 Running Pod。 ENI 模式 Service：ENI 模式绕过 kube-proxy，将 Pod 直接挂载到 SLB 后端，因此不存在因为 iptables/ipvs 导致的服务中断。 目前Terway集群的SVC 默认情况下都是ENI模式挂载后端pod到SLB
SLB
当SVC的后端pod发生变化，会将 Node 从 slb 后端移除。当节点从 slb 后端移除后，SLB 对于继续发往该节点的长连接会直接断开，导致服务中断 ，此时建议为 SLB 设置长链接优雅中断。
