Kubernetes Ingress配置后外部访问不通的实战步骤和排查路径

马哥Linux运维 2026-08-28 160

描述

问题背景

在 Kubernetes 集群中部署应用后，运维同学经常遇到这样的场景：Deployment 创建了，Pod 状态是 Running，Service 也配置了，Ingress 规则也写好了，但外部用户就是访问不到服务。浏览器返回 502、503 或者直接超时，curl 测试也没有响应。

这种问题特别让人抓狂，因为每一层看起来都是正常的：Pod 没有 CrashLoopBackOff，Service Endpoints 有 IP，Ingress 配置语法也没错。但整个链路就是不通。问题可能出在 Ingress Controller 配置、Service 端口映射、Pod 网络策略、kube-proxy 规则、DNS 解析、负载均衡器健康检查，甚至云厂商的安全组规则。

本文面向初中级 Kubernetes 运维工程师和 DevOps 工程师，演示如何在 Ingress 配置后外部访问不通的场景下，从外到内逐层排查：先确认 Ingress Controller 状态，再验证 Service 和 Endpoints，再测试 Pod 网络连通性，最后排查 DNS、负载均衡器和安全组。读者能照着文章操作、观察日志、判断根因，并制定对应的修复方案。

适用场景

本文适用于以下场景：

Ingress 规则已创建，但外部无法访问服务
浏览器返回 502 Bad Gateway、503 Service Unavailable、504 Gateway Timeout
curl 测试返回连接超时、连接拒绝
Ingress Controller 日志显示 upstream 错误
Service 和 Pod 看起来正常，但流量到不了 Pod
需要排查 Ingress、Service、Endpoints、Pod、NetworkPolicy、DNS、LB 的完整链路

不适用场景：

Pod 本身无法启动（应先排查容器镜像、资源限制、挂载卷）
应用内部逻辑错误（如 HTTP 500、数据库连接失败）
集群内部 Service 访问正常，只是 Ingress 不通（重点排查 Ingress 和 Ingress Controller）

核心知识点

Kubernetes 网络流量链路

外部请求到达 Pod 的完整路径：

外部客户端     ↓ DNS 解析（域名 → LoadBalancer IP）     ↓ 云厂商 LoadBalancer / NodePort / HostNetwork     ↓ Ingress Controller Pod（Nginx、Traefik、HAProxy 等）     ↓ Kubernetes Service（ClusterIP）     ↓ kube-proxy iptables/ipvs 规则     ↓ Pod IP     ↓ 应用容器端口

排查时要从外往内走，每一层都验证连通性和配置。

Ingress 工作原理

Ingress 本身只是一个配置对象，描述了"哪个域名、哪个路径应该转发到哪个 Service"。真正干活的是 Ingress Controller，它是一个运行在集群中的 Pod（通常是 Nginx、Traefik、HAProxy、Istio Gateway 等），会监听 Ingress 对象的变化，动态生成反向代理配置，然后将流量转发到后端 Service。

Ingress Controller 通过以下方式暴露给外部：

LoadBalancer Service：云厂商分配公网 IP，流量进入 LoadBalancer → Ingress Controller Pod
NodePort Service：在每个 Node 上监听一个端口（默认 30000-32767），流量进入 NodeIP:NodePort → Ingress Controller Pod
HostNetwork：Ingress Controller Pod 直接使用宿主机网络，监听 80/443 端口

Service 和 Endpoints

Service 是一个虚拟 IP（ClusterIP），流量到达 Service 后，kube-proxy 会根据 iptables 或 ipvs 规则将流量转发到后端 Pod。Service 后端 Pod 列表由 Endpoints 对象维护。

如果 Endpoints 为空，说明没有 Pod 匹配 Service 的 selector，流量无法转发。

NetworkPolicy

NetworkPolicy 可以限制 Pod 之间的网络访问。如果配置了 NetworkPolicy，可能导致 Ingress Controller Pod 无法访问后端 Pod。

排查思路

外部访问失败     ↓ 1. 确认 Ingress Controller Pod 状态和日志     ↓ 2. 确认 Ingress 规则语法和 Service 引用     ↓ 3. 确认 Service 和 Endpoints 是否有后端 Pod     ↓ 4. 确认后端 Pod 状态和监听端口     ↓ 5. 测试 Ingress Controller → Service → Pod 的网络连通性     ↓ 6. 排查 NetworkPolicy     ↓ 7. 排查 DNS 解析     ↓ 8. 排查 LoadBalancer / NodePort 配置     ↓ 9. 排查云厂商安全组、防火墙     ↓ 10. 根据以上信息定位根因并修复

整体排查思路

分层逐步验证：

Ingress Controller 层：Controller Pod 是否 Running，Service 是否暴露，日志有无错误
Ingress 规则层：规则语法是否正确，backend Service 是否存在，host 和 path 是否匹配
Service 层：Service 是否存在，Endpoints 是否有 Pod IP，端口映射是否正确
Pod 层：Pod 是否 Running，容器端口是否监听，应用是否正常
网络策略层：NetworkPolicy 是否阻止流量
DNS 层：域名解析是否指向正确的 IP
LoadBalancer 层：云厂商 LB 健康检查是否通过，监听器配置是否正确
防火墙和安全组层：云厂商安全组、iptables 规则是否放行

实战步骤

第一步：确认 Ingress Controller Pod 状态

目的

确认 Ingress Controller 本身是否正常运行。

操作

bash

# 查看 Ingress Controller Pod（常见命名空间：ingress-nginx、kube-system、istio-system） kubectl get pods -n ingress-nginx kubectl get pods -n kube-system | grep ingress kubectl get pods -A | grep ingress # 查看 Pod 详情 kubectl describe pod  -n ingress-nginx # 查看 Pod 日志 kubectl logs  -n ingress-nginx --tail=100 kubectl logs  -n ingress-nginx -f

预期输出

Pod 状态应该是 Running，Ready 应该是 1/1 或 2/2（根据容器数量）：

NAME                                        READY   STATUS    RESTARTS   AGE ingress-nginx-controller-5d88495688-abcde   1/1     Running   0          10d

日志应该没有严重错误，能看到启动信息和配置加载记录：

2026-08-26 1000 [notice] 1#1: start worker processes 2026-08-26 1000 [notice] 1#1: nginx configuration is reloaded

异常表现

Pod 状态是 Pending、CrashLoopBackOff、ImagePullBackOff → Ingress Controller 本身没启动
Ready 是 0/1 → 容器启动失败或健康检查失败
日志中出现 failed to load configuration、failed to update Ingress status、upstream connect error → 配置加载失败或后端不可达

判断逻辑

如果 Pod 不是 Running → 优先解决 Controller 启动问题
如果 Pod 是 Running 但日志有错误 → 根据错误信息排查
如果 Pod 正常 → 继续下一步

下一步动作

记录 Ingress Controller 的命名空间、Pod 名称、日志关键信息。

第二步：确认 Ingress Controller Service 暴露方式

目的

确认 Ingress Controller 是否正确暴露给外部。

操作

bash

# 查看 Ingress Controller Service kubectl get svc -n ingress-nginx kubectl get svc -n kube-system | grep ingress # 查看 Service 详情 kubectl describe svc  -n ingress-nginx

预期输出

Service 类型应该是 LoadBalancer、NodePort 或者 Controller Pod 使用 hostNetwork: true：

LoadBalancer 类型：

NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                      AGE ingress-nginx-controller             LoadBalancer   10.96.100.100   203.0.113.50      80:32080/TCP,443:32443/TCP   10d

EXTERNAL-IP 应该是一个公网 IP（云厂商分配），不应该是或。

NodePort 类型：

NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE ingress-nginx-controller             NodePort       10.96.100.100           80:32080/TCP,443:32443/TCP   10d

可以通过任意 NodeIP:32080 访问。

hostNetwork 类型：

如果 Controller Pod 使用 hostNetwork: true，Service 可能不需要 LoadBalancer 或 NodePort，直接通过 Node IP 的 80/443 端口访问。

bash# 检查 Pod 是否使用 hostNetwork kubectl get pod -n ingress-nginx -o yaml | grep hostNetwork

异常表现

EXTERNAL-IP 是 → 云厂商 LoadBalancer 未分配，检查云厂商配额、权限
EXTERNAL-IP 是且类型不是 NodePort → Ingress Controller 没有暴露方式
Service 不存在 → Ingress Controller 安装不完整

判断逻辑

如果是 LoadBalancer 且有 EXTERNAL-IP → 记录这个 IP，继续下一步
如果是 NodePort → 记录 NodePort 端口（如 32080），继续下一步
如果是 hostNetwork → 记录 Node IP，继续下一步
如果没有暴露方式 → 需要创建 Service 或修改 Controller 配置

下一步动作

记录 Ingress Controller 的外部访问入口（LoadBalancer IP、NodePort、Node IP）。

第三步：测试 Ingress Controller 入口连通性

目的

确认能否访问到 Ingress Controller 的默认后端或健康检查端点。

操作

bash

# 如果是 LoadBalancer curl -I http:// curl -I http:///healthz # 如果是 NodePort curl -I http://: curl -I http://:/healthz # 如果是 hostNetwork curl -I http:// curl -I http:///healthz # 测试 HTTPS（如果配置了证书） curl -Ik https://

预期输出

应该能收到响应，即使是 404 或 default backend 也说明 Ingress Controller 可达：

HTTP/1.1 404 Not Found Server: nginx Date: Tue, 26 Aug 2026 1000 GMT Content-Type: text/html Content-Length: 146 Connection: keep-alive

或者：

