新版本刚滚动发布完。

你打开Kubernetes看了一眼：

Pod是 Running。

Readiness是绿的。

副本数量也正常。

看起来这次发布应该没问题。

结果流量刚切进来，监控里503突然开始上涨。

更奇怪的是：

过了二三十秒以后，没有改代码，没有重启Pod，503又慢慢消失了。

这时候最容易出现一个判断：

Pod明明已经Ready了，为什么还会503？

如果直接让 ChatGPT、Codex 去“排查K8s网络”，很容易一上来就查错方向。

因为真正要先判断的不是：

Pod是不是Ready。

而是：

Pod显示Ready的时候，应用到底有没有真正准备好接业务流量。

---

一、先给核心判断：Ready不等于业务真正可用

Kubernetes里的Ready，本质上只代表：

你配置的Readiness Probe通过了。

它并不自动知道：

数据库连接池有没有初始化完成。

Redis连接有没有建立。

配置中心有没有拉到最新配置。

缓存有没有预热。

JVM有没有完成关键类加载。

下游依赖能不能正常调用。

如果你的Readiness Probe只是：

GET /health
返回 200

那它证明的可能只是：

Web进程已经起来了。

但真实业务请求可能还需要：

数据库。

Redis。

MQ。

第三方接口。

本地缓存。

这些资源都准备好以后，系统才真正能处理流量。

所以第一个判断一定要拆开：

K8s Ready ≠ Business Ready

---

二、为什么会出现“刚Ready就503，几十秒后自动恢复”？

这种时间特征本身就是非常重要的Evidence。

如果503只发生在：

发布后的前20秒。

前40秒。

前1分钟。

然后自己恢复。

那我第一反应通常不是：

代码逻辑突然坏了。

而是：

应用存在一个“假Ready窗口”。

也就是：

Kubernetes已经把Pod加入Service Endpoint。

但应用内部还有一部分初始化没结束。

于是流量提前进来了。

---

三、表层原因一：Readiness Probe测得太浅

最常见的情况是：

Readiness只检查一个非常简单的接口。

比如：

/health

这个接口内部甚至什么都不查，只返回：

OK

那Pod启动几秒后就会变成Ready。

但真实业务接口可能需要：

连接数据库。

访问Redis。

读取配置。

初始化线程池。

加载模型或规则。

一旦这些还没准备好，真实请求就可能失败。

所以排查时第一件事不是问：

“Probe是不是绿的？”

而是问：

Probe到底检查了什么？

---

四、表层原因二：连接池还没真正准备好

这个场景在线上非常常见。

比如Spring Boot、Java服务启动完成以后：

HTTP端口已经可以接请求。

Readiness Probe也通过。

但数据库连接池里真正可用的连接还没有稳定建立。

流量一进来：

第一批请求同时抢连接。

连接建立本身又有延迟。

于是接口开始超时。

上游最终返回503。

过几十秒：

连接池逐渐热起来。

问题又自动消失。

这就是为什么：

Pod正常、CPU正常、代码也没报明显错误，发布后却短暂503。

---

五、Redis、配置中心、远程依赖也一样

除了数据库，很多服务启动以后还会做：

Redis连接。

配置中心订阅。

服务发现。

MQ Consumer注册。

远程RPC Client初始化。

这些东西有一个共同特点：

它们不一定和Web端口同时Ready。

比如：

应用10:00:05开始监听8080。

10:00:07 Readiness通过。

10:00:08 Pod进入Endpoint。

但直到10:00:25：

Redis连接才稳定。

配置才拉完。

服务发现才拿到下游节点。

那么：

10:00:08到10:00:25之间，

这个Pod虽然“Ready”，但业务能力其实是不完整的。

---

六、另一个容易忽略的点：缓存和JIT还没热起来

有些服务即使所有依赖都正常，

刚启动时依然会明显慢。

比如：

JVM JIT还没完成热点代码优化。

大量类第一次加载。

本地缓存为空。

模板、规则、配置第一次解析。

第一批请求进来时，需要承担大量初始化成本。

如果上游超时比较严格，就可能出现：

Pod其实没挂。

业务最终也能跑。

但首批请求太慢，最后还是被判成503。

这类问题很容易被误认为：

Ingress异常。

Service异常。

Pod网络异常。

实际上本质是：

Cold Start。

---

七、真实边界场景：Probe没错，错的是Endpoint加入太早

Kubernetes的流量路径大致可以理解成：

Pod启动 → Readiness通过 → 加入Endpoint → Service开始转发流量

所以真正值得看的时间线是：

10:00:05 Pod启动
10:00:09 Readiness通过
10:00:10 Endpoint加入
10:00:11 503开始上涨
10:00:32 应用初始化完成
10:00:35 503恢复

这条时间线一旦对齐，

问题通常就很清楚了。

真正的问题不是：

“为什么Ready还503？”

而是：

“为什么应用还没真正准备好时，Readiness就已经通过了？”

---

八、最快排查顺序，我一般按这6步

以后遇到“Pod全绿但流量503”，我建议直接按这个顺序查。

第一步：先对齐503时间

确认503是不是只集中在发布后几十秒。

如果是，优先怀疑启动窗口。

