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