Pod生命周期和健康检查

Pod的生命周期涵盖了前面所说的PostStart 和 PreStop在内

Pod phase

Pod的status定义在 PodStatus对象中，其中有一个phase字段。

Pod的运行阶段是Pod在其生命周期中的简单宏观概述。

下面是phase可能的值：

Pending 挂起：该状态标识Pod没有调度到节点上，可能下载镜像耗费时间，容器还未启动。
Running 运行中： Pod已经绑定到一个节点上，Pod中的容器已经全部创建，至少有一个容器正在运行，或者证处于启动状态或重启状态。
Succeeded 成功： Pod中所有的容器都被成功终止，并且不会被重启。
Failed 失败：Pod中的所有容器都已经终止了，并且至少有一个容器是因为失败终止。容器退出状态非0或被系统终止。
Unknown 未知：因为某些原因无法取得Pod状态，通常因为与Pod所在节点失去通信造成失联。

Pod 状态

Pod 有一个 PodStatus 对象，其中包含一个 PodCondition 数组。 PodCondition 数组的每个元素都有一个 type 字段和一个 status 字段。type 字段是字符串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。status 字段是一个字符串，可能的值有 True、False 和 Unknown。

Pod健康检查

查看官网文档，探针是有kubelet对容器状态的一种定期监控和检查，要执行诊断，kubelet可以调用由容器实现的Handler。有三种执行方式：

HTTPGetAction(http)：对指定端口和路径上的容器的IP地址执行HTTP Get请求。如果状态码大于等于200且小于400，则认为诊断成功。
ExecAction(exec): 在容器内部执行指定命令，执行后退出状态码为0则诊断成功。
TCPSocketAction(tcp:): kubelet 对指定容器IP和Port进行TCP检查，如果端口打开，则被认为诊断成功

诊断状态有三种：

成功：容器状态健康，通过了检测
失败：容器未通过诊断
未知：诊断失败，不会采取任何行动

容器探针

供kubelet对容器诊断的探针有两种：

LivenessProbe: 存活探针，指容器是否正在运行。如果检测失败，则kubelet会杀死容器，并且容器会受重启策略的影响而是否重启，如果容器不提供探针，则默认状态为success。
ReadnessProbe: 就绪探针，指容器是否准备就绪，接受服务请求。如果就绪探针失败，端点控制器将从与Pod匹配的所有service的端点中移除该Pod的IP 地址。初始延迟之前的就绪状态默认是Failure，如果容器不提供就绪探针，则默认状态为Success。

什么时候选择livenessProbe 存活探针和readnessProbe就绪探针？

如果容器中的进程能够在出现服务故障的时候自动崩溃，那么这种时候是不需要提供livenessProbe ，kubelet将根据Pod的restartPolicy自动执行正确的操作

如果希望容器在探测失败时被杀死并重新启动，那么请指定一个livenessPRobe存活探针，并指定restartPolicy为Always或OnFailure。

如果要在探测成功才开始向Pod发送流量，就需要指定一个readnessProbe 。在这种情况下，就绪探针可能和存活探针同时存在，这种情况下的readnessProbe意味容器在没有接受到任何流量的情况下启动，并且只有在探针成功后才接收流量。如果希望容器能够自行维护，那就指定一个readnessProbe探针，和livenessProbe探测不同的端点。

注意，如果只想在pod被删除时能够排除请求，则不一定需要使用就绪探针；在删除Pod时，Pod将自动将自身置于未完成状态，无论是否有就绪探针。当等待Pod中的容器停止时，Pod仍处于未完成状态。

模板使用exec方式

apiVersion: v1

kind: Pod

metadata:

  name: probe

spec:

  containers:

  - name: probe

    image: busybox

    argx:

    - /bin/sh

    - -c

    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600

    livenessProbe:

      exec:

        command:

        - cat

        - /tmp/healthy

      initialDelaySeconds: 5		#等待容器启动5秒后发起探针

      periodSeconds: 5				#发起探针的间隔5秒一次

使用kubectl 部署这个yaml文件，创建一个Pod,可以发现在启动完成后等待5秒后开始发起探针诊断，每隔5秒后发起一次诊断，而这里使用的是exec方式，在30秒后容器会执行删除/tmp/healthy 文件操作，这之后再发起探针诊断则诊断失败，容器将被kubelet 杀掉然后重启。

livenessProbe和readnessProbe一起使用

apiVersion: v1

kind: Pod

metadata:

  name: probe-http

  label:

    app: probe-http

sepc:

  containers:

  - name: probe-http

    image: nginx

    containerPort:

    - name: http

      port: 80

    livenessProbe:

      # 当没有定义 "host" 时，使用 "PodIP"

        # host: my-host

        # 当没有定义 "scheme" 时，使用 "HTTP" scheme 只允许 "HTTP" 和 "HTTPS"

        # scheme: HTTPS

        path: /		#路径可以是想要检查的能访问到的任何路径，如：/healthy

        port: 80

     #   httpHeaders:   设置http请求头

     #   - name: X-Custom-Header

     #     value: Awesome

      initialDelaySeconds: 15

      timeoutSeconds: 1  #超时时间

    readnessProbe:

      tcpSocket:

        port: 80

      initialDelaySeconds: 5

      periodSeconds: 20

从上面的YAML文件我们可以看出readiness probe的配置跟liveness probe很像，基本上一致的。唯一的不同是使用readinessProbe而不是livenessProbe。两者如果同时使用的话就可以确保流量不会到达还未准备好的容器，准备好过后，如果应用程序出现了错误，则会重新启动容器。

探针参数：

* timeoutSeconds：探测超时时间，默认1秒，最小1秒。

* successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1，但是如果是`liveness`则必须是 1。最小值是 1。

* failureThreshold：探测成功后，最少连续探测失败多少次才被认定为失败。默认是 3，最小值是 1。

重启策略

PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。 restartPolicy 适用于 Pod 中的所有容器。restartPolicy 仅指通过同一节点上的 kubelet 重新启动容器。失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒…）重新启动，并在成功执行十分钟后重置。如 Pod 文档中所述，一旦绑定到一个节点，Pod 将永远不会重新绑定到另一个节点。

restartPolicy:

Always 容器失效时，kubelet 自动重启该容器
OnFailure 容器终止运行且退出码不为0时重启
Never 不论状态为何， kubelet 都不重启该容器

Pod 的生命

一般来说，Pod 不会消失，直到人为销毁他们。这可能是一个人或控制器。这个规则的唯一例外是成功或失败的 phase 超过一段时间（由 master 确定）的Pod将过期并被自动销毁。

有三种可用的控制器：

使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。
对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。
提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod 。

所有这三种类型的控制器都包含一个 PodTemplate。建议创建适当的控制器，让它们来创建 Pod，而不是直接自己创建 Pod。这是因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以。

如果节点死亡或与集群的其余部分断开连接，则 Kubernetes 将应用一个策略将丢失节点上的所有 Pod 的 phase 设置为 Failed