HTTP/1.1 200 OK Server: nginx Date: Tue, 26 Aug 2026 1000 GMT Content-Type: text/plain Content-Length: 2 Connection: keep-alive ok

异常表现

连接超时 → 网络不通，检查防火墙、安全组、路由
连接拒绝 → Ingress Controller 没有监听端口，检查 Controller 配置
没有响应 → 检查 LoadBalancer 健康检查、Node 状态

判断逻辑

如果能收到响应 → Ingress Controller 入口正常，继续排查 Ingress 规则
如果连接超时 → 检查防火墙、安全组、LoadBalancer 监听器
如果连接拒绝 → 检查 Controller Pod 和 Service 配置

下一步动作

如果入口正常，继续下一步。

第四步：检查 Ingress 规则配置

目的

确认 Ingress 规则语法正确，backend Service 存在，host 和 path 匹配。

操作

bash

# 查看 Ingress 资源 kubectl get ingress -A kubectl get ingress -n  # 查看 Ingress 详情 kubectl describe ingress  -n  # 查看 Ingress YAML kubectl get ingress  -n  -o yaml

预期输出

yaml

apiVersion: networking.k8s.io/v1 kind: Ingress metadata:   name: example-ingress   namespace: default spec:   ingressClassName: nginx  # 或者通过 annotation 指定   rules:   - host: example.com     http:       paths:       - path: /api         pathType: Prefix         backend:           service:             name: backend-service             port:               number: 8080

kubectl describe ingress 输出：

Name:             example-ingress Namespace:        default Address:          203.0.113.50 Ingress Class:    nginx Rules:   Host        Path  Backends   ----        ----  --------   example.com               /api   backend-service:8080 (10.244.1.10:8080,10.244.2.20:8080)

关键字段：

Address：应该是 Ingress Controller 的 LoadBalancer IP，如果是空或，说明 Controller 没有更新 Ingress 状态
Ingress Class：应该匹配 Ingress Controller 的 ingressClassName
Backends：应该显示 Service 名称、端口和 Endpoints IP

异常表现

Address 是空 → Ingress Controller 没有更新 Ingress 状态，检查 Controller 日志
Backends 显示或 → Service 不存在或 Endpoints 为空
Ingress Class 不匹配 → Ingress 不会被当前 Controller 处理
host 或 path 配置错误 → 请求不会匹配到这个 Ingress

判断逻辑

如果 Address 是空 → 检查 Ingress Controller 权限和日志
如果 Backends 显示错误 → 检查 Service 和 Endpoints
如果配置正确 → 继续下一步

下一步动作

记录 Ingress 的 host、path、backend Service 名称和端口。

第五步：检查 Service 和 Endpoints

目的

确认 Service 存在，Endpoints 有后端 Pod IP，端口映射正确。

操作

bash

# 查看 Service kubectl get svc  -n  # 查看 Service 详情 kubectl describe svc  -n  # 查看 Service YAML kubectl get svc  -n  -o yaml # 查看 Endpoints kubectl get endpoints  -n  # 查看 Endpoints 详情 kubectl describe endpoints  -n

预期输出

Service：

NAME               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE backend-service    ClusterIP   10.96.200.100           8080/TCP   5d

Endpoints：

NAME               ENDPOINTS                          AGE backend-service    10.244.1.10:8080,10.244.2.20:8080  5d

或者：

bashkubectl describe endpoints backend-service -n default

输出：

Name:         backend-service Namespace:    default Labels:        Annotations:   Subsets:   Addresses:          10.244.1.10,10.244.2.20   NotReadyAddresses:     Ports:     Name     Port  Protocol     ----     ----  --------     http     8080  TCP

异常表现

Endpoints 是或显示 NotReadyAddresses → 没有 Ready 的 Pod
Endpoints IP 数量为 0 → Service selector 没有匹配到 Pod
Service 端口与 Ingress backend 端口不一致 → 端口映射错误
Service 不存在 → Ingress backend 引用错误

判断逻辑

如果 Endpoints 为空 → 检查 Pod 和 Service selector
如果 Endpoints 有 IP → 继续下一步

下一步动作

记录 Endpoints 中的 Pod IP 和端口。

第六步：检查后端 Pod 状态和标签

目的

确认 Pod 是否 Running，标签是否匹配 Service selector，端口是否监听。

操作

bash

# 查看 Pod kubectl get pods -n  -l  # 查看 Pod 详情 kubectl describe pod  -n  # 查看 Pod 标签 kubectl get pod  -n  --show-labels # 检查 Service selector kubectl get svc  -n  -o jsonpath='{.spec.selector}' # 进入 Pod 检查监听端口 kubectl exec -it  -n  -- netstat -tlnp kubectl exec -it  -n  -- ss -tlnp

预期输出

Pod 状态：

NAME                                READY   STATUS    RESTARTS   AGE backend-deployment-5d88495688-abc   1/1     Running   0          5d backend-deployment-5d88495688-def   1/1     Running   0          5d

