Kubernetes1.3:POD生命周期管理

转:http://blog.csdn.net/horsefoot/article/details/52324830

(一)  核心概念

Pod是kubernetes中的核心概念,kubernetes对于Pod的管理也就是对Pod生命周期的管理,对Pod生命周期的管理也就是对Pod状态的管理,我们通过下面Pod相关的各个实体信息关系图可以分析出来kubernetes是如何管理Pod状态的。

(二)  结构体介绍

Pod这个结构体中有个变量Status,通过这个变量可以得到每个Pod的状态信息,这个Status变量对应的结构体是PodStatus,从图中可以看出来Pod状态信息同四个变量相关,分别是Phase、Conditions、InitContainerStatuses和ContainerStatuses,这四个变量分别表示Pod所在生命周期阶段、Pod生命周期需要满足的条件、Pod中所有初始化容器状态、Pod中所有应用容器状态。

变量Phase有五个可选的值,分别是Pending、Running、Succeeded、Failed和Unknown。

这个五个值的含义分别是:

1)       Pending:kubernetes已经开始创建Pod,但是Pod中的一个或多个容器还没有被启动。比如Pod正处在应该被分配到哪个节点上这个调度过程中,或者kubernetes还在从镜像仓库中下载Pod中容器镜像这个下载过程中。

2)       Running:kubernetes已经将Pod分配到节点上,并且Pod中的所有容器都启动了。还包括Pod中至少有一个容器仍然在运行状态,或者正在重新启动状态。

3)       Succeeded:Pod中的所有容器都处在终止状态,并且这些容器是自主正常退出到终止状态的,也就是退出代码为0,而且kubernetes也没有重启任何容器。

4)       Failed:Pod中的所有容器都处在终止状态,并且至少有一个容器不是正常终止的,也就是退出代码不为0,或者是由于系统强行终止的。

5)       Unknown:由于一些特殊情况无法获取Pod状态,比如由于网络原因无法同Pod所在的主机通讯。

变量Phase的取值还取决于结构体PodSpec中的RestartPolicy变量,这个RestartPolicy变量是用来设置Pod中容器重启策略的,包括三个可选值,分别是Always、OnFailure和Never。

这三个值得含义分别是:

1)       Always:表示对容器一直执行重启策略。如果不设置RestartPolicy,那么Always是默认值。

2)       OnFailure:表示在容器失败的时候重启容器。

3)       Never:表示在对容器不执行重启策略。

变量Conditions对应结构体PodCondition,在这个结构体中有两个变量Type和Status。变量Type表示有效的条件类型,变量Status表示每种类型对应的状态。

变量Type有三个可选的值,分别是PodScheduled、Ready和Initialized。

这三个值的含义分别是:

1)       PodScheduled:表示Pod处在调度过程中。

2)       Ready:表示Pod已经能够提供服务了。

3)       Initialized:表示Pod中所有初始化容器都已经成功启动了。

变量Status表示每种Type对应的状态,有三个可选的值,分别是True、False和Unknown。

这三个值的含义分别是:

1)       True:表示Pod处于某种类型的有效条件中。

2)       False:表示Pod不在某种类型的有效条件中。

3)       Unknown:表示kubernetes无法判断Pod是否在某种类型的有效条件中。

变量InitContainerStatuses和ContainerStatuses对应结构体ContainerStatus,记录Pod中所有初始化容器状态和所有应用容器状态,结构体ContainerStatus表示一个容器的状态,在这个结构体中变量State表示容器当前状态,变量State对应结构体ContainerState。结构体ContainerState中包括三个变量Waiting、Running和Terminated,分别表示等待状态、运行状态和结束状态,结构体ContainerState中三个变量只能有一个处在生效状态,如果无法确定哪个剩下,那么会选择等待状态。

变量Terminated对应结构体ContainerStateTerminated,结构体ContainerStateTerminated中有一个变量ExitCode,通过这个变量来记录上面提到的容器退出代码,如果容器正常退出那么退出代码为0,否则为其他值。

(三)  设置Pod生命周期

