K8s Pod 状态流转深度解析：生命周期管理与状态判定内幕

你有没有好奇过，在 Kubernetes (K8s) 里，一个 Pod 从创建到消亡，中间都经历了哪些状态？K8s 又是如何判断 Pod 当前状态的？今天咱们就来聊聊这个话题，深入剖析 Pod 的生命周期管理和状态判定机制。

作为 K8s 的老手，想必你对 Pod 已经很熟悉了。Pod 是 K8s 中最小的可部署单元，它可以包含一个或多个容器。但 Pod 的状态可不仅仅是“运行”或“停止”这么简单，它背后有一套完整的状态转换流程。

Pod 的生命周期

Pod 的生命周期，指的是 Pod 从创建到最终终止的整个过程。在这个过程中，Pod 会经历多个不同的状态阶段。咱们先来捋一捋这些状态：

• Pending（等待中）：Pod 已经被 K8s 系统接受，但有一个或多个容器镜像尚未创建。这个阶段包括了等待调度的时间，以及通过网络下载镜像的时间。
• Running（运行中）：Pod 已经绑定到了一个节点上，并且 Pod 中所有的容器都已经被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
• Succeeded（成功）：Pod 中的所有容器都已成功终止，并且不会再重启。这通常用于一次性任务，比如批处理作业。
• Failed（失败）：Pod 中的所有容器都已终止，并且至少有一个容器是因为失败而终止。也就是说，容器以非零状态退出，或者被系统终止。
• Unknown（未知）：由于某种原因无法获得 Pod 的状态，通常是由于与 Pod 所在节点的通信错误。

除了上面这几个主要状态外，Pod 在不同阶段还会有一些更细粒度的状态信息，比如：

• ContainerCreating（容器创建中）：容器正在被创建。
• PodScheduled（Pod 已调度）：Pod 已经被调度到一个节点上。
• Initialized（已初始化）：所有的 Init 容器都已经成功启动。
• Ready（就绪）：Pod 能够提供服务，并且应该被添加到对应服务的负载均衡池中。
• ContainersReady（容器就绪）: Pod 中所有容器已就绪.

Pod 状态转换流程

Pod 的状态转换不是随意发生的，它遵循一定的规则和流程。下面这张图可以清晰地展示 Pod 状态之间的转换关系：

                                      +------------------+
                                      |      Pending      |
                                      +------------------+
                                             |
                                             V
+------------------+      +------------------+      +------------------+
|  PodScheduled   |----->|  ContainerCreating  |----->|    Running      |
+------------------+      +------------------+      +------------------+
       |                                                     |
       |                                                     |
       |                                                     V
       |                                             +------------------+
       |      +-------------------------------------------------->|    Succeeded    |
       |      |                                             +------------------+
       |      |
       |      V
       |      +------------------+
       |      |      Failed      |
       +----->+------------------+
              |                  |
              +------------------+
 
 
                                      +------------------+
                                      |     Unknown      |
                                      +------------------+
 
 
  Init Containers: Pending -> Running -> Completed/Failed. 独立于主容器的生命周期

从图中我们可以看到，Pod 的生命周期通常是从 Pending 状态开始的。当 Pod 被调度到一个节点后，状态变为 PodScheduled。然后，K8s 会开始创建 Pod 中的容器，状态变为 ContainerCreating。当所有容器都创建成功并且至少有一个容器正在运行，Pod 的状态变为 Running。

如果 Pod 中的所有容器都成功运行结束，并且 Pod 的 restartPolicy 设置为 Never 或 OnFailure，那么 Pod 的状态就会变为 Succeeded。如果 Pod 中有容器运行失败，并且 restartPolicy 设置为 Always 或 OnFailure，那么 Pod 会尝试重启容器。如果容器无法成功重启，或者 restartPolicy 设置为 Never，那么 Pod 的状态就会变为 Failed。

在 Pod 运行过程中，如果 K8s 无法获取 Pod 的状态（比如节点失联），那么 Pod 的状态就会变为 Unknown。

K8s 如何判断 Pod 状态？

那么，K8s 内部是如何判断 Pod 状态的呢？这就要说到 K8s 的核心组件之一：kubelet。

Kubelet 是运行在每个节点上的代理程序，它负责管理节点上的 Pod 和容器。Kubelet 会定期向 API Server 汇报 Pod 的状态。API Server 会将这些状态信息存储在 etcd 中。K8s 的其他组件，比如 Scheduler、Controller Manager 等，就可以通过 API Server 查询 Pod 的状态，并根据状态做出相应的决策。

Kubelet 判断 Pod 状态的主要依据是容器的状态。它会通过 Container Runtime Interface (CRI) 来获取容器的运行状态。CRI 是 K8s 定义的一组接口，用于与不同的容器运行时（比如 Docker、containerd 等）进行交互。

