一文看懂K8S中的滚动升级

　　随着云原生的普及，越来越多的公司已经使用K8S进行容器编排和管理，在分布式微服务场景下，滚动升级是一种自动化程度较高的主流发布方式，能做到服务更新升级过程中用户体验平滑，业务“零停机”。

　　Part 01、升级策略

　　K8S中通过spect.strategy来定义新的 Pod 替换为旧的Pod的策略。策略类型分为：重建策略(Recreate)或滚动升级策略(RollingUpdate)，默认为 RollingUpdate。

　　Recreate -- 在创建出新的Pod之前会先删掉所有已存在的Pod。

　　RollingUpdate -- 可以指定maxSurge和maxUnavailable来控制滚动升级过程。

　　maxSurge：用来指定升级期间可以超过预期Pod数量的最大值，该值可以是一个绝对数(例如：5)或一个预期 Pod 的百分比(例如：10%)，默认为 25%。通过百分比计算的绝对值向上取整。

　　maxUnavailable：用来指定升级期间不可用的最大 Pod 数量。该值可以是一个绝对数(例如：5)或一个预期 Pod 的百分比(例如：10%)，默认为 25%。通过百分比计算的绝对值向下取整。

　　在业务中我们默认使用滚动升级策略，通过合理配置maxSurge和maxUnavailable实现业务高可用。

　　Part 02、健康检查

　　K8S中通过探针对容器执行定期诊断来判断容器的状态，通常使用存活性探针(liveness probes)和就绪性探针(readiness probes)根据容器状态进行后续处理。

　　livenessProbe：探测容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。

　　readinessProbe：探测容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。

　　在业务中我们经常同时使用这两种探针，通过存活性探针判断容器是否需要重启以实现自愈，通过就绪性探针判断容器是否已经准备好对外提供服务。

　　Part 03、K8S滚动升级原理

　　K8S通过Deployment创建副本，Deployment是一个三级结构：Deployment控制Replicaset(副本集)，Replicaset控制Pod。根据Deployment的这个结构特性，一个Deployment下可存在不同的Replicaset，那就表示一个Deployment下可以有不同镜像版本的Pod同时存在。

　　升级过程中Deployment自动创建Replicaset，Replicaset通过滚动升级策略中maxSurge、maxUnavailable两个参数来精准地控制每次滚动的Pod数量。再结合健康检查中的存活性探针(liveness probes)和就绪性探针(readiness probes)来精准判断Pod何时启动成功以及何时准备好服务请求，确保升级过程中可用的Pod都是可正常提供服务的。

　　具体过程如下图所示。

K8S滚动升级过程

　　本文中介绍了K8S中的升级策略和健康检查，通过配置升级策略和健康检查实现滚动升级来确保微服务的平滑部署，但滚动升级也对业务设计提出了更高的要求，需要业务在设计中做到前后版本兼容，否则滚动升级过程中新旧版本同时存在期间服务调用可能会导致业务失败、脏数据等问题，业务要根据自身特性与需求选择适合的升级方案。

　　来源： 移动Labs

  　　>>>>>>点击进入云计算专题