K8S多节点部署状态下，采用滚动升级策略，可以保证服务稳定运行，平滑升级，流程如下：

1. 新创建Pod节点N1，运行启动探测，直至启动成功
2. N1启动成功后，开始接收流量
3. 关闭老Pod节点O1，直至关闭结束
4. 再创建一个Pod节点N2，重复以上流程，以此类推

升级策略

想要达到文章开头的效果，使用如下的升级策略：

• 不可用Pod最大数量：0 个
• 超过期望的Pod数量：1 个
• 最小准备时间：30秒（待验证）

能够使得： 1) 老Pod在新Pod启动成功之前不会销毁 2) 每次滚动升级1个Pod，1个成功之后销毁原Pod再新建一个新Pod 3) （待验证）最小准备时间，来延缓多个Pod之间的启动间隔，因为JVM启动之后，刚开始执行调用请求效应速度很慢，需要预热一段时间达到最高效率

接口探测参数详解

路径

可以使用SpringBoot的健康检查增强包，也可以使用自定义的Controller接口来作为启动成功的验证接口。

端口

Pod对外开放的请求端口。

延迟探测时间

从开启启动Pod开始，到执行探测接口之间的间隔时间，设置这个时间可以保证在执行探测的时候，JVM已经启动成功，且做好了接收请求的准备。

执行探测频率

多长时间执行一次探测动作

超时时间

等待接口返回的最大时间

健康阈值

如果探测接口未超时且返回成功，就标记为成功；当成功次数超过健康阈值，就不再进行探测了。 这个参数只需要在启动探测的策略上配置即可。

不健康阈值

如果探测接口超时或者返回失败，就标记为失败；当失败次数超过不健康阈值，就会重启Pod。

接口探测的必要性

启动探测

不加启动探测的时间：

2022-12-02 17:33:00
2022-12-02 17:33:01

加启动探测的时间：

2022-12-02 17:21:03
2022-12-02 17:25:04

结论：需要配置启动探测，保证上一个Pod启动且Pod的JVM启动成功才会升级下一个Pod， 避免虽然所有Pod都是running状态但是JVM尚未启动成功，导致服务异常的问题。

健康检查接口

健康检查组件选择：Spring 提供的健康检查组件 或者 自己开发一个 RESTful 的测试接口。 spring组件的优点是集成度高、功能丰富；缺点是可能存在潜在的安全漏洞； 自研测试接口的优点是定制化程度高、安全；缺点是覆盖全部功能的话开发量大。

当前采用的是自研接口，只测试 controller 层接口是否准备完成； 如果采用 Spring 组件，那么需要在 微服务网关层 或者 安全部门的WAF层 屏蔽相关接口的访问。

各种检查的关系

1) 健康检查会在启动探测服务结束，也就是服务启动成功之后开始运行；
2) 就绪检查和健康检查都会在服务运行期间持续调用，只有启动探测在启动成功之后就不再运行；
3) 就绪检查的作用暂未体现出来，暂时不进行相关配置。

接口探测推荐配置

启动检查最佳实践

• 延迟探测时间（秒）：30
• 执行探测频率（秒）：3
• 超时时间（秒）：1
• 不健康阈值（秒）：200

健康检查最佳实践

• 延迟探测时间（秒）：300
• 执行探测频率（秒）：30
• 超时时间（秒）：1
• 不健康阈值（秒）：3

参考资料

• K8S滚动升级策略