Unkown：API Server 无法正常获取到 Pod 对象的状态信息，通常是由于其无法与所在工作节点的 kubelet 通信所致。
Pod 相位是在其声明周期的宏观概述，而非对容器或 Pod 对象的综合汇总，而且相位的数量和含义被严格界定，它仅包含上面列举的相位值。
二、Pod 的创建过程
Pod 是 Kubernetes 的基础单元，理解它的创建过程对于了解系统运作有很大帮助。
1）用户通过 kubectl 或其他 API 客户端提交 Pod Spec 给 API Server。
2）API Server 尝试着将 Pod 对象的相关信息存入 etcd 中，待写入操作执行完成，API Server 即会返回确认信息至客户端。
3）API Server 返回 etcd 中的状态变化。
4）所有的 Kubernetes 组件均使用 "watch" 机制来跟踪检查 API Server 上的相关的变动。
5）kube-scheduler（调度器）通过其 "watch" 觉察到 API Server 创建了新的 Pod 对象但尚未绑定至任何工作节点。
6）kube-scheduler 为 Pod 对象挑选一个工作节点将结果更新至 API Server。
7）调度结果信息由 API Server 更新至 etcd 存储系统，而且 API Server 也开始反映此 Pod 对象的调度结果。
8）Pod 被调度到的目标工作节点上的 kubelet 尝试在当前节点上调用 Docker 启动容器，并将容器的结果状态送至 API Server。
9）API Server 将 Pod 状态信息存入 etcd 系统中。
10）在 etcd 确认写入操作成功完成后，API Server 将确认信息发送至相关的 kubelet，事件将通过它被接受。
三、Pod 生命周期中的重要行为
除了创建应用容器（主容器及其辅助容器）之外，用户还可以为 Pod 对象定义其生命周期中的多种行为，如初始化容器、存活性探测及就绪性探测等。
1、初始化容器
HTTPGetAction：通过向容器 IP 地址的某指定端口的指定 path 发起 HTTP GET 请求进行诊断，响应码为 2xx 或 3xx 时即为成功，否则为失败。
任何一种探测方式都可能存在三种结果："Success"（成功）、"Failure"（失败）或 "Unknown"（未知），只有第一种结果表示成功通过检测。 存活性检测：
用于判定容器是否处于 "运行"（Running）状态；一旦此类检测未通过，kubelet 将杀死容器并根据其 restartPolicy 决定是否将其重启；未定义存活性检测的容器的默认状态为 "Success"。 就绪性检测：
用于判断容器是否准备就绪并可对外提供服务；未通过检测的容器意味着其尚未准备就绪，端点控制器（如 Service 对象）会将其 IP 从所有匹配到此 Pod 对象的 Service 对象的端点列表中移除；检测通过之后，会再次将其 IP 添加至端点列表中。
四、容器调度重启策略
容器程序发生崩溃或容器申请超过限制的资源等原因都可能会导致 Pod 对象的终止，此时是否应该重建该 Pod 对象则取决于其重启策略（restartPolicy）属性的定义。
1）Always：但凡 Pod 对象终止就将其重启，此为默认设定。
2）OnFailure：仅在 Pod 对象出现错误时方才能将其重启。
3）Nerver：从不重启
提示：
restartPolicy 适用于 Pod 对象中的所有容器，而且它仅用于控制在同一节点上重新启动 Pod 对象的相关容器。
首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作由 kubelet 延迟一段时间后进行，且反复的重启操作的延迟时长依次为 10秒、20秒、40秒、80秒、160秒 和 300秒，300秒是最大延迟时长。
Pod 一旦绑定到一个节点，Pod对象将永远不会被重新绑定到另一个点，它要么被重启，要么终止，直到节点发生故障或被删除。
五、Pod 的终止过程
Pod 对象代表了在 Kubernetes 集群节点上运行的进程，它可能曾用于处理生产数据或向用户提供服务等，但是，当 Pod 本身不再具有存在的价值时，如何将其优雅地终止就显得尤为重要了，而用户也需要能够在正常提交删除操作后可以获知其如何开始终止并最终完成。
操作中，当用户提交删除请求后，系统就会进行强制删除操作的宽限期倒计时，并将 TERM 信息发送给 Pod 对象的每个容器中的主进程。宽限期倒计时结束后，这些进程将啊收到强制终止的 KILL 信号，Pod 对象随即也将由 API Server 删除。如果在等待进程终止的过程中，kubelet 或容器管理器发生了重启，那么终止操作会重新获得一个满额的删除宽限期并重新进行删除操作。·
一个典型的 Pod 对象终止流程具体如下：
1）用户发送删除 Pod 对象的命令。
2）API 服务器中的 Pod 对象会随着时间的推移而更新，在宽限期内（默认 30秒），Pod 视为 "dead"。
3）将 Pod 标记为 "Terminating" 状态。
4）（与第 3 步同时运行）kubelet 在监控到 Pod 对象转为 "Terminating" 状态的同时启动 Pod 关闭过程。
5）（与第 3 步同时运行）端点控制器监控到 Pod 对象的关闭行为时将其从所有匹配到此端点的 Service 资源的端点列表中移除。
6）如果当前 Pod 对象定义了 preStop 钩子处理器，则在其标记为 "terminating" 后即会以同步的方式启动执行；如若宽限期结束后，preStop 仍未执行结束，则第 2 步会被重新执行并额外获取一个时长为 2 秒 的小宽限期。
7）Pod 对象中的容器进程收到 TERM 信号。
8）宽限期结束后，若存在任何一个仍在运行的进程，那么 Pod 对象即会收到 SIGKILL 信号。
9）Kubelet 请求 API Server 将此 Pod 资源的宽限期设置为 0 从而完成删除操作，它变得对用户不再可见。
默认情况下，所有删除操作的宽限期都是 30秒，不过， kubectl delete 命令可以使用 "--grace-period="选项自定义其时长，若使用 0 值则表示直接强制删除指定的资源，不过，此时需要同时为命令使用 "--force" 选项。
