Skip to main content

Command Palette

Search for a command to run...

Pod 的一生

Updated
3 min read

原文:Pod Lifecycle

本文阐述了 Pod 的生命周期,这并不是一篇全面的文档,仅是这一话题的简介。

Pod 的阶段(Phase)

按照《API 公约》 的描述,Pod 阶段是对生命周期的一个阶段的概括。他不是一个对 Pod 或者容器层次的状态的详尽结论,也不是一个全面的状态机。

PodPhase 很封闭。除了本文提到的内容,不应该对一个 Pod 的 PodPhase 做出任何假设。

  • Pending:Pod 被系统接收,但是其中的一个或者多个容器镜像尚未创建。这一过程包括下载镜像的时间,以及被计划运行之前的时间。
  • Running:该 Pod 被分派给一个 Node,并且已经创建了所有容器。至少一个容器还在运行,或者正在被启动以及重启。
  • Succeeded:Pod 中的所有容器都已经成功结束,并且不会重新启动。
  • Failed:Pod 里所有的容器都已经结束运行,且至少一个容器的退出结果是失败的(被系统结束,或非 0 的退出状态)。
  • Unknown:因为某些原因无法获得 Pod 状态,一般来说是 Pod 所处主机的通信出了故障。

Pod 状态(Condition)

Pod 中容器的就绪检测会报告就绪状况,其取值可能是 True、False 或者 Unknown。

容器检测

Kubelet 会周期性的对容器进行检测 。这一过程是如下三种方法之一:

  • ExecAction:执行一个容器内的指定命令,如果命令返回码为 0 ,则代表成功。
  • TCPSocketAction:对目标容器的 IP 地址执行 TCP 操作,如果指定端口开放,则代表成功。
  • HTTPGetAction:对目标容器的 IP 地址、端口号以及路径进行 HTTP Get 操作,如果返回码在 200 和 400 之间,则检测成功。

检测过程可能会有三种结果之一:

  • Success:容器成功通过检测。
  • Failure:容器检测失败。
  • Unknown:检测未能完成。

目前 Kubelet 能够有两种独立的检测可以被触发:

  • LivenessProbe:用于检查当前容器是否存活,也就是正在运行。LivenessProbe 会告知 Kubelete 容器的健康状况。如果 LinenessProbe 失败,Kubelete 会杀掉这个容器,接下来,容器会根据 RestartPolicy(重启动策略)进行后续动作。容器在没进行这一检测之前的状态被标记为 Success。
  • ReadinessProbe:当前容器是否已经就绪,可以对外提供服务。如果这一检测失败的话,即使这一Pod 还在运行,Endpoint 控制器也会把这个 Pod 的 IP 地址从相关服务中移除,这样他就不会从 Proxy 获取流量(例如容器在提供服务之前会有一个较长的启动时间,或者容器正在关机维护)。在初始化完成之前,缺省的就绪状态是 Failure。当没有进行检测的时候,容器的就绪状态缺省假设为 Success。

容器状态(Statuses)

对容器状态的详细信息可以参考ContainerStatuses

重启策略

RestartPolicy 有几个可能的取值:Always,OnFailure 以及 Never。他的缺省值是 Always。RestartPolicy 作用于一个 Pod 中的所有容器。RestartPolicy 适用于同一 Node 的 Kubelet 的重启动操作。失败的容器会被 Kubelet 重启,重启之前会有一个渐进的延迟,延迟时长是同步频率的 0、1、2、4、8...倍,上限是五分钟,成功执行 10 分钟后会复位(延迟时间)。在 [Pod 文档中] 提到,Pod 一旦绑定到了一个 Node 上,就不会再绑定到其他 Node 了。这意味着即便是只有一个 Pod,也需要有控制器来进行操作,这样在 Node 失败的时候,才能保证 Pod 的存活。

目前有三种可用的控制器:

  • Job:用来执行会结束的 Pod (例如批处理运算)。
  • ReplicationController:不需要结束的 Pod (例如 Web Server)。
  • DaemonSet:每台(物理)机只能运行一个的 Pod,这种 Pod 提供机器相关的系统服务。如果在 ReplicationController 或者 Daemon 之间举棋不定,可以参考 Daemon Set vs Replication Controller

ReplicationController 是唯一符合 RestartPolicy = Always 需要的。Job 就适合另外两种。