设置Pod生命周期,也就是设置结构体PodStatus中变量Phase的值,下面的流程图展示了如何设置变量Phase的值。

在kubernetes1.3的POD中,有两类容器,一类是系统容器(POD Container),一类是用户容器(User Container),在用户容器中,现在又分成两类容器,一类是初始化容器(Init Container),一类是应用容器(App Container),设置Pod生命周期需要使用到用户容器。

首先检查Pod中所有初始化容器状态,接着检查Pod中所有应用容器状态,接着根据这两类容器状态和RestartPolicy来设置Pod生命周期。

如下为根据具体不同的条件设置Pod生命周期的例子:

1.        如果Pod中存在任何一个初始化容器,当这个初始化状态是Terminated,并且这个初始化容器非正常退出,也就是退出代码不为0,并且RestartPolicy是Never,那么Pod生命周期为Failed。

2.        如果Pod中存在任何一个初始化容器,当这个初始化容器状态是Waiting,并且这个初始化容器上一次终止状态不为空,也就是LastTerminationState不为空,并且这个初始化容器上一次是非正常退出,也就是退出代码不为0,并且RestartPolicy是Never,那么Pod生命周期为Failed。

3.        如果Pod中存在任何一个应用容器,当这个应用容器状态是Waiting,并且这个应用容器上一次终止状态为空,也就是LastTerminationState为空,那么Pod生命周期为Pending。也就是说当Pod中有应用容器没有开始运行的时候,Pod生命周期为Pending。

4.        如果Pod中所有应用容器都不存在Waiting状态,或者Pod中存在Waiting状态的应用容器,但是这些应用容器上一次终止状态不为空,如果满足上面两种情况之一,并且Pod中存在一个Running状态的应用容器,那么Pod生命周期为Running。也就是说当Pod中所有应用容器都出于正常启动状态,并且存在一个状态是Running的应用容器时,那么Pod生命周期为Running。

5.        如果Pod中不存在Running状态的应用容器,当满足这个条件时,如果Pod中存在Terminated状态的应用容器,或者Pod中存在Waiting状态的应用容器,并且这些应用容器的上一次终止状态不为空,这时候如果RestartPolicy是Always,那么Pod生命周期为Running,也就是说Pod中所有应用容器都存在重启状态,这时候如果RestartPolicy不是Always,那么如果所有应用容器都正常终止,那么Pod生命周期为Succeeded,这时候如果RestartPolicy为Never,那么如果有一个容器处在失败状态,Pod生命周期就是Failed,这时候如果RestartPolicy是OnFailure,那么如果有一个容器处在重启失败状态,Pod生命周期就是Running。

6.        如果都不满足上面条件,那么Pod生命周期默认处在Pending状态。

时间: 2024-10-13 04:41:34

Kubernetes1.3:POD生命周期管理的相关文章

k8s的Pod状态和生命周期管理

Pod状态和生命周期管理 一.什么是Pod? 二.Pod中如何管理多个容器? 三.使用Pod 四.Pod的持久性和终止 五.Pause容器 六.init容器 七.Pod的生命周期 (1)Pod phase(Pod的相位) (2)Pod的创建过程 (3)Pod的状态 (4)Pod存活性探测 (5)livenessProbe和readinessProbe使用场景 (6)Pod的重启策略 (7)Pod的生命 (8)livenessProbe解析 一.什么是Pod? Pod是kubernetes中你可以

tomcat系列分析之生命周期管理初始化动作

tomcat中有很多组件,要对这些组件进行生命周期的管理非常困难,tomcat中采用的是抽象出一个生命周期管理接口,然后所有的组件都实现该接口,当父组件启动时,同事负责将子组件启动起来,从而完成整tomcat的初始.启动.结束等动作. 来看下tomcat启动的过程,首先构造Bootstrap类,调用其中的init方法,完成类加载器的初始化,方便后面加载类使用,然后调用其中的load方法,实际上tomcat真正的启动动作是由Catalina类完成的.而这其中在BootStrap中调用Catalin

Siemens PLM TeamCenter 9.1生命周期管理软件

