K8s Pod生命周期与健康探针

可视化演示

展示Kubernetes Pod完整生命周期状态流转与三种健康探针(Liveness/Readiness/Startup)工作机制。切换模式查看各维度，拖动滑块调节探针检测间隔。

生命周期阶段——前台面板上的状态灯

酒店前台（API Server）的系统屏幕上，每间客房都有一盏状态灯。房间正在打扫、住客还没进门，绿灯亮起标着 Pending；住客刷卡入住、房门关上，变成 Running；任务型住客（比如 Job 型 Pod）办完事正常退房，点亮 Succeeded；住客把房间弄得一塌糊涂必须强制清退，则亮起 Failed。还有一盏灰灯叫 Unknown——管家和前台彻底失联了，谁也不知道房间里发生了什么。

在 Kubernetes 中，Pod 的 phase 字段就是这盏状态灯。它属于 Pod 级别的“大状态摘要”，不关心容器内部细节，只告诉你住客整体处于哪个环节。Pending 意味着 Pod 已被 API Server 接受，但容器尚未全部创建完成（可能是调度中、镜像拉取中、初始化容器未跑完）；Running 表示 Pod 已绑定节点、所有容器已创建且至少有一个仍在运行；Succeeded 与 Failed 都是终态，前者代表所有容器正常退出，后者代表至少一个容器以非零状态失败。

理解这五种阶段，就像看懂前台屏幕上的状态灯：你一眼就知道哪些房间住着人、哪些房间空出来了、哪些房间出了状况。排障的第一步，永远是先看 kubectl get pod 输出里的 STATUS 列——那是酒店前台最诚实的一句话。

状态转换机制——管家手册里的规矩

客房管家（kubelet）手里有一本《服务手册》，规定了住客在房间内发生各种情况时该如何处置。住客在等电梯、在洗澡、还是已经退房，对应容器状态的 Waiting、Running、Terminated 三态；住客突然跑路了怎么办，对应重启策略（restartPolicy）；住客要退房时给多少时间收拾行李，对应优雅终止（graceful termination）。这些规矩共同驱动着前台面板上状态灯的切换。

重启策略是这本手册里最重要的一条：Always 表示住客无论什么原因离开都立刻安排新住客；OnFailure 表示只有住客自己作妖出事（异常退出）才安排新人，正常退房就不再安排；Never 表示这间房一旦空出来就永久关闭。而优雅终止则像退房流程：管家先敲门说“请收拾行李”（发送 SIGTERM 信号），给你默认 30 秒宽限期去保存数据、关闭连接，时间一到还没出来，保安就会用备用钥匙强行清房（发送 SIGKILL 强制杀死进程）。

这套“先礼后兵”的机制，保证了线上服务在缩容或发布时不会瞬间断连。住客优雅退房，留下的房间干干净净；强闯进来硬拖走，下一批住客（新 Pod）接手时可能面对一堆半写坏的文件——这也是为什么优雅终止宽限期要按业务启动耗时和清理耗时来调优。

存活探针Liveness——确认住客还有呼吸

管家每天定时到客房门口听动静：里面还有没有呼吸声？叫两声有没有回应？如果连续几次敲门都没反应，管家就会联系保安破门而入——发现住客已经“假死”在房间里（进程还在，但逻辑死锁、goroutine 泄漏、事件循环卡死），赶紧把房间清理干净，安排一位新住客入住（重启容器）。

Liveness 探针（存活探针）干的就是这活儿。它周期性探测容器是否“活着”，注意这里“活着”的定义是进程本身状态良好，而不是业务对外可用。经典的死锁场景是：Java 应用进程没有退出，但所有工作线程都阻塞在抢锁上，HTTP 接口永远不返回。此时进程存在但已丧失服务能力，Liveness 探针失败累计到阈值后，kubelet 会杀掉容器并按 restartPolicy 重建，让服务恢复元气。

在云上大酒店里，Liveness 就是那个“每分钟确认住客还有没有气”的尽职管家。它不是用来判断“住客是否愿意开门见客”的——那太严厉了，会误伤正在午休的好住客。它只管一件事：这间房里还有没有活人。

就绪探针Readiness——是否准备好接待访客

有些住客入住后要先打扫房间、布置客厅、打开空调，才方便接待访客。管家会在门口挂上“请勿打扰”的牌子，访客（流量）看到牌子就绕道去别的房间；等住客一切安排妥当，管家摘掉牌子，访客才会敲他的门。

Readiness 探针（就绪探针）就是这个“请勿打扰”牌子。它周期性检查容器是否“就绪”——注意，就绪不代表进程活着，而是代表当前是否能够接收外部请求。探测失败时，Kubernetes 将 Pod 从 Service 的 Endpoints 列表（后端地址簿）中摘除，流量不再转发过来；探测恢复后，Pod 自动加回列表。整个过程不会重启容器，纯粹是“流量开关”。

滚动更新就是靠这个牌子实现的：新房间的住客还没收拾好，牌子挂着，访客全去老房间；新住客陆续准备好、牌子逐个摘下，访客才慢慢分流过去。没有 Readiness 探针的滚动发布，如同让一群刚进门的住客手忙脚乱地同时见客——必然一地鸡毛。

启动探针Startup——给慢性子住客的缓冲期

