Pod分为两类:
- 自主式Pod:这种Pod本身是不能自我修复的。当Pod被创建后(不论是由你直接创建还是被其它COntroller),都会被K8s调度到集群的Node上。直到pod的进程终止、被删掉。因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在八个Node上。Pod不会自愈。如果Pod运行的Node故障,或者是调度器本身故障,这个Pod就会被删除。同样的,如果Pod所在Node缺少资源或者Pod处于维护状态,Pod也会被驱逐。
- 控制器管理的Pod:K8s使用更高级的称为Controller的抽象层,来管理Pod实例。Controller可以创建和管理多个Pod,提供副本管理、滚动升级和集群级别的自愈能力。例如。如果一个Node故障,Controller就能自动将该节点上的Pod调度到其他健康的Node上,虽然可以直接使用Pod,但是在K8s中通常是使用Controller来管理Pod的。
注:每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的景象属于K8s平台的一部分,除了Pause容器,每个Pod还包含一个或者多个紧密相关的用户业务容器。
K8s涉及这样的Pod概念和特殊组成结构有什么含义?
- 在一组容器作为一个单元的情况下,难以对整体的容器简单地进行判断及有效地进行行动。比如,一个容器死亡了,此时是算整体挂了么?那么引入与业务无关的Pause容器作为Pod的根容器,以它的状态代表着整个容器组的状态。
- Pod里的多个业务容器共享Pause容器的IP,共享Pause容器挂载的Volume,这样简化了业务容器之间的通信问题。也解决了容器之间的文件共享问题。
Pod的持久性和终止
Pod的持久性:
Pod在设计支持就不是作为持久化设计的。在调度失败、节点故障缺少资源或者节点维护的状态下都会死掉会被驱逐。
通常,用户不需要手动直接创建Pod,而是应该使用Controller(例如Deployment),即使是在创建单个Pod的情况下。Controller可以提供集群级别的资源功能、复制和升级管理。
Pod的终止
因为Pod作为集群的节点上运行的进程,所以在不再需要的时候能够优雅的终止是十分必要的(相比Kill这种方式)。用户需要能够放松删除请求,并且知道他们何时会被终止,是否被正确的删除,用户想终止程序是发生删除Pod请求,在Pod可以被强制删除前会有一个宽限期,会发送一个TERM请求到每个容器的主进程,一旦超市,将向主进程发送KILL信号并从API server中删除,如果Kubelet或者container manager在等待进程终止的过程中重启,在重启后仍然会重试完整的宽限期。
示例过程如下:
-
用户发送删除Pod的命令,默认宽限期是30秒;
-
在Pod超过该宽限期后API server就会更新Pod的状态为dead;