Pod 标签：

NAME                                READY   STATUS    RESTARTS   AGE   LABELS backend-deployment-5d88495688-abc   1/1     Running   0          5d    app=backend,version=v1

Service selector：

json{"app":"backend"}

监听端口：

Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1/python

异常表现

Pod 状态不是 Running → Pod 启动失败，检查容器日志、镜像、资源限制
Pod 标签与 Service selector 不匹配 → Service 找不到 Pod
Pod 没有监听端口 → 应用没有启动或端口配置错误
Ready 是 0/1 → 健康检查失败

判断逻辑

如果 Pod 不是 Running → 优先解决 Pod 启动问题
如果标签不匹配 → 修改 Pod 标签或 Service selector
如果没有监听端口 → 检查应用配置
如果 Pod 正常 → 继续下一步

下一步动作

确认 Pod 正常后，测试网络连通性。

第七步：测试 Ingress Controller 到 Service 的连通性

目的

确认 Ingress Controller Pod 能否访问后端 Service。

操作

bash

# 进入 Ingress Controller Pod kubectl exec -it  -n ingress-nginx -- /bin/sh # 在 Controller Pod 中测试 Service curl http://..svc.cluster.local: # 或者直接测试 ClusterIP curl http://: # 退出 exit

预期输出

应该能收到后端应用的响应：

HTTP/1.1 200 OK Content-Type: application/json Content-Length: 123 {"status":"ok"}

异常表现

连接超时 → Service 或 Pod 不可达，检查网络策略、kube-proxy
连接拒绝 → Pod 没有监听端口
返回错误（如 500）→ 应用逻辑错误

判断逻辑

如果能正常访问 → Service 到 Pod 的链路正常，问题可能在 Ingress 规则或外部访问
如果连接超时 → 检查 NetworkPolicy、kube-proxy 规则

下一步动作

如果连通性正常，回到 Ingress 规则排查。

第八步：测试 Service 到 Pod 的直接连通性

目的

绕过 Service，直接访问 Pod IP，排除 kube-proxy 规则问题。

操作

bash

# 获取 Pod IP kubectl get pod  -n  -o jsonpath='{.status.podIP}' # 进入 Ingress Controller Pod 或其他 Pod kubectl exec -it  -n ingress-nginx -- /bin/sh # 直接访问 Pod IP curl http://: # 退出 exit

预期输出

应该能收到后端应用的响应。

异常表现

连接超时 → Pod 网络不通，检查 CNI、NetworkPolicy
连接拒绝 → Pod 端口配置错误

判断逻辑

如果直接访问 Pod IP 正常，但通过 Service 不正常 → kube-proxy 规则问题
如果直接访问也不正常 → Pod 网络或应用问题

下一步动作

根据测试结果排查对应层面。

第九步：检查 NetworkPolicy

目的

确认是否有 NetworkPolicy 阻止 Ingress Controller 访问后端 Pod。

操作

bash

# 查看所有 NetworkPolicy kubectl get networkpolicy -A # 查看特定命名空间的 NetworkPolicy kubectl get networkpolicy -n  # 查看 NetworkPolicy 详情 kubectl describe networkpolicy  -n  # 查看 NetworkPolicy YAML kubectl get networkpolicy  -n  -o yaml

预期输出

如果没有 NetworkPolicy，输出为空：

No resources found in namespace.

如果有 NetworkPolicy，检查 podSelector 和 ingress 规则是否允许 Ingress Controller 访问：

yaml

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata:   name: backend-policy   namespace: default spec:   podSelector:     matchLabels:       app: backend   policyTypes:   - Ingress   ingress:   - from:     - namespaceSelector:         matchLabels:           name: ingress-nginx     ports:     - protocol: TCP       port: 8080

异常表现

有 NetworkPolicy 但没有允许 Ingress Controller 的规则 → 流量被阻止

判断逻辑

如果没有 NetworkPolicy → 不是 NetworkPolicy 问题
如果有 NetworkPolicy 但规则不允许 Ingress Controller → 修改 NetworkPolicy 或删除

下一步动作

如果 NetworkPolicy 正常，继续排查外部访问。

第十步：检查 DNS 解析

目的

确认域名解析是否指向 Ingress Controller 的 LoadBalancer IP 或 NodePort。

操作

bash

# 本地测试 DNS 解析 nslookup example.com dig example.com # 在集群外的客户端测试 curl -v http://example.com/api

预期输出

DNS 解析应该返回 Ingress Controller 的 EXTERNAL-IP：

Server:8.8.8.8 Address:8.8.8.8#53 Non-authoritative answer: Name:example.com Address: 203.0.113.50

异常表现

域名解析不到 IP → DNS 记录未配置或传播未完成
域名解析到错误的 IP → DNS 记录配置错误

判断逻辑

