Pod状态及生命周期

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概念和特殊组成结构有什么含义？

1. 在一组容器作为一个单元的情况下，难以对整体的容器简单地进行判断及有效地进行行动。比如，一个容器死亡了，此时是算整体挂了么？那么引入与业务无关的Pause容器作为Pod的根容器，以它的状态代表着整个容器组的状态。
2. 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在等待进程终止的过程中重启，在重启后仍然会重试完整的宽限期。
示例过程如下：

1. 用户发送删除Pod的命令，默认宽限期是30秒；

2. 在Pod超过该宽限期后API server就会更新Pod的状态为dead；

3. 在客户端命令行上显示Pod状态为“