kubernetes pod&container生命周期浅析


前言

蜂巢(现已更名为网易云计算基础服务)上线的微服务有两大类,有状态和无状态,两者有很大区别,除了有状态服务可以挂盘、带公网这种比较表面的区别以外,其实它们在底层调用k8s的实现上也有很大区别。这里列出两个不同类型的服务的结构简图。

有状态服务:

无状态服务:

可以看出来pod无论在无状态服务和有状态服务都是一个核心概念。而在服务创建过程中pod的运行状态至关重要。跟服务的可用性息息相关。下面就简单分析一下pod的生命周期以及可能出现的状态。

POD生命周期

需要注意的是pod的生命周期和container的生命周期有一定的联系,但是不能完全混淆一致。pod状态相对来说要简单一些。这里首先列出pod的状态

  • 1、pending:pod已经被系统认可了,但是内部的container还没有创建出来。这里包含调度到node上的时间以及下载镜像的时间,会持续一小段时间。
  • 2、Running:pod已经与node绑定了(调度成功),而且pod中所有的container已经创建出来,至少有一个容器在运行中,或者容器的进程正在启动或者重启状态。--这里需要注意pod虽然已经Running了,但是内部的container不一定完全可用。因此需要进一步检测container的状态。
  • 3、Succeeded:这个状态很少出现,表明pod中的所有container已经成功的terminated了,而且不会再被拉起了。
  • 4、Failed:pod中的所有容器都被terminated,至少一个container是非正常终止的。(退出的时候返回了一个非0的值或者是被系统直接终止)
  • 5、unknown:由于某些原因pod的状态获取不到,有可能是由于通信问题。 一般情况下pod最常见的就是前两种状态。而且当Running的时候,需要进一步关注container的状态。下面就来看下container的状态有哪些:

Container生命周期

  • 1、Waiting:启动到运行中间的一个等待状态。
  • 2、Running:运行状态。
  • 3、Terminated:终止状态。 如果没有任何异常的情况下,container应该会从Waiting状态变为Running状态,这时容器可用。

    但如果长时间处于Waiting状态,container会有一个字段reason表明它所处的状态和原因,如果这个原因很容易能标识这个容器再也无法启动起来时,例如ContainerCannotRun,整个服务启动就会迅速返回。(这里是一个失败状态返回的特性,不详细阐述)

当一个容器已经运行起来以后,pod和container的状态是如何关联起来的呢,下面给一些举例来更加形象化其中的关系。

Example

  • 1、Pod是running的,1个容器,容器成功exit。需要关注是否会自动拉起,目前微服务中容器退出会自动拉起,所以容器会自动restart,pod持续保持Running。
  • 2、Pod是running的,1个容器,容器异常exit。目前微服务容器也会自动拉起,pod持续保持Running。
  • 3、Pod是running的,container OOM退出了,容器自动拉起,pod持续保持Running。
  • 4、Pod是running的,disk挂掉了,pod变成Failed。
  • 5、Pod是running的,node出现了段错误或者内存溢出等错误,pod变成Failed。

需要注意的是这里都是基于重启策略是always的方式。而kubernate本身实际上是支持多种重启策略的。包括Onfailue,Never这其他两种,分别代表只有错误退出的时候才拉起,以及从不拉起的策略。其他两种策略下continer退出的话pod的状态会略有不同。由于我们微服务没有采用其他两种策略,因此不在此阐述。

总结

pod和container的状态让我们对微服务底层的对象和状态有了更加深入的认识,并且有利于帮助定位问题。

本文来自网易实践者社区,经作者崔晓晴授权发布。