如果 DNS 解析正确 → 继续排查 HTTP 请求
如果 DNS 解析错误 → 修改 DNS 记录

下一步动作

如果 DNS 正确，使用 curl 测试完整请求。

第十一步：使用 curl 测试完整请求

目的

模拟真实请求，观察返回结果和错误信息。

操作

bash

# 测试 HTTP 请求，显示详细信息 curl -v http://example.com/api # 测试 HTTPS 请求 curl -vk https://example.com/api # 指定 Host 头（如果 DNS 未配置） curl -v -H "Host: example.com" http:///api # 查看响应头 curl -I http://example.com/api

预期输出

应该收到后端应用的响应：

< HTTP/1.1 200 OK < Server: nginx < Date: Tue, 26 Aug 2026 1000 GMT < Content-Type: application/json < Content-Length: 123 < {"status":"ok"}

异常表现

HTTP/1.1 502 Bad Gateway → Ingress Controller 无法连接后端
HTTP/1.1 503 Service Unavailable → 后端无可用 Pod
HTTP/1.1 504 Gateway Timeout → 后端响应超时
HTTP/1.1 404 Not Found → Ingress 规则不匹配或路径错误
连接超时 → 网络不通，检查防火墙、安全组
证书错误 → TLS 配置问题

判断逻辑

502 → 检查 Ingress Controller 日志、Service、Endpoints
503 → 检查 Endpoints 是否有 Pod
504 → 检查 Pod 应用性能、超时配置
404 → 检查 Ingress 规则的 host 和 path
连接超时 → 检查防火墙、安全组、LoadBalancer

下一步动作

根据错误码排查对应层面。

第十二步：查看 Ingress Controller 日志

目的

从 Ingress Controller 视角看请求处理过程和错误信息。

操作

bash

# 实时查看日志 kubectl logs  -n ingress-nginx -f # 查看最近 100 行 kubectl logs  -n ingress-nginx --tail=100 # 过滤特定域名或路径 kubectl logs  -n ingress-nginx | grep "example.com" kubectl logs  -n ingress-nginx | grep "/api"

预期输出

正常情况下，能看到访问日志：

203.0.113.100 - - [26/Aug/202600:00 +0000] "GET /api HTTP/1.1" 200 123 "-" "curl/7.68.0" 0.005

异常表现

502 或 503 且日志显示 no live upstreams → Endpoints 为空
502 且日志显示 upstream prematurely closed connection → Pod 主动关闭连接
502 且日志显示 connect() failed (111: Connection refused) → Pod 端口未监听
504 且日志显示 upstream timed out → Pod 响应慢
没有日志 → 请求没有到达 Ingress Controller，检查 LoadBalancer、DNS

判断逻辑

根据日志中的错误信息定位问题层面。

下一步动作

根据日志定位根因。

第十三步：检查云厂商 LoadBalancer 配置

目的

确认云厂商的 LoadBalancer 健康检查、监听器、安全组配置正确。

操作

登录云厂商控制台，检查：

负载均衡器：是否创建成功，状态是否正常
监听器：80/443 端口是否监听，转发规则是否正确
后端服务器组：是否包含 Node，健康检查是否通过
健康检查：路径、端口、协议是否正确
安全组：是否放行 80/443 端口

预期输出

负载均衡器状态：运行中
监听器：80/443 → NodePort（如 32080/32443）
后端服务器：包含所有 Node，健康检查全部通过
安全组：入方向放行 0.0.0.0/0 的 80/443 端口

异常表现

负载均衡器状态异常 → 联系云厂商支持
监听器配置错误 → 修改监听器
后端服务器健康检查失败 → 检查 Node 状态、NodePort 端口
安全组未放行 → 修改安全组规则

判断逻辑

根据云厂商控制台信息排查。

下一步动作

根据云厂商配置调整。

第十四步：检查 Node 防火墙和安全组

目的

确认 Node 防火墙和云厂商安全组放行 Ingress Controller 使用的端口。

操作

bash

# 在 Node 上检查 iptables 规则 iptables -L -n -v | grep  # 检查 firewalld 状态 systemctl status firewalld firewall-cmd --list-all # 检查 ufw 状态 ufw status # 测试从外部访问 NodePort curl http://:

云厂商安全组：

登录控制台，检查 Node 实例的安全组
确认入方向规则放行 NodePort 端口（如 32080/32443）

预期输出

iptables 或 firewalld 没有 DROP NodePort 端口的规则
云厂商安全组放行 NodePort 端口
从外部能访问 NodePort

异常表现

iptables 或 firewalld 阻止 NodePort → 修改规则
云厂商安全组未放行 → 修改安全组

判断逻辑

根据防火墙和安全组规则调整。

下一步动作

修复防火墙或安全组配置。

常用命令

kubectl 常用命令

bash

