一、Pod资源生命周期（健康状态检查）

1.1、pod生命周期的介绍

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

Pod生命周期中的重要阶段

• 初始化容器
• 生命周钩子函数
  • postStart
  • preStop
• 容器探测
  • 探测类型
    • 存活状态探测 ：liveness probe
    • 就绪状态探测 ： readiness probe
  • 探测行为
    • ExecAction
    • TCPSocketAction
    • HTTPGetAction

1.1.1、Pod phase

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

1.1.2、Pod 状态

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

1.1.3、Pod健康检查

• 查看官网文档，探针是有kubelet对容器状态的一种定期监控和检查，要执行诊断，kubelet可以调用由容器实现的Handler。有三种执行方式：
  • HTTPGetAction(http)：对指定端口和路径上的容器的IP地址执行HTTP Get请求。如果状态码大于等于200且小于400，则认为诊断成功。
  • ExecAction(exec): 在容器内部执行指定命令，执行后退出状态码为0则诊断成功。
  • TCPSocketAction(tcp:): kubelet 对指定容器IP和Port进行TCP检查，如果端口打开，则被认为诊断成功
• 诊断状态有三种：
  • 成功： 容器状态健康，通过了检测
  • 失败： 容器未通过诊断
  • 未知： 诊断失败，不会采取任何行动

1.1.3.1、容器探针

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

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

• 如果容器中的进程能够在出现服务故障的时候自动崩溃，那么这种时候是不需要提供livenessProbe ，kubelet将根据Pod的restartPolicy自动执行正确的操作
• 如果希望容器在探测失败时被杀死并重新启动，那么请指定一个livenessPRobe存活探针，并指定restartPolicy为Always或OnFailure。
• 如果要在探测成功才开始向Pod发送流量，就需要指定一个readnessProbe 。在这种情况下，就绪探针可能和存活探针同时存在，这种情况下的readnessProbe意味容器在没有接受到任何 流量的情况下启动，并且只有在探针成功后才接收流量。如果希望容器能够自行维护，那就指定一个readnessProbe探针，和livenessProbe探测不同的端点。
• 注意，如果只想在pod被删除时能够排除请求，则不一定需要使用就绪探针；在删除Pod时，Pod将自动将自身置于未完成状态，无论是否有就绪探针。当等待Pod中的容器停止时，Pod仍处于未完成状态。

1.1.3.3、模板 使用exec方式指定command

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 杀掉然后重启。

1.1.3.4、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。两者如果同时使用的话就可以确保流量不会到达还未准备好的容器，准备好过后，如果应用程序出现了错误，则会重新启动容器。

1.1.3.6、探针参数

• timeoutSeconds：探测超时时间，默认1秒，最小1秒。
• successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1，但是如果是liveness则必须是 1。最小值是 1。
• failureThreshold：探测成功后，最少连续探测失败多少次才被认定为失败。默认是 3，最小值是 1。

1.1.3.7、重启策略

• dSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。 restartPolicy 适用于 Pod 中的所有容器。restartPolicy 仅指通过同一节点上的 kubelet 重新启动容器。失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒…）重新启动，并在成功执行十分钟后重置。如 Pod 文档 中所述，一旦绑定到一个节点，Pod 将永远不会重新绑定到另一个节点。
• tartPolicy:
  • ways 容器失效时，kubelet 自动重启该容器
  • Failure 容器终止运行且退出码不为0时重启
  • ver 不论状态为何， kubelet 都不重启该容器

4.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