所有三种控制器都有对应的 PodTemplate,跟 Pod 的字段一致。建议创建控制器,让控制器创建 Pod,而不是自行直接创建 Pod。这是因为 Pod 不具备适应服务器失败的能力,而控制器可以。

Pod 的生命期

一般来说, Pod 创建之后就不会消失,除非被手工销毁。销毁手段可能是人工、ReplicationController 或者其他控制器。唯一的例外是处于 Succeeded 或者 Failed 阶段一定时间的 Pod 会因过期(由 Master 决定)而被自动销毁。

如果一个 Node 崩溃或者从集群断开,系统内的实体(目前称为 NodeController )会负责执行策略(例如超时)并把丢失的 Node 中的所有 Pod 标记为 Failed。

例子

  • Pod 在 Running 状态,1 个容器,该容器成功退出
    • 记录结束事件
    • RestartPolicy 如果是
      • Always:重启容器,Pod 保持 Running 状态
      • OnFailure:Pod 转为 Succeeded 状态
      • Never:Pod 转为 Succeeded 状态
  • Pod 在 Running 状态,一个容器,容器失败退出
    • 记录失败事件
    • 如果 RestartPolicy 是:
      • Always:重启容器,Pod 保持 Running 状态
      • OnFailure:重启容器,Pod 保持 Running 状态
      • Never:Pod 进入 Failed 状态
  • Pod 在 Running 状态,两个容器,容器 1 失败退出
    • 记录失败事件
    • 如果 RestartPolicy 是:
      • Always:重启容器, Pod 保持 Running 状态
      • OnFailure:重启容器,Pod 保持 Running 状态
      • Never:Pod 保持 Running 状态
    • 容器 2 退出...
      • 记录失败事件
      • 如果 Restart Policy 是:
        • Always:重启容器,Pod 保持 Running 状态
        • OnFailure:重启容器,Pod 保持 running 状态
        • Never:Pod 进入 Failed 状态
  • Pod 在 Running 状态,容器内存不足
    • 容器失败退出
    • 记录 OOM 事件
    • 如果 RestartPolicy 是:
      • Always:重启容器,Pod 保持 Running
      • OnFailure:重启容器,Pod 保持 Running - Never:记录失败事件,Pod 进入 Failed 状态
  • Pod 在 Running 状态,一个磁盘坏掉。
    • 所有容器被 Kill
    • 记录事件
    • Pod 进入失败状态
    • 如果在控制器之下运行,则 Pod 会在其他位置被创建
  • Pod 在 Running 状态,所在 Node 被断开
    • NodeController 等待超时长
    • NodeController 标记 Pod 为 Failed 状态
    • 如果在控制器之下运行,则 Pod 会在其他位置被创建
type PodStatus struct {
    // Current condition of the pod.
    // More info: http://releases.k8s.io/HEAD/docs/user-guide/pod-states.md#pod-phase
    Phase PodPhase `json:"phase,omitempty"`
    // Current service state of pod.
    // More info: http://releases.k8s.io/HEAD/docs/user-guide/pod-states.md#pod-conditions
    Conditions []PodCondition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type"`
    // A human readable message indicating details about why the pod is in this condition.
    Message string `json:"message,omitempty"`
    // A brief CamelCase message indicating details about why the pod is in this state.
    // e.g. 'OutOfDisk'
    Reason string `json:"reason,omitempty"`

    // IP address of the host to which the pod is assigned. Empty if not yet scheduled.
    HostIP string `json:"hostIP,omitempty"`
    // IP address allocated to the pod. Routable at least within the cluster.
    // Empty if not yet allocated.
    PodIP string `json:"podIP,omitempty"`

    // RFC 3339 date and time at which the object was acknowledged by the Kubelet.
    // This is before the Kubelet pulled the container image(s) for the pod.
    StartTime *unversioned.Time `json:"startTime,omitempty"`

    // The list has one entry per container in the manifest. Each entry is currently the output
    // of `docker inspect`.
    // More info: http://releases.k8s.io/HEAD/docs/user-guide/pod-states.md#container-statuses
    ContainerStatuses []ContainerStatus `json:"containerStatuses,omitempty"`
}
type ContainerState struct {
    // Details about a waiting container
    Waiting *ContainerStateWaiting `json:"waiting,omitempty"`
    // Details about a running container
    Running *ContainerStateRunning `json:"running,omitempty"`
    // Details about a terminated container
    Terminated *ContainerStateTerminated `json:"terminated,omitempty"`
}

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts