Part01.升级策略在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实现服务高可用。Part02，健康检查K8S通过探针对容器进行周期性诊断，判断容器的状态。通常使用livenessprobe和readinessprobe来根据容器状态进行后续处理。livenessProbe：探测容器是否在运行。如果liveness探测失败，kubelet将杀死容器并且容器将服从其重启策略。如果容器不提供livenessprobe，则默认状态为Success。readinessProbe：探测容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与Pod匹配的所有服务的端点中删除Pod的IP地址。初始延迟之前的就绪状态默认为失败。如果容器不提供就绪探测，则默认状态为成功。在业务中，我们经常同时使用这两个探头。生存性探针用于判断容器是否需要重启以实现自愈，就绪性探针用于判断容器是否准备好对外提供服务。Part03，K8S滚动升级原理K8S通过Deployment创建副本。Deployment是一个三级结构：Deployment控制Replicaset（副本集），Replicaset控制Pod。根据Deployment的结构特点，一个Deployment下可以存在不同的Replicaset，也就是说一个Deployment下可以同时存在不同镜像版本的Pod。在升级过程中，Deployment会自动创建一个Replicaset，Replicaset通过滚动升级策略中的maxSurge和maxUnavailable这两个参数来精确控制每次滚动的Pod数量。结合健康检查中的liveness探针和readiness探针，准确判断Pod何时成功启动，何时准备好服务请求，保证所有可用的Pod在升级过程中正常提供服务。具体过程如下图所示。K8S滚动升级流程Part04.总结本文介绍了K8S中的升级策略和健康检查。通过配置升级策略和健康检查实现滚动升级，保证微服务的顺利部署。但是，滚动升级也对业务设计提出了更高的要求。为了满足需求，业务在设计上需要兼容之前的版本。否则在滚动升级过程中，新旧版本并存时，服务调用可能会导致业务失败和脏数据。业务应根据自身特点和需求选择合适的升级方案。参考：kubernetes中文文档：http://docs.kubernetes.org.cn/317.html
