容器编排平台部署 Web 服务无法访问的排查指南

在容器编排平台上部署了一个 Web 服务，部署清单检查无误、容器状态也显示运行中，但在浏览器里输入访问地址后却长时间无响应、超时，甚至连接被拒绝，这是生产环境中最常见、也最消耗排查时间的故障场景之一。网络类故障的隐蔽性在于：它通常没有直观的报错堆栈，往往表现为间歇性超时、部分节点可达而另一部分不可达、或域名解析失败，很难一眼判断问题出在应用本身、容器网络还是流量入口。

许多团队的第一反应是删除并重建容器实例，或反复微调配置“碰运气”。这种盲试不仅低效，还可能掩盖真因、引发业务抖动。正确的做法是先建立一条严密的证据链：从应用层的连接超时出发，逐层向下追溯服务转发规则、容器网络插件的数据包路径、节点侧代理组件的内核态转发逻辑，最后核对集群 DNS 的解析结果，用证据收敛故障范围，而不是靠猜测。

一、先分域：三类典型故障与“由内向外”的排查顺序

浏览器无法访问，本质上是“客户端 → 外部入口 → 节点端口 → 转发规则 → 容器 → 应用进程”这条链路中的某一环断了。据此可将问题划分为三个典型域：

1. 服务定义与端口错误：服务对象没有正确关联到后端容器实例，或端口映射配置不一致。这是出现频率最高的根因，应最先排查。
2. 容器网络与实例间通信中断：容器网络插件部署或版本异常、跨节点转发链路故障、网络策略误拦截。
3. 外部流量入口异常：节点端口未在防火墙或安全组放行、云侧负载均衡健康检查失败、入口路由规则配置错误。

推荐“由内向外”的三段式验证，每一步都留下明确的通断证据：

• 集群内验证：任选一个业务容器，直接请求服务虚拟 IP 与服务端口；
• 节点本地验证：登录目标节点，请求本机回环地址加节点端口；
• 外部验证：从集群外客户端请求节点 IP 加节点端口，或负载均衡地址。

三段结果交叉对比，故障范围即可收敛到唯一一层。实践中可以总结出一张“现象—方向”对照表：

现象	优先怀疑方向
集群内通、外部不通	防火墙、安全组、负载均衡、入口规则
集群内不通、容器内应用正常	服务定义、标签选择器、后端实例列表
同节点通、跨节点不通	容器网络插件、内核参数漂移
IP 直连通、域名不通	集群 DNS 或客户端解析
小请求正常、大请求超时	隧道 MTU 不匹配

二、问题域一：服务端口定义与后端实例检查

绝大多数“部署成功但访问不通”的案例，根因都落在服务定义上。首先必须分清三个容易混淆的端口概念：

• port：服务对象自身对集群内暴露的端口；
• targetPort：后端容器内应用真正监听的端口；
• nodePort：通过节点 IP 对集群外暴露时使用的端口。

最经典的错误是 targetPort 与应用实际监听端口不一致；另一种更隐蔽的情况是应用在容器内只监听了 127.0.0.1 而非 0.0.0.0，此时从容器外部无论怎么连都不通，但在容器内部自测一切正常，极易被误判为网络问题。

第二类高频错误是标签选择器与容器实例的标签不匹配，导致服务背后没有挂载任何健康实例（后端实例列表为空），此时访问服务地址会直接超时或被拒绝。一段典型的服务暴露示意配置如下（字段以实际使用的编排系统为准）：

metadata:
  name: web-service
spec:
  type: NodePort          # 通过节点端口对外暴露
  selector:
    app: web              # 必须与后端容器实例的标签逐字一致
  ports:
    - port: 80            # 服务自身对集群内暴露的端口
      targetPort: 8080    # 容器内应用真正监听的端口
      nodePort: 30080     # 节点上对外暴露的端口

本域排查清单：

1. 确认服务对象的后端实例列表已挂载健康实例，若为空，逐字核对标签选择器与实例标签；
2. 确认 targetPort 与镜像内应用监听端口一致，且应用监听地址为 0.0.0.0；
3. 确认服务端口、节点端口均在合法且未被占用的范围内；
4. 在集群内其他容器中直接请求服务虚拟 IP 与端口，取得集群内可达性的基准证据。

三、问题域二：容器网络与跨节点通信

当集群内访问也不通时，问题通常出在容器网络层，常见根因有四类：

1. 容器网络插件（CNI）未正确部署或版本不兼容。插件负责为容器分配 IP 并维护节点间的路由或隧道；若其版本与内核、容器运行时不匹配，会出现部分节点上的实例互相不可达、IP 分配冲突等“间歇性”故障。升级编排组件或运行时前，务必核对插件兼容性。
2. 跨节点转发链路异常。多数方案通过隧道封装（如 VXLAN）或直接路由打通节点间网络。隧道两端的 MTU 不一致会导致大包被静默丢弃，表现为心跳类小请求正常，而携带较大载荷的 HTTP 请求超时，极具迷惑性。
3. 网络策略误拦截。启用网络策略后，若放行规则不完整，来自服务代理组件或入口组件的流量可能被静默丢弃，且不产生任何应用层报错。
4. 节点内核参数不一致。IP 转发未开启、网桥流量未纳入转发规则处理等参数在节点间发生配置漂移，会造成“部分节点正常、部分节点异常”的典型现象，这也是排查中反复强调配置基线的原因。

