3.2.2 优雅更新

对于云上k8s应用，我们在日常维护和实施部署的时候，经常性的由于新功能，新版本，新接口问题需要对副本进行更新发布。由于k8s本身的限制，最小化的流量控制的精细颗粒度为SVC，无法对单个pod进行流量管理(其实我们可以借助其他手段，比如istio实现，这里不做过多陈述）。同时对于k8s来说，发布就是删除老的pod，新建pod的过程，那么对于这些老pod上跑的流量，如何实现优雅关闭？新的流量如何保证是路由到新pod？如何确定新pod的业务程序是在ready后才会承接流量？等等这些是我们在部署应用的时候需要考虑的方面。在了解这些之前，我们首先需要了解整个pod的生命周期相关参数。

图：pod生命周期示意图

Init Container

Init 容器是一种特殊容器，在 Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。

init C本身有如下特点：

•它们总是运行到完成。

•每个都必须在下一个启动之前成功完成。

•同时 Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe， 因为它们必须在 Pod 就绪之前运行完成。(如上图所示)

•如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。 每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时， Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。

•基于有效 limit/request 完成调度，这意味着 Init 容器能够为初始化过程预留资源， 这些资源在 Pod 生命周期过程中并没有被使用。

•Pod 的 有效 QoS 层 ，与 Init 容器和应用容器的一样。

如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 然而，如果 Pod 对应的 restartPolicy 值为 "Never"，并且 Pod 的 Init 容器失败， 则 Kubernetes 会将整个 Pod 状态设置为失败。

《企业级云原生白皮书项目实战》——第三章 容器——3.2 业务部署——3.2.2 优雅更新（下） https://developer.aliyun.com/article/1229320?groupCode=supportservice