服务平滑发布方案

服务平滑发布，核心点 2 个。

1. 保证旧节点销毁的时候，先处理完已接入的请求。
2. 保证新节点服务可用时再上线。（不是服务启动成功，如果是服务可用，可以对外提供服务。）

我们现在不平滑的原因：

1. 服务发布过程中速度太快造成了不稳定。
2. 服务下线的生命周期没有配置。

主要是更新策略的配置，会同时启动和销毁多个 Pod。

  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate

更改后有所缓解。

  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate

同时我们配置不够用，监控表示，新 Pod 发布的 3 ~ 5 分钟内，CPU 处于高峰状态，我们的就绪检测，在 1分钟 ~ 1.5分钟完成就绪接入流量，此时 CPU 占用还在还未平稳，接入流量后负载直线上升，当负载接近 limit 时，存活检测的请求无法及时响应，失败三次后，K8s 认为服务已挂，重启镜像。

Pod 在稳定后的 CPU 占用在 0.1~0.3。只有在发布的 3 ~ 5 分钟高负载。

推荐处理方式：

1. 将 request 保持 0.5CPU，limit 2CPU。加快新 Pod 启动速度。
2. 拉长就绪检测的间隔时间，保证服务启动成功 CPU 稳定后再接入流量。
3. 增加存活检测的超时时间和连续失败次数。
4. Pod 的生命周期新增销毁前的延迟处理。