k8s contianer 和pod的关系

最新推荐文章于 2025-11-11 14:47:21 发布

转载最新推荐文章于 2025-11-11 14:47:21 发布 · 1.3w 阅读

大数据专栏收录该内容

4 篇文章

订阅专栏

本文深入探讨了微服务架构下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的状态会略有不同。由于我们微服务没有采用其他两种策略，因此不在此阐述。