Pod生命周期和健康检查

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