阿里云大额充值优惠 阿里云 ACK Ingress 控制器提示 503 Service Temporarily Unavailable 排查

阿里云 ACK Ingress 控制器提示 503 Service Temporarily Unavailable 排查

阿里云 ACK Ingress 控制器提示 503 Service Temporarily Unavailable，通常不等于应用“彻底挂了”，更多时候是入口层、后端服务层或云账号资源层有一环没接上。排查时不要先盯着业务代码，先确认请求到底卡在哪一层。

实际处理里，最常见的分界线只有两种：一类是集群内服务本身没有可用后端；另一类是账号、认证、充值、风控或资源配额问题，导致负载均衡、证书、公网入口没有真正生效。先分清这两类，能少走很多弯路。

先判断 503 是请求链路哪一段返回的

看到 503 时，先做一个最简单的分流判断：

• 集群内直接访问 Service 正常，外网访问 503：优先看 Ingress、负载均衡、证书和域名。
• 集群内访问 Service 也 503：优先看 Pod、Endpoint、探针和端口映射。
• 阿里云大额充值优惠 刚创建资源、刚完成实名认证、刚充值续费后出现：先看账号状态、风控和资源是否已经真正可用。

这个分流很重要。很多人一上来就重建 Ingress，结果只是把问题重复了一遍。

最常见的 5 类原因

1. Service 没有可用 Endpoint

这是最常见的场景之一。后端 Pod 虽然存在，但没有通过就绪检查，或者标签没对上，导致 Service 下面没有任何可转发的后端。Ingress 控制器这时候经常直接返回 503。

排查时看两点就够了：`kubectl get endpoints` 是否为空，Pod 的 `Ready` 是否为 `True`。如果 Endpoint 是空的，先修后端，不要先改 Ingress。

2. Service 端口和容器端口不一致

有些业务迁移后改过容器端口，但 Service 的 `targetPort` 还停留在旧值，或者 Ingress 指向了错误的 Service 端口。表现上看像入口故障，实际上是转发到了一个根本不存在的端口。

这种问题在多环境部署时尤其常见，比如测试环境和生产环境端口配置不一致，复制 YAML 时漏改一个字段，503 就会一直存在。

3. 就绪探针过严，Pod 一直不算可用

阿里云大额充值优惠 Pod 启动后如果 readinessProbe 失败，Kubernetes 会认为它还没准备好接流量。结果就是 Pod 看似运行中，但不进入可转发列表，Ingress 只能返回 503。

常见原因包括：探针路径写错、应用启动时间比预期长、依赖数据库或缓存未就绪、探针超时时间太短。对刚上线的新应用、跨境链路较长的业务、以及有慢启动过程的 Java 服务，这类问题很常见。

4. Ingress 规则写错或 Host/Path 不匹配

如果只有某个域名或某个路径返回 503，优先检查 Ingress 规则是否真的匹配到了请求。常见错误有：

• Host 写错，实际访问域名和规则里的域名不一致。
• Path 前缀配置不对，导致流量没有命中预期规则。
• 同一个域名下多个规则冲突，后写的规则覆盖了前面的转发。

这类问题在业务切流、灰度发布、临时加路径时特别容易出现。

5. 负载均衡、证书、域名还没真正生效

在阿里云 ACK 场景里，Ingress 后面往往还要经过负载均衡、监听器、证书和 DNS 解析。控制台里看起来资源已创建，不代表它已经能稳定接流量。

阿里云大额充值优惠 如果你刚绑定域名、刚换证书、刚改监听端口，或者刚申请公网入口，建议优先看健康检查和解析是否已经生效，而不是先怀疑应用。

不要忽略账号、认证、充值和风控

阿里云大额充值优惠 很多排查文章只写集群配置，但真实项目里，503 有时根本不是技术配置问题，而是账号和资源状态问题。尤其是你在做以下事情时，更要先看控制台状态：

• 账号购买后还没完成实名认证或企业认证，部分资源申请会受限。
• 支付方式未通过审核，或者支付审核卡住，公网资源和证书申请可能延迟。
• 充值续费不及时，欠费后负载均衡、EIP、相关证书或托管资源可能出现不可用状态。
• 短时间频繁创建、释放、重建资源，可能触发风控审核，表现为资源申请成功但实际不可用。
• 资源配额不足，比如负载均衡实例数、公网 IP、证书或节点配额已满，Ingress 规则看着配好了，底层却没有可用承载。

实际项目里，最容易被忽略的一类 503，就是“控制台显示已开通，实际上资源还在审核、欠费、限额或风控处理中”。如果你最近刚换账号、刚做企业认证、刚续费，先查这个，再查 YAML。

按这个顺序排查，通常最快

1. 先看后端 Pod 是否 Ready，Service 有没有 Endpoint。
2. 再看 Service 的端口、目标端口、Selector 是否一致。
3. 检查 Ingress 的 Host、Path、后端 Service 名称是否写对。
4. 查看 Ingress Controller 日志，确认是“找不到后端”还是“转发失败”。
5. 检查负载均衡、监听器、健康检查、证书和 DNS 是否真正生效。
6. 最后回到账号侧，确认实名认证、企业认证、充值续费、支付审核和风控状态。

常见错误

• 一看到 503 就重建 Ingress，结果把定位线索删掉了。
• 只看 Pod 是否 Running，不看 Ready 状态。
• 把控制台里“已创建”当成“已可用”，忽略审核和生效时间。
• 为了省成本只开很少的副本，流量一上来就触发后端不可用。
• 测试环境配置直接复制到生产环境，域名、证书、端口没有同步改。

不同场景怎么处理更合适

FAQ

Q: 重启 ACK Ingress 控制器能解决 503 吗？

A: 只能暂时掩盖问题，不能解决根因。如果是 Endpoint 为空、端口不对、账号欠费或风控未解除，重启完还会再出现。

Q: 只有某个域名 503，其他域名正常，通常查什么？

A: 先查这个域名对应的 Ingress 规则、证书和 DNS 解析，很多时候是 Host 写错或证书没有绑定到正确监听器。

Q: 新开通账号为什么更容易遇到这类问题？

A: 新账号常见卡点不是应用，而是实名认证、企业认证、支付审核、风控和资源配额。资源没完全放通之前，入口层会表现得像 503。

Q: 什么时候该直接找云厂商工单？

A: 当你确认 Pod、Service、Ingress、LB 都正常，账号没有欠费、认证已完成、风控也无异常，但 503 仍持续存在时，就该提交工单。

决策建议

如果你现在是在生产环境，建议先按“后端可用性 - 入口规则 - 账号和资源状态”这个顺序排查，不要先动业务代码。这样能最快判断问题是该修配置、该补资源，还是该先处理实名认证、企业认证、充值续费和风控审核。

如果你是在控制成本的前提下做跨境部署，别把副本、负载均衡和公网资源压到刚好够用。ACK Ingress 的 503 往往不是单点故障，而是资源余量太小、审核未完成或健康检查阈值过严一起叠加出来的。