1.POD生命周期中的各个阶段

POD中明确规定了如下几个阶段

• Pending
  这个阶段说明该POD已经被kubernetes系统接收，但是在调度完成之前需要准备相关的条件，比如下载镜像，创建网络等。
• Running
  POD已经被明确调度到相应的node上，从scheudler层面讲已经完成"绑定动作"，内部所有的容器已经创建完成，并且最少有一个容器处于运行状态，其他的处于启动或者重启状态，如果POD中所有的容器都已经成功结束将不再执行重启动作。
• Succeeded
  POD中所有的容器都已成功结束，并且将不会重启，例如JOB或者初始化任务
• Failed
  POD中所有的容器已经结束，并且至少有一个容器结束失败，所谓的结束失败值得是容器的退出码不是0，或者是被系统强制退出的。
• Unknown
  这个情况主要是由于无法获得POD的状态，常见的原因是无法和pod所在的主机进行通信。

实际上还有一中状态Terminating，在代码和文档中都没有说明，但却是存在。这种情况出现杂无法获取所在主机的资源情况，一直在尝试建立连接。

[root@node1 yaml]# kubectl -n ovn-kubernetes get pod 
NAME                              READY   STATUS        RESTARTS   AGE
ovnkube-db-79f656485c-dkr87       2/2     Running       2          38h
ovnkube-master-7b4bb48cd5-rgl95   2/2     Running       15         38h
ovnkube-node-fqc44                0/3     Terminating   0          39m

2.POD的conditions

PodStatus中包含一系列的condition，condition是否通过决定着POD的状态，其中每个condition包含如下几个属性

lastProbeTime: 探针最后一次探测时间
lastTransitionTime：从上一个最近状态转化过来的时间
message：人为原因导致的转换信息
reason：最后一次状态转换的原因
status：当前condition的状态True，False， Unknown
type：PodScheduled（已经被调度到节点），Ready（服务已准备好可以提供服务，readiness 探针检测到后可以被添加到LB），Initialized(所有容器已经启动成功)，Unschedulable（由于资源或者约束没有合适的节点可调度），ContainersReady（所有容器都已准备好）

3.POD中容器的状态

Waiting:默认状态，如果容器即没有运行也没有终止就处于Waiting，处于Waiting状态的容器，一般是在拉去镜像，获取配置，认证等。
Running：表示容器没有任何问题，处于运行状态，并显示运行时间，此时postStart也被成功执行
Terminated：表示容器完成相关的动作或者由于某些原因而失败导致终止，不过都会显示退出码，以及开始时间和完成时间。同样的在进入这个状态之前preStop也会被执行。

4.POD中容器的hook

hook主要用于容器启动的各个环节做相应的处理动作，容器的hook主要有两个

• PostStart
  这个hook会在容器被创建后立即执行，但是不能保证其优先于容器的ENTRYPOINT。没有任何参数传递。
• PreStop
  在容器被终止之前执行，如果已经处于终止或者完成状态执行会失败。该动作是阻塞的,也就是说该动作时同步的。同样没有任何参数传递。

应用场景

数据初始化，优雅退出等

实例

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-hook-demo
spec:
  containers:
  - name: lifecycle-hook-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", " echo excute after container is created > /usr/share/message"]
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

5.POD中的探针

READINESS

• 作用
  Readiness 探针的目的是让 Kubernetes 能够知道你的什么时候能提供服务。如果Readiness 检测失败，那么外部的流量是无法到达应用对应的pod（实际上是在iptabless中将相应的转发drop掉），直到Readiness 检测成功，请求才会被转发下去到达相应的pod。

• 使用场景
  假如应用启动时比较耗时或者说启动完成后需要做很多预处理的工作（比如加载相关数据到内存），那么即便在应用的进程跑起来之后也不能立即对外提供服务，也就是应用并没有完全准备好，需要数据加载完成后，那么此时READINESS就可以用来探测你的数据是否加载完成。

LIVENESS

• 作用
  Liveness 探针主要是让 Kubernetes 知道你的应用是否存活（注意存活和是否能提供服务是两回事），以便执行相应的动作，具体的动作取决于相应的策略。默认情况下，如果是挂掉的，Kubernetes 会移除异常的 Pod，并重新拉起新的Pod 。

6.POD中的重启策略

策略针对POD内的所有容器有效，相对POD内的容器属于全局配置，但不是所有节点，只和节点上的一个POD相关。重启的周期随着次数变化（10s, 20s, 40s ）

• Always（默认值）
• OnFailure
• Never