kubenetes Pod生命周期详解 之 initC

1.生命周期

就是Pod从创建到销毁的一个过程

initc就是下载容器镜像和配置网络栈的过程，你想 容器都没下载玩，后续怎么运行？

initC 是初始化容器 而且是线性执行 1 执行完了 并且 状态码返回 0 成功了 才能执行2 

因为持续时间短，所以危险系数高的操作一般放里面

initC具有阻塞特性 比如 他可以等待某个 initC 执行成功 之前 一直阻塞，直到那个initC 执行完成 ，他才开始执行它的初始化。比如Java 进程 为一个 Pod  ,Mysql一个 Pod Java进程必须要等待MysqlPod初始化完毕了，才能启动，要不然启动没有数据库会报错的！！！

initC 状态结束 即将进入 MainC 

主容器 更像是 守护进程 一样的  不间断的持续运行 

initC 更像我们所谓的脚本类型 它是有退出时机的

mainC 也可以定义很多

mainC 可以并行运行同时存在

在创建容器的过程中它是并发执行的 ，

mainC 是理论上 设计上是允许共同执行的

当然在一些老的 kubenetes 版本里 ，镜像的下载的动作是线性执行的 就导致一个结果，我们看起来好像这一个pod的mainC，好像是线性执行的,其实是并行的,在新版的 kubenetes 的测试实验性里已经调整了一个实验状态,允许镜像的并发执行,能够达到真正的创建mainC的并行,Ok这个概念别搞混了

2.mainC

1.特性有哪些

1. 钩子
2. 探针

当前的每一个mainC里呢有两种类型 

1. 启动后 
2. 关闭前

每一个mainC 都有对应它的初始化

初始化完成后执行我们对应的启动命令

1.钩子 

钩子可以钩在启动后 和 关闭前

启动后

但是它是在初始化之后 执行的 命令 官方命名叫做启动后钩子,但是实际是在初始化之后 启动命令执行之前

钩子没有执行完成的时候 启动命令就开始执行了

官方话：我们并不能保证启动命令的执行的时候,启动后钩子已经完毕了

关闭前

关闭前钩子 关闭信号的执行

学Docker的 时候 关闭容器的时候 发送15号信号 如果发送15号信号多次以后没有被关闭 那就会发送9级别信号 强制杀死

所以我们关停我们的pod的时候也是想这些容器发送对应的关闭信号的,这是毋庸置