Kubelet 会根据容器的状态来综合判断 Pod 的状态。比如：

• 如果所有容器都处于运行状态，那么 Pod 的状态就是 Running。
• 如果所有容器都已终止，并且都以状态码 0 退出，那么 Pod 的状态就是 Succeeded。
• 如果有任何一个容器以非零状态码退出，那么 Pod 的状态就是 Failed。

除了容器的状态，Kubelet 还会考虑 Pod 的 restartPolicy、Pod 的 readinessProbe 和 livenessProbe 等因素来判断 Pod 的状态。

深入理解：ReadinessProbe 和 LivenessProbe

ReadinessProbe 和 LivenessProbe 是 K8s 中用于探测容器状态的两种机制。它们可以帮助 K8s 更准确地判断 Pod 的状态，并做出更精细的控制。

• LivenessProbe（存活探针）：用于检测容器是否还在运行。如果 LivenessProbe 检测失败，K8s 会认为容器已经死亡，并根据 Pod 的 restartPolicy 来决定是否重启容器。
• ReadinessProbe（就绪探针）：用于检测容器是否已经准备好接收流量。如果 ReadinessProbe 检测失败，K8s 会认为容器还没有准备好，并将 Pod 从 Service 的 Endpoints 列表中移除，这样就不会有流量转发到这个 Pod。

ReadinessProbe 和 LivenessProbe 可以通过以下几种方式进行探测：

• ExecAction：在容器内执行一个命令。如果命令的退出状态码为 0，则认为探测成功。
• TCPSocketAction：尝试与容器的指定端口建立 TCP 连接。如果连接成功，则认为探测成功。
• HTTPGetAction：向容器的指定端口和路径发送 HTTP GET 请求。如果响应的状态码在 200-399 之间，则认为探测成功。

通过合理配置 ReadinessProbe 和 LivenessProbe，我们可以让 K8s 更好地管理 Pod 的状态，提高应用的可靠性和可用性。

举个栗子！假设你有一个 Web 应用，启动比较慢。你可以在启动脚本里加一段逻辑，等所有初始化都完成后，再创建一个标志文件。然后配置一个 LivenessProbe，定期检查这个文件是否存在。这样，在应用完全启动之前，K8s 就不会把流量转发给它。

再举个例子, 假如你的应用在运行过程中可能会出现死锁。你可以配置一个 LivenessProbe，定期检查应用的某个接口是否正常响应。如果接口无响应，K8s 就会自动重启容器，避免应用长时间处于不可用状态。

总结一下

今天，咱们深入探讨了 K8s 中 Pod 的状态转换流程，以及 K8s 内部是如何判断 Pod 状态的。我们了解了 Pod 的生命周期，以及不同状态之间的转换关系。还学习了 K8s 的核心组件 kubelet 是如何通过 CRI 来获取容器状态，并综合判断 Pod 状态的。最后，我们还介绍了 ReadinessProbe 和 LivenessProbe 这两种探测机制，以及如何利用它们来提高应用的可靠性和可用性。

希望通过今天的分享，你对 K8s Pod 的状态管理有了更深入的理解。如果你还有其他问题，欢迎随时提问！咱们下期再见！

进阶思考

1. Init 容器的状态对 Pod 状态有什么影响？
   Init 容器是在 Pod 的主容器启动之前运行的容器，用于执行一些初始化任务。Init 容器的状态也会影响 Pod 的状态。如果 Init 容器运行失败，Pod 的状态会变为 Failed，除非设置了restartPolicy。所有的 Init 容器都必须成功运行，Pod 才会进入 Running 状态。
2. Pod 的 TerminationGracePeriodSeconds 参数有什么作用？
   TerminationGracePeriodSeconds 参数用于设置 Pod 的优雅终止时间。当 Pod 被删除时，K8s 会先向 Pod 中的容器发送 SIGTERM 信号，然后等待 TerminationGracePeriodSeconds 指定的时间。如果容器在这个时间内没有正常终止，K8s 会强制杀死容器（发送 SIGKILL 信号）。合理设置 TerminationGracePeriodSeconds 可以让容器有足够的时间来处理未完成的请求，避免数据丢失。
3. 如何监控 Pod 的状态变化？
   可以通过 K8s 的 API Server 来监控 Pod 的状态变化。可以使用 kubectl get pods -w 命令来实时查看 Pod 的状态。也可以使用 K8s 的 Event 机制来监听 Pod 的状态变化事件。此外，还可以使用一些第三方监控工具，比如 Prometheus、Grafana 等，来监控 Pod 的状态。