对于一个Pod而言，从开始到结束,要经过很多点初始化则在其中，而初始化也需要一定的时间，如：Dockerfile中的ENTRYPOINT脚本，此脚本也需要运行时间，所谓的秒级启动，可能不包含这些，简述pod什么周期，如下图
其中，在容器内通常运行一个进程，而在pod中通常运行一个容器。在pod中的主容器运行之前是需要做一些环境设定，比如init-containers,在主容器启动之前，会运行一个环境初始化的容器，运行完成后就退出，并且初始化容器不单单只会是一个，多个初始化容器之间是串行执行的，当最后一个初始化容器执行完成并且退出后则主容器启动。在主容器启动时，也会进行环境初始化，如一些文件展开，启动服务等。在主容器刚刚启动后，用户可以手动嵌入做一些操作Post start,执行完成则退出。在主容器结束前，也可以做一些操作pre stop,这种做一些钩子来实现启动前的预设和结束后的清理。
在主容器执行的过程中，还可以做一些操作，在post start 完成后。如，健康状态监测。liveness probe ： 存活状态监测。readiness probe：就绪性状态检测。
- 存活探测
在kubernetes中是有两种探测，而Docker中则没有存活探测，因为如果docker不存活则结束，而在kubernetes中则不是，一个pod中存在多个容器，一个容器结束了，而pod则不存在问题的。为了探测某一个特定容器，特别是主容器是否运行正常，则需要存活性探测
- probe
无论哪一种probe都支持三种探测行为。第一种则是自定义操作第二种向指定的套接字发请求第三种向指定的http发请求，如：get响应码
然而，pod从创建到结束之前，一定处于某种状态之中。状态如下：
状态：Pending，调度尚未完成的挂起
running：运行状态
Failed：失败.
Succeeded：成功
Unknown：未知状态。pod的状态是API server与运行pod节点的kubelet通信来获取节点信息的， 如果kubelet本身故障，就得不到信息，Unknown- 创建pod过程
创建pod时候，请求会提交给apiserver,apiserver将请求的目标状态保存在etcd中，而后apiserver请求scheduler(scheduler负责挑选节点运行pod),调度成功则保存在etcd中，调度信息会更新到etcd的pod资源中的状态资源中。一旦信息存储在etcd中更新后，被调度节点（挑选的NODE）kubelet通过apiserver中的状态变化得知任务下发详情，此刻kubelet通过apiserver会拿到此前用户提交的资源创建清单，根据清单在当前节点上运行或者创建启动这个pod,如果运行或者创建成功或者失败， 它的当前节点状态会发回apiserver,apiserver随后存储在etcd当中.如下图：
现在，我们知道在pod的什么周期中的几种重要行为: 初始化容器，容器探测（liveness,readiness ），但是如果容器挂了又是如何处理的
restartPolicy
一旦pod中的容器挂了，则会有如下状态Always:：重启，延迟重启
- 一旦某个pod被调度到某个节点后，只要这个节点在，此pod便不会被重新调度，只会进行重启
其中，每隔一段时间，就会向liveness probe ，readiness probe发送探测 ，一旦故障，故障之后的操作取决于restartPolicy的状态Onfailure：只有状态为错误才重启Never： 不重启Default：
终止容器
在删除一个pod时候，并不会直接Kill掉。其中，当提交一个termination时，会向pod内的每一个容器，发送一个终止信号。而后pod内的容器会进行正常终止，但是这个正常终止并非无限期，他有一个时间宽限段，默认30秒（可另行指定），一旦在这个宽限的时间内没有终止，将会发送终止信号，强行终止默认情况下，所有删除在30秒内都是正常的。参考：https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods
