Kubernetes Pod 的生命周期

原文： https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

这篇介绍了 Pod 的生命周期。

Pod phase

Pod 的状态字段是一个 PodStatus 对象，它带有一个 phase 字段。

Pod 的阶段是 Pod 在其生命周期中的简单、高级的概述。Pod 的阶段不是为了对 Container 或 Pod 状态的进行全面地综合汇总，也不是为了做全面的状态机。

Pod 阶段的数值和含义是严格指定的。除了本文中列举的内容外，不应该再假定 Pod 有其他的 phase 值。

下面是 phase 的可能值：

Pod 条件

Pod 由一个 PodStatus 对象，此对象包含一个 PodConditions 数组。每个 PodCondition 数组元素包含六个可能的字段：

• lastProbeTime 字段提供了最后一次探测 Pod 条件的时间戳。
• lastTransitionTime 字段提供了 Pod 最后一次状态转换的时间戳。
• message 字段是人类可读的消息，它指明了有关转换的详细信息。
• reason 字段是唯一、单字的 CamelCase 原因，它指明了最后一次条件转换的原因。
• status 字段是一个字符串，可选值有 True 、 False 和 Unknown 。
• type 字段是一个带有下列可能值的字符串:
  • PodScheduled ：Pod 已经被调度到一个节点上。
  • Ready ：Pod 可以处理请求，并且应该被添加到所有匹配服务的负载均衡池中。
  • Initialized ：所有 初始化容器 都已经成功启动。
  • Unschedulable ：调度器现在不能调度 Pod，例如缺少资源或其他限制。
  • ContainersReady ：Pod 中的所有容器都已准备就绪。

容器探针

探针 是由 kubelet 定期执行的诊断。为了执行诊断，kubelet 调用了由容器实现的 Handler 。处理程序有三种类型：

• ExecAction ：在容器内部执行指定的命令。如果命令以状态码 0 退出，则诊断为成功。
• TCPSocketAction ：对容器 IP 地址的指定端口执行 TCP 检查。如果端口是打开的，则诊断为成功。
• HTTPGetAction ：对容器 IP 地址的指定端口和路径执行 HTTP GET 请求。如果响应的状态码大于等于 200 且小于 400，则诊断为成功。

每个探针的结果有下面三种：

• Success：容器通过诊断。
• Failure：容器诊断失败。
• Unknown：诊断失败，因此不应采取任何措施。

kubelet 可以选择在运行的容器上执行两种探测并做出反应：

• livenessProbe ：指示容器是否运行。如果存活探测失败，kubelet 会杀死容器，并且容器将收到其 重启策略 的影响。如果容器没有提供存活探针，其默认状态是 Success 。
• readinessProbe ：指示容器是否准备好处理请求。如果就绪探测失败，端点控制器会从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址。初始延迟之前的就绪状态的默认值为 Failure 。如果容器不提供就绪探针，则默认状态为 Success 。

何时应该使用存活探针和就绪探针？

如果容器中的进程在遇到问题或变得不健康时能够自行崩溃，那么你一定不需要存活探针；kubelet 将自动地按照 Pod 的 restartPolicy 执行正确的操作。

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

如果你希望仅在探测成功时才开始发送流量到 Pod，那么请指定一个就绪探针。在这种情况下，就绪探针可能和存活探针相同，但是在规约中的就绪探针的存在意味着 Pod 开始时没有接收任何流量并且只在探测成功后才开始接收流量。

如果容器在启动时需要载入大量数据、配置或迁移文件，请指定一个就绪探针。

如果希望容器能够自行维护，可以指定一个就绪探针，该探针用于检查特定就绪状态的端点（此端点与存活探针的不同）。

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

更多有关如何设置存活探针和就绪探针的信息，请查看 配置存活探针和就绪探针 。

Pod 和 Container 的状态

有关 Pod Container 状态的详细信息，请查看 PodStatus 和 ContainerStatus 。注意，报告 Pod 状态的信息取决于当前的 ContainerState 。

Pod readiness gate

FEATURE STATE： Kubernetes v1.11 alpha

为了通过将额外的反馈或信号注入到 PodStatus 来增加 Pod 就绪探针的扩展性，Kubernetes 1.11 引入了一个名为 Pod ready++ 的功能。你可以在 PodSpec 中使用新字段 ReadinessGate 指定 Pod 就绪探针进行评估附加条件。如果 Kubernetes 不能在 Pod 的 status.conditions 字段中找到这样一个条件，那么条件的默认状态为 False 。下面是一个例子：

Kind: Pod
......
spec:
  readinessGates:
    - conditionType: 'www.example.com/feature-1'
status:
  conditions:
    - type: Ready # this is a builtin PodCondition
      status: 'True'
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: 'www.example.com/feature-1' # an extra PodCondition
      status: 'False'
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true
......

新的 Pod 条件必须符合 Kubernetes 标签的格式 。由于 kubectl patch 命令仍然不支持对象状态，新的 Pod 条件必须使用 KubeClient 库 通过 PATH 操作注入进去。

随着新的 Pod 条件的引入，只有当下面两个条件都成立时才会认为 Pod 准备就绪：

• Pod 中所有容器都准备就绪。
• 所有 ReadinessGates 指定的条件都为 True 。

为了便于 Pod 就绪探针对此作出改变，引入新的 Pod 条件 ContainersReady 来捕获旧的 Pod Ready 条件。

作为 alpha 功能，必须通过将 PodReadinessGates feature gate 设置为 True 来显示地启用 “Pod Ready++” 功能。

重启策略

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

Pod 的生命周期

通常情况上，Pod 不会消失，知道有人销毁它。这可能是一个人会控制器。这个规则唯一的例外是 phase 值为 Succeeded 或 Failed 超过一段时间（由主节点上的 terminated-pod-gc-threshold 决定的）的 Pod 将过期并被自动销毁。

有三种可用的控制器类型：

• 使用 Job 运行预期会终止的 Pod，例如批量计算。Job 只适用于具有 restartPolicy 为 OnFailure 或 Never 的 Pod。
• 使用 ReplicationController 、 ReplicaSet 或 Deployment 运行预期不会终止的 Pod，例如 web 服务器。ReplicationControllers 只适用于具有 restartPolicy 为 Always 的 Pod。
• 使用 DaemonSet 运行需要为每台机器运行一个的 Pod，因为它提供特定于机器的系统服务。

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

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

例子

高级存活探针示例

存活探针由 kubelet 来执行，因此所有的请求都在 kubelet 的网络命名空间中进行。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
    - args:
        - /server
      image: k8s.gcr.io/liveness
      livenessProbe:
        httpGet:
          # when "host" is not defined, "PodIP" will be used
          # host: my-host
          # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
          # scheme: HTTPS
          path: /healthz
          port: 8080
          httpHeaders:
            - name: X-Custom-Header
              value: Awesome
        initialDelaySeconds: 15
        timeoutSeconds: 1
      name: liveness

示例状态

• Pod 正在运行并有一个容器。容器成功退出。

  restartPolicy
  phase
  phase
  phase
  

• Pod 正在运行并有一个容器。容器失败退出。

  restartPolicy
  phase
  phase
  phase
  

• Pod 正在运行并有两个容器。容器 1 失败退出。
  • 记录失败事件。
  • 如果 restartPolicy 为：
  • Always：重启容器，Pod phase 仍为 Running。
  • OnFailure：重启容器，Pod phase 仍为 Running。
  • Never：不重启容器，Pod phase 仍为 Running。
  • 如果容器 1 不在运行，而容器 2 退出：
  • 记录失败事件。
  • 如果 restartPolicy 为：

    phase
    phase
    phase
    

• Pod 正在运行并有一个容器。容器运行超出内存。

  restartPolicy
  phase
  phase
  phase
  

• Pod 正在运行，磁盘故障。

  phase
  

• Pod 正在运行，但是节点被分隔出来。

  phase