有些住客入住动作特别慢：行李几十个箱子要逐个搬（加载大模型权重）、房间要重新装修（初始化缓存与连接池）。如果管家按常规节奏敲门确认呼吸，很可能住客还在搬第一箱行李时就被误判为“没反应”，直接请保安清房，导致住客永远无法住下。

Startup 探针（启动探针）就是应对这种慢性子住客的专用机制。启动探针临时接管“确认住客状态”的职责，以它自己的节奏反复检查住客是否安顿完毕；只有 Startup 探针成功后，Liveness 和 Readiness 探针才会开始正常工作。也就是说，Startup 探针相当于一个“满血保护期”，保护慢启动容器不被 Liveness 误杀。

在云上大酒店里，Startup 探针是给“搬行李选手”的专属礼遇：先让客人从容进屋，安顿好了，管家才开始例行检查。大模型推理服务、JVM 应用、缓存预热型中间件，都是它的忠实受益者。

探针配置参数——探测仪表的旋钮

管家的健康检测仪上有四个旋钮，决定了“什么时候开始查、隔多久查一次、一次等多久、连续几次算出事”。这四个旋钮对应探针配置里的四个字段，它们是探针灵敏度的全部秘密。

第一个旋钮 initialDelaySeconds：容器启动后先等多久再开始第一次探测，相当于管家站在门口先听半分钟动静再敲门。第二个旋钮 periodSeconds：两次探测的间隔时间，管家每隔 N 秒来敲一次门。第三个旋钮 timeoutSeconds：单次探测最多等多久，敲门后 5 秒内没有应门就算这一次失败。第四个旋钮 failureThreshold：连续失败多少次才触发决策（重启或摘除），管家连敲 3 次没回应才认定出事了。

旋钮调太紧（周期太短、阈值太小），管家会草木皆兵，住客打个喷嚏就被清房；旋钮调太松，住客真的昏倒在屋里也没人发现。生产环境的调优，就是在“反应速度”和“误伤概率”之间找到微妙的平衡。

探针实现方式——管家用哪种敲门法

管家检查住客状态有三种手段：敲门问话（Exec）、按门铃听回应（TCP）、透过门缝看指示灯（HTTP）。三种手段对应三种探针 handler，各有各的适用场景。

HTTP 探针向容器暴露的 URL 发起 GET 请求，如果响应状态码落在 200 到 399 之间就判定健康——这是最常用也最贴近“业务感知”的方式，前提是应用必须实现健康检查端点。TCP 探针尝试与指定端口建立 TCP 连接，连接成功即视为健康，适合没有 HTTP 接口的服务器（数据库、消息队列）。Exec 探针在容器内执行一条命令，命令退出码为 0 则健康，适合无法开端口、只能在进程内部自检的场景。

选哪种敲门方式，取决于门上装了什么“应答器”。有 HTTP 服务就用 HTTP，只有端口就用 TCP，啥端口都没有就塞一条自检命令进容器。选对方式，管家的每一次敲门才有意义。

AI 应用场景

Python 演示

"""Simulate how startup/liveness/readiness probes collaborate in a Pod.""" import randomimport time  class Probe:    """A simplified probe: runs every period ticks, counts consecutive failures."""     def __init__(self, name, period, threshold):        self.name = name        self.period = period        self.threshold = threshold        self.failed_count = 0        self.tick = 0     def run_check(self):        """Return 'success', 'failure', 'pending' or 'idle'."""        self.tick += 1        if self.tick % self.period != 0:            return "idle"        time.sleep(0.01)        ok = random.random() > 0.3        if ok:            self.failed_count = 0            return "success"        self.failed_count += 1        if self.failed_count >= self.threshold:            self.failed_count = 0            return "failure"        return "pending"  def simulate():    startup = Probe("startup", 1, 3)    liveness = Probe("liveness", 2, 3)    readiness = Probe("readiness", 2, 2)    started = False    ready = False     for t in range(1, 41):        if not started:            result = startup.run_check()            if result == "failure":                print("t={}: startup failed, container restarted".format(t))                return            if result == "success":                started = True                print("t={}: startup ok, liveness/readiness begin".format(t))            continue         if liveness.run_check() == "failure":            print("t={}: liveness failed, container restarted".format(t))            started = False            ready = False            continue         result = readiness.run_check()        if result == "success" and not ready:            ready = True            print("t={}: readiness ok, joined endpoints".format(t))        elif result == "failure" and ready:            ready = False            print("t={}: readiness lost, removed from endpoints".format(t))     print("done: started={}, ready={}".format(started, ready))  if __name__ == "__main__":    random.seed(2024)    simulate()

1. class Probe:定义探针类，把三种探针的公共行为（周期、失败计数、阈值）统一封装。
2. self.failed_count = 0记录连续失败次数，对应 failureThreshold 的累计机制。
3. if self.tick % self.period != 0: return "idle"按 periodSeconds 节流探测频率，不到周期不探测。
4. if self.failed_count >= self.threshold: return "failure"达到阈值才返回失败，模拟“连续失败才触发动作”。
5. if not started: result = startup.run_check()Startup 探针优先运行，成功前 Liveness/Readiness 一律不启动。
6. if liveness.run_check() == "failure":存活探测失败后模拟容器重启，重新回到启动阶段。
7. readiness.run_check()就绪探针控制 Pod 是否加入端点列表，失败时摘除、恢复时加回。

常见误区

面试题