当我们向k8s 集群中提交了应用部署YAML文件之后,k8s 驱动调度器给pod分配一个可用的工作节点,接着工作节点的kubelet 组件驱动容器运行时,把对应的pod运行起来,pod 的生命周期被分为三个阶段如下图所示:
在这里插入图片描述
如上图所示,pod的整个生命周期被分成三个阶段,其中在初始化阶段(春天),执行初始化容器,完成环境初始化和数据初始化工作;接着是运行阶段,这个阶段容器正常运行,对外提供服务,这个是容器生命周期的夏天;如果pod实例被删除,容器实例收到关闭信号,容器和pod 最终会退出(秋冬)。

在初始化阶段,初始化容器最先运行,并且严格按照pod 对象的init Containers域定义的顺序依次执行。从时间顺序的角度看,初始化容器被启动后,做的第一件工作就是从镜像仓库pull 容器镜像实例到工作节点上,而容器定义中的imagePullPolicy 字段控制镜像的拉取策略,比如是每次都来去最新的镜像实例,还是只在第一次拉去或从来都拉去镜像(最后一种看起来有点违反直觉,实际上在生产环境非常有用,因为我们必须控制生产环境镜像的版本。笔者在编写文章中案例的时候,大部分时间也是关闭自动拉取,来节省带宽)。

1.k8s 提供的三种镜像拉取策略详细描述如下:

1.not specified(未指定策略),如果我们使用了:latest 标签那么默认就是Always;其他标签默认的策略 是IfNotPresent

2.Always策略,容器实例每次启动或者重启,都会从仓库拉取最新的的镜像数据,如果工作节点的本地缓存中已经有指定的版本,虽然说不会下载,但是还是会和仓库镜像通信。

3.Never 策略,容器镜像已经在工作节点的缓存中,不从仓库下载,设置这种策略的时候,我们必须保证指定的镜像已经存在工作节点上,比如另外一个容器已经运行过这个镜像,或者镜像就是在这台节工作节点上,比如另外一个容器已经运行过这个镜像,或者这个镜像就是在这台工作节点上通过docker build 构建的,甚至是管理员手动docker pull 过这个镜像。

4.IfNotPresent策略: 如果指定的经i昂不在工作节点的缓存中,那么就从仓库下载,这个策略确保镜像只有在工作节点上第一次执行的时候,才会从仓库下载。

镜像拉取策略不光在容器启动的时候起作用,在容器重启的时候,也会基于配置的拉取策略来确定是否要重新下载镜像数据,为了让大家对这三种镜像拉取策略有直观的感受,看下图:
在这里插入图片描述
注意: 如果容器的imagePullPolicy 被设置为Always ,但是镜像仓库无法连接,即便是本地有指定版本的镜像数据,容器也无法顺利启动。因此设置为Always 本质上给应用增加了 外部依赖,如果仓库不可用,应用就无法启动,特别是在需要重启的时候,会造成系统的稳定性问题。

1.深入理解运行阶段1

当镜像被成功pull 到工作节点上之后,初始化容器就开始运行。初始化容器按照YAML文件中定义的顺序,一个接一个执行,具体来说第一个初始化容器运行成功之后,接着下载第二初始化容器的镜像,然后开始运行,这个过程会循环一直到最后一个初始化容器运行的时候出现问题,比如 退出后返回码未非0,那么初始化容器就会被重新启动,如下图所示:
在这里插入图片描述
如上图所示,初始化容器运行失败(退出码为非0),并且pod 的重启策略是Always或者Onfailure,那么运行失败的初始化容器就会被重新 启动,如果重启策略是Never,后续初始化容器就没有机会运行了,Pod的Status就会被设置未Init:Error,对于运维和开发人员来说,就需要手动删除这个对象,然后重新创建以达到重新启动应用程序的目的。

初始化容器一般情况下,只需要被执行一次,即便是Pod中的应用容器实例有异常被k8s 退出并重启,这种情况下,初始化容器也不会再次执行。但是在特殊情况下,如果k8s 决定重建pod ,那么初始化容器就会被再次执行 ,这就意味着我们在初始化容器中做的工作,必须考虑幂等性。

3.深入理解运行阶段2

当所有的初始化容器都成功运行,pod 中定义的主容器进程(应用程序),才开始运行,大家需要注意的是,如果pod中定义了多个容器(比如笔者前面的文章中Spring cloud 应用容器和Envoy容器的例子),那么这些容器实例并行启动。理论上容器实例之间没有相互依赖,但是情况并不总是如此,请继续阅读。

从源代码的角度来看,kubelet 并不是同时启动所有的容器实例 ,而是基于我们提交的YAML 文件中容器的定义顺序来逐个启动容器实例。如果一个容器定义了post-start hook,并且我们知道这个hook 进程和定义它的容器是并行运行的,因此如果hook 进程执行的过程中出现问题,那么这个hook 不光会影响定义它的容器进程,也会影响这个容器后边定义的容器实例 的启动。

注:post-start hook 以及kubelet 按顺序启动每个容器实例属于具体代码实现层面的原理,k8s 在后续的版本中可能优化实现逻辑,因此大家了解 即可。作为对比,所有容器 实例退出过程是并发执行,长时间运行的pre-stop hook 的确会block 定义它的容器实例退过程,但是不会影响其他的容器实例。容器定义的多个pre-stop hook 会被同时触发开始执行。

在运行阶段,每个容器是按照:
1.拉取镜像
2.容器实例启动
3.当容器退出时,基于配置的重启策略,进行重启
4.一直运行到pod 被删除后,容器收到TERM 信号,这样的顺序运行,接下里我们详细聊聊这个执行的顺序。

基于配置的imagePullPolicy,应用程序容器启动后会首先从镜像仓库拉取数据,当镜像数据ready 后,容器实例就会被创建。如笔者前面的介绍,容器实例并不是被同时启动,并且由于每个容器实例不同,镜像的大小不同,因此pull 镜像到本地需要的时间也不同,的确还存在某个容器还在下载镜像,而pod中其他容器都应成功启动运行的场景。

当容器中的主进程启动成功后,整个容器实例就成功启动了,如果为我们定义了post-start hook ,那么这些hook 会和 主容器进程并发执行,并且hook 执行成功过后,主容器进程才会继续运行,要不然会被block.我们还可以为容器定义startup probe,当startup probe成功后,才会触发liveness prode(存活探针)设定的健康检查。

当startup prode 或者liveness prode 连续多次探测到容器的健康状态是false ,那么会被退出,pod 定义的restartPolicy策略决定了容器是否 需要重新启动。如果pod 的restartPolicy 被设置为Never, 并且startup hook 执行失败,podd的状态会被设置为completed,即便是post-start hook 运行失败,这个非常让人confuse.

容器退出的时候,pre-stop hook 会被触发,因此容器可以实现我们所说的优雅退出模式,当pre-stop hook 执行完成,TERM 信号会被发送给容器中的主进程,k8s 会给主进程一段时间来完成退出工作。这个时间可以通过terminationGracePeriodSecond来设置,默认情况下是30s,这个时间的计时,会从pre-stop hook被调用开始,如果在设定时间内进程尚未完成退出,k8s 会通过kill 信号来强制退出,如下图所示:
在这里插入图片描述

容器成功退出后,k8s 会基于pod 上配置的重启策略,如果重启策略是不重启,那么容器就会一直在terminated 状态,即便是其他容器都在正常运行,直到pod 退出或者运行失败为止。

4.深入理解pod 的退出阶段

pod 中的容器会一直运行下去,直到我们删除了pod 对象,当我们删除pod 对象后,pod 中所有的荣光其就开始执行退出流程,并且状态设置为terminating .

容器退出流程本质上是和liveness prode 连续几次失败退出的流程基本一致,除了pod 的deletetion-grace-peroid 这个参数设置了容器有多少时间来完成退出流程。

grace peroid 通过POD 的参数metadata.deleteGracePeriodSeconds来设定,当我们删除pod 的时候,我们可以指定这个参数的值,来修改默认从spec.terminationGracePeriodSecond读取到的值;
如下图所示,POD中多有容器实例基本同时触发退出流程,对于每个容器实例,如果定义了pre-stop hook,那么会先调用pre-stop hook,然后发送TERM信号给主容器进程,如果在优雅退出等待时间内进程尚未退出,那么Kubernetes会发送KILL信号来强制退出进程。当POD所有的容器进程都停止运行后,POD对象会被最终删除。
在这里插入图片描述

为了让大家对退出机制有直观的了解,我们可以通过yunpan-ssl这个POD来实际观察一下整个退出的过程。如果这个POD没有启动,请通过命令kubectl apply -f yunpan-ssl.yaml来首先启动应用程序。