Siemens PLM TeamCenter 9.1生命周期管理软件Teamcenter 在构建时充分考虑了可扩展性. 无论是需要小规模部署来支持单个站点的小型团队,还是拥有遍布全球的众多站点以及复杂供应链的大型企业,或者介于其间的任何公司,Teamcenter 灵活的体系架构都能满足您当前的业务需求,并能随着贵公司的增长而继续保持出色表现. 下载内容包括: Siemens PLM TeamCenter 9.1 32和64位 为多国语言版本 Disc3 和 Disc4安装包 Teamcenter

Java实现生命周期管理机制

先扯再说 最近一直在研究某个国产开源的MySQL数据库中间件,拉下其最新版的代码到eclipse后,启动起来,然后做各种测试和代码追踪:用完想要关闭它时,拉出它的STOP类想要运行时,发现这个类里赫然只写以下几行代码,于是我感觉瞬间受到了很多伤害. public static void main(String[] args) { System.out.println(new Date() + ",server shutdown!"); } 这个中间件启动和运行的时候,开启了监听,启动着

6、Khala的登录生命周期管理

khala能够对设备进行生命周期管理,并提供了与生命周期相关的接口,用户只需在具体的设备类型实现类中重写这些生命周期接口,即可享受khala对于生命周期管理的同时定制与业务相关的操作.具体接口解释如下: onLoginCheckMsg(): 进行登录检查,在此可以通过查询DB等方式检查登录设备账号是否合法,可以为连接设备设置设备ID(此ID必须唯一,将被视为设备key,若出现重复将执行onLoginFailureMsg,若未设置将以临时ID值作为ID key),若账号检查失败,设置失败回复消息并

[转载]DevOps建立全生命周期管理

全生命周期管理(ALM)领域作为企业DevOps实践的总体支撑,应该说是DevOps领域中最为重要的实践领域,也是所有其他实践的基础设施.现在很多企业都非常重视CI/CD自动化工具的引入和推广,但是对ALM的建设的重视程度并不够.CI/CD的火爆很大程度上是被Docker和DevOps的热潮带动的,但CI/CD自动化只是提升团队效率的一个环节,如果没有ALM工具的支撑,CI/CD也只是空中楼阁,无法起到整体优化团队工作效率的作用,甚至局部的效率提高还会造成团队的不适应甚至抵触.如果管理者看不到自

Android apk动态加载机制的研究(二):资源加载和activity生命周期管理

出处:http://blog.csdn.net/singwhatiwanna/article/details/23387079 (来自singwhatiwanna的csdn博客) 前言 为了更好地阅读本文,你需要先阅读Android apk动态加载机制的研究这篇文章,在此文中,博主分析了Android中apk的动态加载机制,并在文章的最后指出需要解决的两个复杂问题:资源的访问和activity生命周期的管理,而本文将会分析这两个复杂问题的解决方法.需要说明的一点是,我们不可能调起任何一个未安装的

viewpager中fragment的生命周期管理

viewpager中fragment的生命周期管理 - i_bobby - 开源中国社区 调试fragment的时候发现一个莫名其妙的事情,viewpager中包含4个fragment,其中第一个和第三个fragment是要联网取得数据的,如图: 界面刚进去的时候显示第一个fragment,通过log信息,我发现two fragment竟然"偷偷"走了一遍的生命周期!着实把我震惊了! 然后我滑动到two,发现第三个也"偷"了一遍生命周期,也就是说,手机在显示第二个不

助力绵阳市商业银行,打造高效项目生命周期管理平台

金融市场捷报连连,近日,TechExcel公司再次凭借产品和服务实力直签下绵阳市商业银行,打造项目全生命周期管理平台.DevSuite研发与项目管理平台为绵阳市商业银行员工提供了一套必不可少的信息化工具,大大提升研发管理效率. 绵阳市商业银行(绵阳市商业银行股份有限公司)是国有控股地方商业银行,成立于2000年9月,是中国(绵阳)科技城唯一一家国有控股法人金融机构.成立至今,绵阳市商业银行秉承"服务地方.服务中小"的企业宗旨,全力打造一流中小企业金融服务机构,不断开创科学发展新局面.2