# 查看 Ingress kubectl get ingress -A kubectl describe ingress  -n  kubectl get ingress  -n  -o yaml # 查看 Ingress Controller Pod kubectl get pods -n ingress-nginx kubectl logs  -n ingress-nginx -f kubectl describe pod  -n ingress-nginx # 查看 Service kubectl get svc  -n  kubectl describe svc  -n  # 查看 Endpoints kubectl get endpoints  -n  kubectl describe endpoints  -n  # 查看 Pod kubectl get pods -n  -l  kubectl describe pod  -n  kubectl logs  -n  # 查看 NetworkPolicy kubectl get networkpolicy -A kubectl describe networkpolicy  -n  # 进入 Pod kubectl exec -it  -n  -- /bin/sh # 端口转发（调试用） kubectl port-forward svc/ 8080:8080 -n

curl 测试命令

bash

# 基础测试 curl http://example.com/api curl https://example.com/api # 显示详细信息 curl -v http://example.com/api curl -vk https://example.com/api # 指定 Host 头 curl -H "Host: example.com" http:///api # 只显示响应头 curl -I http://example.com/api # 显示响应时间 curl -o /dev/null -s -w "%{time_total} " http://example.com/api

网络测试命令

bash

# DNS 解析 nslookup example.com dig example.com # 测试端口连通性 telnet   nc -zv   # 测试 HTTP wget -O- http://example.com/api

配置示例

Ingress 配置示例（Nginx Ingress Controller）

yaml

apiVersion: networking.k8s.io/v1 kind: Ingress metadata:   name: example-ingress   namespace: default   annotations:     nginx.ingress.kubernetes.io/rewrite-target: /     nginx.ingress.kubernetes.io/ssl-redirect: "false" spec:   ingressClassName: nginx   rules:   - host: example.com     http:       paths:       - path: /api         pathType: Prefix         backend:           service:             name: backend-service             port:               number: 8080   tls:   - hosts:     - example.com     secretName: example-tls

Service 配置示例

yaml

apiVersion: v1 kind: Service metadata:   name: backend-service   namespace: default spec:   selector:     app: backend   ports:   - protocol: TCP     port: 8080     targetPort: 8080   type: ClusterIP

Deployment 配置示例

yaml

apiVersion: apps/v1 kind: Deployment metadata:   name: backend-deployment   namespace: default spec:   replicas: 2   selector:     matchLabels:       app: backend   template:     metadata:       labels:         app: backend     spec:       containers:       - name: backend         image: myapp:v1.0         ports:         - containerPort: 8080         livenessProbe:           httpGet:             path: /health             port: 8080           initialDelaySeconds: 30           periodSeconds: 10         readinessProbe:           httpGet:             path: /ready             port: 8080           initialDelaySeconds: 5           periodSeconds: 5

NetworkPolicy 配置示例（允许 Ingress Controller 访问）

yaml

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata:   name: allow-ingress-controller   namespace: default spec:   podSelector:     matchLabels:       app: backend   policyTypes:   - Ingress   ingress:   - from:     - namespaceSelector:         matchLabels:           name: ingress-nginx     ports:     - protocol: TCP       port: 8080

说明：

namespaceSelector 匹配 Ingress Controller 所在命名空间（需要给命名空间打标签）
如果 Ingress Controller 在 ingress-nginx 命名空间，需要执行：

bashkubectl label namespace ingress-nginx name=ingress-nginx

LoadBalancer Service 配置示例（Ingress Controller）

yaml

apiVersion: v1 kind: Service metadata:   name: ingress-nginx-controller   namespace: ingress-nginx spec:   type: LoadBalancer   selector:     app.kubernetes.io/name: ingress-nginx     app.kubernetes.io/component: controller   ports:   - name: http     port: 80     targetPort: http     protocol: TCP   - name: https     port: 443     targetPort: https     protocol: TCP

NodePort Service 配置示例（Ingress Controller）

yaml

apiVersion: v1 kind: Service metadata:   name: ingress-nginx-controller   namespace: ingress-nginx spec:   type: NodePort   selector:     app.kubernetes.io/name: ingress-nginx     app.kubernetes.io/component: controller   ports:   - name: http     port: 80     targetPort: http     protocol: TCP     nodePort: 32080   - name: https     port: 443     targetPort: https     protocol: TCP     nodePort: 32443

日志或指标观察方法

Ingress Controller 日志关键字

bash

# 查看 502/503 错误 kubectl logs  -n ingress-nginx | grep -E "502|503" # 查看 upstream 错误 kubectl logs  -n ingress-nginx | grep "upstream" # 查看连接拒绝 kubectl logs  -n ingress-nginx | grep "Connection refused" # 查看超时 kubectl logs  -n ingress-nginx | grep "timeout"

Pod 日志关键字

bash

# 查看应用启动日志 kubectl logs  -n  | head -50 # 查看错误日志 kubectl logs  -n  | grep -iE "error|exception|fail" # 查看健康检查日志 kubectl logs  -n  | grep -iE "health|ready"