验证手段：分别在同节点与跨节点各选两个容器实例互发请求，对比结果差异；再在源端与目的端同时抓包，观察请求包是否发出、是否到达对端、有无回包，若只有出没有回，基本可锁定中间链路（隧道、路由或策略）在丢包。

四、问题域三：外部流量入口异常

集群内一切正常、浏览器却无法访问时，问题集中在“最后一公里”：

1. 节点端口未放行。云环境的安全组与主机防火墙默认很可能没有放行节点端口范围，需确认放行的是整个端口段而非单个示例端口，这是新手最常见的“最后一击”。
2. 负载均衡健康检查失败。若通过负载均衡对外暴露，健康检查探测的端口、协议或路径与实际服务不一致，会把所有后端节点摘除，外部表现为连接超时或 502/504 类错误。
3. 入口规则配置错误。若通过入口控制器（Ingress）暴露 HTTP/HTTPS 服务，需核对路由规则中的域名、路径与后端服务端口是否匹配，证书是否有效；入口控制器自身实例异常也会导致全部路由失效。
4. 流量保持策略的影响。服务的外部流量策略若未按需保留客户端源 IP，可能影响会话保持与转发路径，需结合业务要求核对。

若集群运行在云上托管容器平台（例如百度智能云等云厂商提供的容器服务），还应在云控制台同步核对负载均衡监听器、健康检查与安全组配置，云侧与集群侧配置不一致，是托管环境下独有的高频问题。

五、深层排查：转发规则与集群 DNS

当以上三层“看起来都正常”却依然不通时，需要深入节点侧的转发机制与解析体系。

转发规则的生成与核对。 节点上的服务代理组件会根据服务与后端实例的变化，把“服务虚拟 IP:端口 → 某个具体容器 IP:端口”的映射写入内核转发规则，常见形态是 iptables 的 NAT 表规则或 IPVS 的虚拟服务器表。排查时应核对三点：目标端口的规则是否存在；规则指向的后端是否为当前健康的实例；是否残留了已删除服务的陈旧条目。若采用 IPVS 模式，还需关注调度策略与会话保持配置，以及规则同步延迟造成的短暂不一致。

集群 DNS 的影响。 若访问使用域名，解析失败会直接表现为“无法访问”。集群 DNS 组件的缓存污染、上游转发配置错误或 DNS 实例自身异常，都会造成间歇性解析失败。一个快速判定方法：在客户端分别用 IP 直连与域名访问，若 IP 直连通而域名不通，即可把故障锁定在解析层。

抓包定位丢包点。 在节点入口网卡、隧道网卡与容器网卡分别观察数据包，可以精确判断包在哪一跳消失，把“网络不通”细化到“某条规则缺失”或“某段隧道丢包”，这是该层最有力的定位手段。

六、工程化沉淀：用证据链缩短 MTTR

实践证明，大多数看似复杂的网络故障，根源往往集中在三类问题上：节点代理组件与内核参数的配置差异、容器网络插件的版本兼容性、服务端口定义错误。围绕这三点做工程化建设，才能真正降低平均恢复时间（MTTR）：

1. 配置基线管理：所有节点的内核参数与代理组件配置纳入统一管理，杜绝节点间漂移；
2. 版本兼容矩阵：升级容器网络插件、容器运行时或编排组件前，先核对兼容性，灰度验证后再全量推进；
3. 可观测性建设：将转发规则变更、网络策略命中、DNS 解析成功率、节点间连通性探测纳入监控告警，并借助集中化的日志服务做多侧日志的时间线关联，客户端、负载均衡、节点、容器四侧日志对齐后，往往几分钟就能锁定断点；
4. 发布前自检清单：每次部署完成后，先跑一遍“集群内 → 节点本地 → 外部”三段式验证，全部通过再对外宣布发布完成。

相比故障后的盲目重启，“事前预防 + 事后按证据链收敛”的组合拳，既能避免重启掩盖真因导致故障反复，也能显著压缩故障处理时长。

结语

浏览器无法访问从来不是一个孤立问题，而是访问链路中某一环失效的外在表现。把“客户端 → 入口 → 节点 → 转发规则 → 容器 → 应用”作为固定的思维框架，用端口检查、连通性探测与抓包分析逐层取证，绝大多数问题都能在很短时间内定位。记住这条经验法则：先查服务定义与端口映射，再查容器网络与策略，最后查外部入口与 DNS——由内向外，用证据说话，不靠猜。