第二步：看Pod什么时候变Ready

记录：

Pod启动时间。

Readiness通过时间。

第三步：看Endpoint什么时候加入

确认Service从什么时候开始把流量送到这个Pod。

第四步：看应用初始化日志

重点找：

数据库连接池。

Redis。

配置中心。

MQ。

远程服务注册。

第五步：看真实业务请求失败在哪里

是数据库超时？

Redis超时？

下游连接失败？

还是业务自身执行太慢？

第六步：回头检查Probe设计

确认Readiness到底是在测：

“进程活着”

还是：

“业务真的可接流量”。

这个顺序比一上来查Nginx、Ingress、网络，效率通常高很多。

---

九、Startup Probe和Readiness Probe不要混在一起理解

这两个Probe解决的问题不完全一样。

Startup Probe

更适合解决：

应用启动比较慢。

比如一个Java服务启动要40秒。

Startup Probe可以让Kubernetes在启动阶段先别急着用正常的健康逻辑判断它。

Readiness Probe

解决的是：

这个Pod现在能不能接业务流量。

所以一个比较合理的思路是：

启动阶段先让Startup Probe确认：

应用已经基本启动完成。

然后Readiness Probe再判断：

真正关键的业务依赖是否已经满足。

如果Readiness只检查进程存活，

那它其实更接近：

Liveness。

这时候设计就有问题了。

---

十、具体怎么修？先看是不是“假Ready”

如果确认问题出在假Ready，通常有几种修法。

1. Readiness增加真正必要的业务条件

比如至少确认：

关键数据库连接可用。

关键配置已经加载。

必要依赖已经初始化。

但也不要把所有第三方接口都塞进Readiness。

否则一个不关键的外部依赖波动，可能导致整个Pod频繁摘流量。

2. 调整启动时序

如果某些初始化必须完成才能接流量，

就不要让Readiness提前成功。

3. 合理使用Startup Probe

特别是启动慢、初始化步骤多的应用。

4. 给关键资源预热

例如：

连接池预建连接。

缓存预热。

关键类和规则提前加载。

避免第一批真实请求承担初始化成本。

---

十一、不要简单粗暴把initialDelaySeconds调大

这是很常见的“临时修法”。

比如发现Pod启动后30秒内不稳定。

于是：

initialDelaySeconds = 60

看起来问题解决了。

但这只是：

用固定时间掩盖真实Ready条件。

今天30秒够。

以后服务变复杂，可能需要50秒。

不同机器、不同环境，启动时间也可能变化。

所以更稳的是：

让Readiness基于真实状态，而不是猜一个时间。

固定延迟可以作为辅助。

但不能代替真正的业务Ready判断。

---

十二、修完以后怎么验证？

这类问题验证也不能只看：

“Pod现在是绿的”。

真正要重新跑一次发布流程。

观察：

发布后503有没有再次出现。

Pod什么时候Ready。

Endpoint什么时候加入。

第一批业务请求P95 / P99多少。

数据库连接池有没有抖动。

Redis连接有没有异常。

配置是否在加入流量前完成。

最好连续做几轮Rolling Update。

如果每次：

Pod一进入Endpoint就能稳定承接流量，

而不是靠几十秒以后自动恢复，

这才说明问题真正解决。

---

十三、这种K8s发布排查，Plus和Pro怎么判断？

如果你平时只是偶尔让 ChatGPT、Codex：

分析一次Pod日志。

看看Probe配置。

对齐一下Ready、Endpoint和503时间。

检查一两个Deployment配置。

这种任务范围比较集中，Plus通常已经够用。

关键还是把Evidence给完整：

Deployment YAML。

Probe配置。

Pod Event。

应用启动日志。

503时间。

Service / Endpoint状态。

这些信息越完整，判断越快。

---

如果你的日常已经变成：

持续排查K8s发布故障。

一次问题需要同时分析：

Deployment。

Service。

Ingress。

Pod日志。

应用Trace。

数据库。

Redis。

还要让Codex改Probe、改初始化逻辑、跑测试、做发布回归，

而且这种长任务一天反复发生，

那就属于：

高频、多轮、长时间工程工作流。

这种强度下，Pro会更适合。

所以Plus还是Pro，不看：

“Kubernetes问题是不是复杂。”

而是看：

ChatGPT、Codex是不是已经长期参与你的整套发布与排障流程。

偶发排查、短任务：

Plus通常够用。

持续发布治理、多模块联调、反复验证：

再考虑Pro。

---

最后

Pod健康检查全绿，

为什么流量一进来还是大量503？

真正值得先问的不是：

Kubernetes是不是坏了。

而是：

Readiness通过的时候，应用到底完成了多少真正的业务准备。

如果只是：

端口起来了。

/health返回200。

但数据库、Redis、配置、缓存、下游依赖还没准备好，

那这个Pod只是：

技术上Ready。

并不代表：

业务上Ready。

所以以后再遇到“发布后几十秒503自动恢复”，不要第一时间只盯Ingress和网络。

先把：

Pod启动时间 → Readiness时间 → Endpoint加入时间 → 应用初始化完成时间 → 503时间

对齐。

很多所谓的“偶发503”，真正根因就藏在这几十秒的时间差里。

持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。