监控指标

如果有 Prometheus + kube-state-metrics，关注以下指标：

# Ingress 状态 kube_ingress_info kube_ingress_path # Service Endpoints 数量 kube_endpoint_address_available # Pod 状态 kube_pod_status_phase kube_pod_container_status_ready # Ingress Controller 指标（需要 Ingress Controller 暴露 metrics） nginx_ingress_controller_requests nginx_ingress_controller_request_duration_seconds nginx_ingress_controller_response_size

Grafana 面板配置示例

# Ingress Controller 请求率 rate(nginx_ingress_controller_requests[1m]) # Ingress Controller 错误率 rate(nginx_ingress_controller_requests{status=~"5.."}[1m]) / rate(nginx_ingress_controller_requests[1m]) # Service Endpoints 数量 kube_endpoint_address_available{service="backend-service"} # Pod Ready 数量 sum(kube_pod_container_status_ready{pod=~"backend-.*"})

排查路径

路径一：502 Bad Gateway

现象：

curl 返回 HTTP/1.1 502 Bad Gateway
Ingress Controller 日志显示 connect() failed (111: Connection refused) 或 no live upstreams

排查步骤：

检查 Endpoints 是否为空
检查 Pod 是否 Running
检查 Pod 是否监听端口
检查 Service 端口映射是否正确
测试从 Ingress Controller Pod 访问 Service

修复方向：

Endpoints 为空 → 修复 Pod 或 Service selector
Pod 未监听端口 → 修复应用配置
Service 端口错误 → 修改 Service 配置

路径二：503 Service Unavailable

现象：

curl 返回 HTTP/1.1 503 Service Unavailable
Ingress Controller 日志显示 no live upstreams

排查步骤：

检查 Endpoints 是否有 Ready 的 Pod
检查 Pod readinessProbe 是否失败
检查 Pod 应用启动是否完成

修复方向：

readinessProbe 失败 → 修复应用或调整探针配置
Pod 未就绪 → 等待应用启动或修复启动错误

路径三：504 Gateway Timeout

现象：

curl 返回 HTTP/1.1 504 Gateway Timeout
Ingress Controller 日志显示 upstream timed out

排查步骤：

检查 Pod 应用是否响应慢
检查 Ingress Controller 超时配置
检查 Pod 资源是否不足

修复方向：

应用响应慢 → 优化应用性能
超时配置过短 → 调大 Ingress annotation 中的超时配置
资源不足 → 调大 Pod 资源限制

路径四：404 Not Found

现象：

curl 返回 HTTP/1.1 404 Not Found
Ingress Controller 日志没有匹配的路由

排查步骤：

检查 Ingress 规则的 host 是否匹配
检查 Ingress 规则的 path 是否匹配
检查请求的 URL 路径是否正确
检查 Ingress ingressClassName 是否正确

修复方向：

host 不匹配 → 修改 Ingress host 或请求域名
path 不匹配 → 修改 Ingress path 或请求路径
ingressClassName 错误 → 修改 Ingress 配置

路径五：连接超时

现象：

curl 返回 curl: (28) Connection timed out
无法访问 LoadBalancer IP 或 NodePort

排查步骤：

检查 DNS 解析是否正确
检查 LoadBalancer 是否创建成功
检查云厂商安全组是否放行
检查 Node 防火墙是否放行
检查 LoadBalancer 健康检查是否通过

修复方向：

DNS 错误 → 修改 DNS 记录
LoadBalancer 未创建 → 检查云厂商配额和权限
安全组未放行 → 修改安全组规则
健康检查失败 → 修复 Ingress Controller 或 Node

路径六：证书错误

现象：

curl 返回 SSL certificate problem
浏览器显示证书无效

排查步骤：

检查 Ingress tls 配置
检查 Secret 是否存在且包含正确的证书
检查证书是否过期
检查证书域名是否匹配

修复方向：

Secret 不存在 → 创建 Secret
证书过期 → 更新证书
域名不匹配 → 重新生成证书

风险提醒

删除资源风险

删除 Service：会导致 Ingress 无法转发流量到 Pod，影响所有访问
删除 Endpoints：Endpoints 是自动生成的，不应手动删除
删除 NetworkPolicy：可能导致其他安全策略失效

建议：

删除前确认资源的依赖关系
在测试环境先验证

修改 Ingress 风险

修改 host 或 path：可能导致现有请求匹配失败
修改 backend Service：可能导致流量转发到错误的后端

建议：

修改前备份 Ingress 配置
使用 kubectl apply 而不是 kubectl replace，方便回滚

修改 Service 风险

修改 selector：可能导致 Endpoints 变化，影响流量
修改端口：可能导致 Ingress 无法访问

建议：

修改前确认 Endpoints 变化
在业务低峰期操作

修改 NetworkPolicy 风险

