kubernetes平滑滚动升级服务 实现零宕机

背景
服务通过kubernetes上线之后，每次进行升级时，升级过程中总有一段时间（我们的服务宕机时间约为一分钟）内服务访问异常。

原因分析
经过分析确定，我们服务的从开始到最终启动成功约需要一分钟，服务的升级采用的时滚动升级，具体策略如下：

type: RollingUpdate
rollingUpdate:
  maxSurge: 1
  maxUnavailable: 0

通过以上策略进行服务升级时，会先启动新的pod，待新的pod启动成功之后，然后删除原有的pod。我们不难发现这儿存在这以下问题

• 新的pod启动成功时，开始停止旧的pod，新的pod启动成功，也就是我们看到的running状态，并不以为着我们的服务是正常的。这个时候如果杀死旧的pod，由新的pod开始接受请求显然会出现宕机情况，所以需要增加探针确保新的pod内部我们的服务已经正常可以接收并处理用户请求。

readinessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

这里我们探测服务的8080端口是否启动监听。经过验证，加上readinessProbe探针基本将宕机时间大幅缩减，readinessProbe会确保服务在你指定的探测命令执行成功的情况下才开始接受请求。
即便是服务的副本数只有1的情况下也不会出现长时间宕机，因为只有新的pod被探活成功，才会去停止旧有的一个pod，也即我们的服务被成功启动前，旧有的pod会一直存在处理请求的。

• 宕机的第二个原因时由于旧的pod停止时，pod的停止顺序导致的，这点在之前的文章中提过，详见 Kubernetes 优雅停止 Pod，Pod停止前处理设定任务的最佳方式

可通过preStop钩子来解决，注意根据特殊场景替换替换command脚本。

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 30"]

注： readinessProbe 和 lifecycle都位于 spec.template.spec.containers下

写在最后
我司专业专注各种服务器代理：
1 来自于阿里、腾讯等大厂开发人员免费答疑，针对您的使用场景规划最合理产品方案和架构，最大限度节约成本。
2.各类云服务器全网超低价。 联想、华为、阿里、腾讯等厂商指定合作代理公司，购买有保障。
以远低于原厂的价格享受原厂的服务！