接着我们在自己本地环境上执行kubectl delete pod yunpan-ssl,你如果计算了从按回车到命令返回之间的消耗的秒数,你会发现删除时间略长(大概在数十秒)。我们来分析一下为啥要这么长时间?由于我们并未给yunpan-ssl中的容器定义pre-stop hook,因此当执行delete命令的时候,这些容器会立即收到TERM信号,而由于我们并未修改terminationGracePeriodSeconds设置,因此这个值默认是30秒,也就是最长要等30秒,Kubernetes才会强制退出。为了让退出的时间更快一下,我们来修改terminationGracePeriodSeconds这个参数,如下图所示:

在这里插入图片描述

如上图所示,pod的terminationGracePeriodSeconds字段被设置为5秒,这样当我们创建这个POD并删除时,大概只需要5秒就可以完成POD的删除。

注:其实在实际项目中,修改terminationGracePeriodSeconds参数不太常见,但是笔者到建议如果应用进程退出过程非常重,需要更多时间的话,可以适当增大这个时间配置。另外除了在YAML文件中指定,我们还可以直接在delete命令中修改默认容忍时间:kubectl delete pod yunpan-ssl --grace-period 10,这样的话,terminationGracePeriodSeconds参数会被覆盖为10秒。一个特例是,如果–grace-period被置为0,那么pre-stop hook就不会执行。

好了,我们来总结一下POD生命周期介绍的所有相关内容,下图是笔者总结的关于POD生命周期中初始化阶段的所有内容:

在这里插入图片描述

当初始化阶段完成后,应用容器实例便开始运行,如下图所示:
在这里插入图片描述
基于上边两个图,我们来总结一下POD和容器的全生命周期内容:

1,POD对象的状态信息包含:pod的phase,conditions以及运行在其中的每个容器的状态status信息。我们可以通过kubectl describe命令来查看POD对象的全量信息,或者通过kubectl get pod xx -o yaml。

2,基于POD的重启策略,运行在POD中容器在失败退出后,可能会被”重启“。实际上,容器没有重启的概念,Kubernetes会销毁老的实例,然后创建一个新的额实例来取代老的实例。

3,如果容器实例频繁重启,Kubernetes后组的启动时间会指数级回退。具体来说,第一次重启不会有任何延迟,第二次延迟10秒,第三次20秒,依次类推。上限是5分钟。如果容器正常运行了10分钟,那么这个回退值会清零。

4,指数级回退策略也被用在容器从仓库pull镜像的场景下。

5,给应用容器配置liveness probe可以在出现异常的时候,重启容器实例,liveness提供httpGET,tcpSocket和exec三种模式。

6,如果应用程序需要比较长的启动时间,我们可以给容器定义startup probe,这样就可以给容器足够的时间来启动,不然会进入无限重启恶性循环中。

7,我们可以为每个容器定义lifecyle hook,Kubernetes提供了两种类型。其中post-start hook在容器启动的时候被触发,而pre-stop hook是在容器关闭推出的时候被触发,lifecycle hook提供httpGet和exec两种模式。

8,如果我们为容器定义了pre-stop hook,那么当容器退出的时候,pre-stop hook会先执行。然后Kubernetes会发送TERM信号给容器的主进程,如果进程在配置的terminationGracePeriodSeconds时间内没有退出,那么Kubernetes会强制KILL掉进程。

9,当我们删除POD对象的时候,所有运行其中的容器开始并行退出。POD对象的deletionGracePeriodSeconds字段提供了容器有多长时间来执行退出,默认情况下这个值读取自termination period字段,但是我们可以在执行delete命令的时候重写。

10,如果应用退出需要较长时间,可能原因是运行在POD中的某个容器没有很好的处理TERM信号,给应用增加处理TERM信号的逻辑,而不缩短termination或者deletion grace period参数。

以上就是笔者在过去的几篇文章中的知识要点,读者可以看看是否和自己理解的一致,如果有任何疑问,可以回到前边文章重新阅读。好了,今天的内容就这么多了。云原生的概念笔者反复强调过多次,特别是云原生和元计算的这两个概念的区别需要大家有清晰的认知,具体来说,云计算是解决我们的应用在哪里运行问题,而云原生是解决如何让我们的应用使用云计算带来的红利,比如说扩展性,灵活性等。而扩展性和灵活性需要应用无状态,但是对于业务系统,不可能无状态,要不然就没有啥用了,因为业务的核心其实就是数据的流转,而数据的变化一定会产生状态。云原生说的应用无状态其实是指将状态进行统一管理,比如配置,数据等。因此云原生引用有状态,只是我们通过将状态代理给数据库以及存储系统来处理而已。存储卷是我们状态持久化的一种方案,因此我们从下篇文章开始介绍数据存储,敬请期待!

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