删除 NetworkPolicy：可能导致安全风险
修改规则：可能误拦合法流量

建议：

修改前备份配置
先在测试环境验证

云厂商配置风险

修改 LoadBalancer 监听器：可能导致流量中断
修改安全组：可能误拦或误放流量

建议：

在业务低峰期操作
修改前记录原配置
分批灰度调整

验证方式

验证 Ingress Controller 正常

bash

# 检查 Pod 状态 kubectl get pods -n ingress-nginx # 检查 Service 外部 IP kubectl get svc -n ingress-nginx # 测试健康检查端点 curl http:///healthz

预期结果：

Pod 状态 Running
Service 有 EXTERNAL-IP
健康检查返回 200 OK

验证 Service 和 Endpoints 正常

bash# 检查 Endpoints kubectl get endpoints -n # 检查 Pod Ready 数量 kubectl get pods -n -l

预期结果：

Endpoints 有 Pod IP
Pod 全部 Running 且 Ready

验证网络连通性

bash

# 从 Ingress Controller Pod 访问 Service kubectl exec -it  -n ingress-nginx -- curl http://: # 从 Ingress Controller Pod 访问 Pod IP kubectl exec -it  -n ingress-nginx -- curl http://:

预期结果：

能正常访问 Service 和 Pod

验证外部访问正常

bash

# 测试 HTTP curl http://example.com/api # 测试 HTTPS curl https://example.com/api # 显示响应时间 curl -o /dev/null -s -w "%{http_code} %{time_total}s " http://example.com/api

预期结果：

返回 200 OK
响应时间合理（如 < 1s）

回滚方案

回滚 Ingress 配置

bash

# 查看历史版本 kubectl rollout history ingress  -n  # 回滚到上一版本（注意：Ingress 不支持 rollout，需要手动恢复） kubectl apply -f  # 或者编辑恢复 kubectl edit ingress  -n

回滚 Service 配置

bash# 恢复备份 kubectl apply -f

回滚 NetworkPolicy

bash# 删除新增的 NetworkPolicy kubectl delete networkpolicy -n # 恢复备份 kubectl apply -f

回滚云厂商配置

在云厂商控制台恢复 LoadBalancer、安全组的原配置

生产环境注意事项

操作窗口

修改 Ingress、Service、NetworkPolicy 建议在业务低峰期操作
修改 Ingress Controller 配置需要重启 Pod，会短暂中断流量

备份和记录

修改前备份当前配置：kubectl get ingress -n -o yaml > backup.yaml
记录修改时间、内容、原因
记录验证结果

灰度验证

如果有多个 Ingress Controller，先在一个上验证
使用不同的域名或路径进行灰度测试
观察监控指标，确认无异常后全量推广

监控和告警

修改后持续监控 Ingress Controller 日志、错误率、延迟
设置告警阈值，异常时及时回滚

权限控制

Ingress、Service、NetworkPolicy 的修改需要适当的 RBAC 权限
云厂商操作需要对应的 IAM 权限

影响范围

修改 Ingress 影响该 Ingress 规则匹配的所有请求
修改 Service 影响该 Service 关联的所有 Ingress 和 Pod
修改 NetworkPolicy 影响该策略匹配的所有 Pod

协作沟通

涉及 DNS 修改，需要与 DNS 管理员协作
涉及 LoadBalancer、安全组修改，需要与云厂商或网络团队协作
保持沟通记录，方便后续复盘

总结

Kubernetes Ingress 配置后外部访问不通是运维中常见问题，因为涉及的组件和配置层次多：Ingress Controller、Ingress 规则、Service、Endpoints、Pod、NetworkPolicy、DNS、LoadBalancer、安全组。本文演示了从外到内逐层排查的完整路径。

排查思路可以总结为：

确认 Ingress Controller 状态和日志：Controller Pod 是否 Running，Service 是否暴露，日志有无错误
确认 Ingress 规则配置：语法是否正确，backend Service 是否存在，host 和 path 是否匹配
确认 Service 和 Endpoints：Service 是否存在，Endpoints 是否有 Pod IP
确认 Pod 状态和监听端口：Pod 是否 Running，标签是否匹配，端口是否监听
测试网络连通性：从 Ingress Controller 访问 Service 和 Pod
排查 NetworkPolicy：是否有策略阻止流量
排查 DNS 解析：域名是否解析到正确的 IP
排查 LoadBalancer 和安全组：云厂商配置是否正确

每一步都要结合实际输出、日志、指标进行判断，不能靠猜测。修复方案要根据根因制定，验证要全面，回滚预案要提前准备。生产环境操作要谨慎，做好备份、灰度、监控、沟通。

掌握这套排查方法后，面对 Ingress 访问不通的问题时不再盲目，能快速定位根因，制定有效的修复方案，减少故障时间，提升服务可用性。

打开APP阅读更多精彩内容