K8s服务访问不通的排查方法

马哥Linux运维 2026-05-11 209

描述

K8s 服务访问不通？从 Pod、Service 到 Ingress 一步步查

问题背景

Kubernetes 里服务访问不通是比节点 NotReady 更常见的故障场景。相比节点 NotReady 这种基础设施层的问题，服务访问不通直接表现为业务不可用——用户能打开页面但数据加载不出来，API 请求返回 502 或 504，Pod 之间内部调用超时。这类问题的根因分散在多个层次：Pod 本身没启动、Service 配置错误、Endpoint 没有关联到 Pod、网络策略阻止了流量、Ingress 配置不对、DNS 解析失败等等。

更重要的是，K8s 的网络是虚拟网络，流量路径不直观。外部请求经过 NodePort 或 LoadBalancer 到达某个节点，再由 kube-proxy 转发到后端 Pod；Pod 之间的调用直接通过 Service IP 或 DNS 名称，但实际连接的是 Endpoint IP。路径中间任何一环出问题，都会导致访问不通。

这篇文章面向初中级 Kubernetes 运维和 DevOps 工程师，以一个典型的"服务访问返回 502"故障为线索，从 Pod、Service、Endpoint、kube-proxy、CNI、Ingress 六个层次系统讲解排查方法。每个层次都有对应的检查命令、判断逻辑和修复步骤。涉及的所有命令在 Kubernetes 1.24 及以上版本验证，部分命令更早版本表现可能略有差异，会在文中说明。

适用场景

服务对外提供访问，但返回 502 Bad Gateway 或 504 Gateway Timeout

Pod 之间通过 Service 名称调用，但请求超时或连接拒绝

通过 Ingress 访问服务，但 URL 无法解析或请求路由到错误的后端

NodePort / LoadBalancer 类型的 Service 无法从外部访问

Headless Service 下的 Pod 之间无法通过 DNS 互相发现

某个命名空间内的 Pod 无法访问其他命名空间的服务

特定 IP 段或端口的流量被网络策略阻断

K8s 服务访问路径全解析

在动手排查之前，必须清楚流量从客户端到后端 Pod 的完整路径。不同类型的服务，路径不同。

场景一：集群内部 Pod 访问 Service（最常见）

PodA -> ClusterIP:ServicePort -> kube-proxy (iptables/ipvs) -> EndpointIP:ContainerPort -> PodB

Pod 内运行的进程访问 http://service-name.namespace.svc.cluster.local:port，这个 DNS 名称被 CoreDNS 解析为 Service IP，然后流量被 kube-proxy 拦截并 DNAT 转发到后端某个 Endpoint IP。

场景二：集群外部通过 NodePort 访问

外部客户端 -> NodeIP:NodePort -> kube-proxy -> EndpointIP:ContainerPort -> PodB

外部请求到达任意节点的 NodePort，kube-proxy 将流量转发到后端 Pod。不一定必须是目标 Pod 所在的节点。

场景三：通过 Ingress 访问

外部客户端 -> Ingress Controller Pod -> Ingress 规则匹配 -> Service:NodePort -> kube-proxy -> PodB

流量先打到 Ingress Controller（通常是一个 NodePort 或 LoadBalancer 类型的 Service），Ingress Controller 根据 Host 和 Path 规则找到对应的 Backend Service，然后通过 Service 访问到后端 Pod。

理解了这三条路径，就知道每个环节该查什么。

第一步：确认问题范围和现象

1.1 确认问题是否真实存在

不要假设问题存在，先复现并确认现象：

# 通过 kubectl 确认目标 Service 存在
kubectl get svc -n  

# 确认 Pod 是否存在且 Running
kubectl get pods -n  -l app=

# 如果 Pod 不在 Running 状态，先解决 Pod 问题
# （Pod 都没起来，Service 肯定访问不了）

1.2 从业务角度确认问题现象

# 测试外部能否访问（用 NodePort 或 LoadBalancer IP）
curl -v http://:/

# 典型 502 错误：
# HTTP/1.1 502 Bad Gateway
# Server: nginx/1.24.0
# 502 Bad Gateway

# 典型超时错误：
# curl: (7) Failed to connect to  port : Connection timed out

1.3 确认问题影响范围

# 查看该 Service 有多少个健康的 Endpoint
kubectl get endpoints -n  

# 如果 endpoints 列表为空或数量少于预期，说明 Service 没有关联到健康的 Pod
# 如果 endpoints 数量正常，问题可能在 Ingress 或更上层

# 查看 Pod 分布
kubectl get pods -n  -o wide | grep

第二步：从 Pod 层开始排查

Pod 是流量的最终目的地。如果 Pod 本身不正常，前面查什么都不重要。

2.1 确认 Pod 是否存在且 Running

kubectl get pods -n  -o wide

# 确认所有副本都在 Running
# 如果有非 Running 状态的 Pod：
kubectl get pods -n  --field-selector=status.phase!=Running

2.2 查看 Pod 事件

Pod 创建失败或重启时，Events 是最直接的线索：

kubectl describe pod  -n 

# 重点看最后 20 行 Events
kubectl describe pod  -n  | tail -20

# 常见的问题线索：
# - ImagePullBackOff: 镜像拉取失败，检查镜像名称、tag、私有仓库认证
# - CrashLoopBackOff: 容器启动后立即退出，检查应用启动命令和健康检查
# - CreateContainerConfigError: 配置错误，检查 ConfigMap/Secret 挂载
# - OOMKilled: 内存不足被杀，检查资源限制和实际使用
# - Evicted: 被驱逐，检查节点资源压力

2.3 查看容器内部日志

# 查看当前日志（stdout）
kubectl logs  -n 

# 如果容器重启过，查看上次运行的日志（用于排查启动后立即崩溃的问题）
kubectl logs  -n  --previous

# 如果是多容器 Pod，指定容器名
kubectl logs  -n  -c 

# 实时查看日志
kubectl logs -f  -n  --tail=100

2.4 登录 Pod 内部排查

如果日志没有明显线索，可以进 Pod 内部测试网络连通性：

# 进容器（需要容器内有 bash）
kubectl exec -it  -n  -- /bin/bash

# 如果容器没有 bash，用 sh
kubectl exec -it  -n  -- /bin/sh

# 确认容器进程是否监听在预期端口
# Java 应用：ps aux | grep java
# Nginx / Python / Node.js：netstat -tlnp 或 ss -tlnp
# 注意：很多精简镜像没有这些命令，可以临时安装或用其他方式验证

# 测试 localhost 端口是否监听
wget -qO- http://127.0.0.1:/healthz
# 或
curl -s http://127.0.0.1:/healthz

# 如果 localhost 访问正常，但通过 Service 访问有问题，说明问题在 Service 层

2.5 检查 Pod 资源限制

资源限制设置不当会导致 Pod 被 OOMKill 或被 throttle，导致请求超时：

# 查看 Pod 的资源请求和限制
kubectl get pod  -n  -o jsonpath='{.spec.containers[*].resources}'

# 查看 Pod 实际资源使用（需要 metrics-server）
kubectl top pod  -n 

# 如果资源使用接近限制，说明需要调高限制或优化应用内存使用

第三步：排查 Service 层

确认 Pod 正常后，转到 Service 层。Service 是 Pod 的访问入口，也是最容易配置出错的地方。

3.1 确认 Service 配置正确

# 查看 Service 完整配置
kubectl get svc  -n  -o yaml

# 重点检查以下字段：
# spec.selector: 是否正确关联到目标 Pod 的 label
# spec.ports: 端口号、目标端口、协议是否正确
# spec.type: ClusterIP / NodePort / LoadBalancer

常见配置错误一：selector 写错

# 错误示例：selector 写成了 app: web-frontend，但 Pod 的 label 是 app: web
spec:
  selector:
    app: web-frontend  # 这个 selector 找不到任何 Pod

正确做法：

# 确认 Pod 实际的 label
kubectl get pods -n  --show-labels

# 查看 Service 的 selector 是否能匹配到 Pod
kubectl get pods -n  -l app=web-frontend
# 如果没有输出，说明 selector 写错了

常见配置错误二：端口配置错误

# 错误示例：targetPort 写成了字符串，但容器实际监听的端口是数字
spec:
  ports:
  - port: 80
    targetPort: "http"   # 容器没有 named port "http"，应该写 8080
    protocol: TCP

3.2 确认 Endpoints 存在且健康

Service 通过 Endpoints 关联到 Pod。如果 Endpoints 为空，说明 Service 找不到健康的后端：

# 查看 Endpoints
kubectl get endpoints  -n 

# 正常输出：
# NAME               ENDPOINTS
# my-service         10.244.1.15:8080,10.244.2.23:8080
# 如果为空：

# 查看 Endpoints 详细信息（关联了哪些 Pod IP 和端口）
kubectl describe endpoints  -n

Endpoints 为空的排查方法：

Endpoints 为空通常有两个原因：selector 匹配不到 Pod，或者匹配的 Pod 没有 ready（readinessProbe 失败）。

# 1. 确认 selector 是否匹配到 Pod
kubectl get pods -n  --show-labels
# 手动验证：Service selector 的每个 key-value 是否都能在 Pod label 中找到

# 2. 确认 Pod 的 Ready 状态
kubectl get pods -n  -o wide
# 关注 Ready 列：应该是 1/1、2/2 等，如果不是，说明 readinessProbe 有问题

# 3. 查看 Pod 的 readinessProbe 配置
kubectl get pod  -n  -o jsonpath='{.spec.containers[*].readinessProbe}'

readinessProbe 配置错误的常见场景：

# 错误示例：readinessProbe HTTP 路径返回 404，但应用实际路径是 /api/health
readinessProbe:
  httpGet:
    path: /healthz  # 应用没有 /healthz 端点
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

3.3 测试从集群内部访问 Service

从 Pod 内部访问 Service 是最基础的测试。如果这一步失败，说明 kube-proxy 或 CoreDNS 有问题：

# 创建一个临时测试 Pod
kubectl run -n  testpod --image=busybox:1.36 --restart=Never -it --rm -- sh

# 在 Pod 内部执行以下测试：

# 1. DNS 解析测试
nslookup 
# 正常输出：
# Name:      
# Address:   

# 如果 nslookup 失败（DNS 问题）
nslookup kubernetes.default
# 如果连 kubernetes 都解析不了，说明 CoreDNS 有问题

# 2. 通过 Service IP 访问
wget -qO- http://:/healthz

# 3. 通过 DNS 名称访问
wget -qO- http://..svc.cluster.local:/healthz

# 4. 测试不同端口（有些服务可能有多个端口）
wget -qO- http://..svc.cluster.local:/

# 如果 DNS 名称能解析但连接超时：
# 说明 kube-proxy 没有正确转发流量，检查 kube-proxy

# 如果 Connection refused：
# 说明容器内端口没监听或 Service targetPort 配置错误

3.4 测试 NodePort 类型 Service

如果 Service 是 NodePort 类型，在所有节点的 NodePort 上都应该能访问：

# 查看 NodePort
kubectl get svc  -n  | grep NodePort

# 输出示例：
#    NodePort: http  30080/TCP
# NodePort 是 30080，在所有节点上都能通过 <任意节点IP>:30080 访问

# 从集群外部测试（如果有 firewall 规则，需要先确认 NodePort 已放行）
curl -v http://<任意节点IP>:30080/

# 如果某个节点能访问、另一个不能：
# 检查不能访问的节点上 kube-proxy 是否正常
ssh <目标节点> "systemctl status kube-proxy"

第四步：排查 kube-proxy 层

kube-proxy 是 Service 流量的转发引擎。它运行在每个节点上，监听 Service 和 Endpoints 的变化，动态更新本地的 iptables 或 ipvs 规则。如果 kube-proxy 异常，Service 流量转发就会失败。

4.1 检查 kube-proxy 是否运行

# kube-proxy 以 DaemonSet 形式运行
kubectl get pods -n kube-system -l k8s-app=kube-proxy

# 查看 kube-proxy 日志
kubectl logs -n kube-system -l k8s-app=kube-proxy --tail=50

# 如果 kube-proxy Pod 不在 Running，检查详情
kubectl describe pod -n kube-system -l k8s-app=kube-proxy

4.2 检查 kube-proxy 的转发模式

kube-proxy 支持 iptables 和 ipvs 两种模式，默认是 iptables。两种模式的排查方法不同：

# 查看 kube-proxy 的启动参数，确认使用的是 iptables 还是 ipvs
kubectl get configmap -n kube-system kube-proxy -o yaml | grep mode

# 或者在节点上查看
ssh  "grep mode /var/lib/kubelet/config.yaml"

# iptables 模式：默认，性能稍差，但稳定
# ipvs 模式：性能更好，但配置复杂，某些内核版本支持不好

4.3 iptables 模式排查

# SSH 到某个节点上查看 iptables 规则

# 1. 查看 NAT 表中关于某个 Service 的规则
# 注意：规则很多，直接 grep
ssh  "sudo iptables -t nat -L -n | grep "

# 输出示例：
# KUBE-SVC-XXXXXXXX  tcp  --  anywhere  10.109.12.34  tcp dpt:80
# KUBE-SEP-XXXXXXXX  tcp  --  anywhere  anywhere  statistic mode: probability mode: random 0.500000000
# KUBE-SEP-XXXXXXXX  tcp  --  anywhere  10.244.1.15  tcp dpt:8080

# KUBE-SVC-XXXXXXXX 是 Service 对应的链
# KUBE-SEP-XXXXXXXX 是具体 Endpoint 的链
# 如果没有这些规则，说明 kube-proxy 没有为这个 Service 生成规则

# 2. 查看 KUBE-SERVICES 链中是否有该 Service
ssh  "sudo iptables -t nat -L KUBE-SERVICES -n | grep "

# 3. 查看 FILTER 表的 FORWARD 链
ssh  "sudo iptables -t filter -L FORWARD -n | grep KUBE"

# 如果 FORWARD 链没有 ACCEPT KUBE 相关的规则，可能 kube-proxy 没有正确处理流量

4.4 ipvs 模式排查

# SSH 到节点上查看 ipvs 规则
ssh  "sudo ipvsadm -L -n"

# 正常输出：
# IP Virtual Server version 1.2.1 (size=4096)
# TCP  :80 rr
#   -> :8081          Masq    1      0          0
#   -> :8082          Masq    1      0          0

# 如果 ipvsadm 没有安装或 ipvs 模块未加载，kube-proxy 会回退到 iptables
# 检查 ipvs 模块是否加载
ssh  "lsmod | grep ip_vs"

4.5 kube-proxy 日志分析

# 查看 kube-proxy 是否有报错
kubectl logs -n kube-system -l k8s-app=kube-proxy | grep -i error

# 常见错误：
# "Failed to delete service" - 删除 Service 时清理规则失败
# "Failed to sync iptables" - 同步规则失败，可能是权限问题
# "ipvs struct not found" - ipvs 模式下某些连接状态异常

第五步：排查网络插件层（CNI）

如果 Service 层和 kube-proxy 都正常，但 Pod 之间还是不通，问题可能在 CNI（容器网络接口）层。CNI 负责 Pod IP 分配和 Pod 之间的网络连通性。

5.1 确认 Pod 网络是否正常

# 在有问题的 Pod 内测试
kubectl exec -it  -n  -- /bin/sh

# 测试到另一个 Pod 的连通性（通过 Pod IP，不是 Service IP）
ping -c 3 <另一个Pod的IP>

# 测试到网关的连通性
ip route
# 默认网关应该是 CNI 网桥或 flannel.1 / calico* 等接口

# 如果 ping 不通：
# 1. 确认两边的 Pod 是否在同一个网段
# 2. 确认 CNI 插件创建的接口是否存在
ip addr | grep -E "flannel|calico|cni|docker"

5.2 常见 CNI 插件排查

Flannel 排查：

# 查看 flannel 是否为所有节点创建了网络
kubectl get pods -n kube-system -l app=flannel

# 在节点上查看 flannel.1 接口
ip addr show flannel.1

# 查看 flannel 的网络范围（Pod CIDR）
kubectl get cm -n kube-system kube-flannel-cfg -o yaml | grep -A 3 "net-conf.json"

# 典型问题：节点 Pod CIDR 没有被 flannel 分配
# 在节点上查看：
ip addr show flannel.1
# 如果 flannel.1 没有 UP，说明该节点的 CNI 网络没有正常初始化

Calico 排查：

# 查看 calico-node 是否 Running
kubectl get pods -n kube-system -l k8s-app=calico-node

# 查看 calico-node 日志
kubectl logs -n kube-system -l k8s-app=calico-node --tail=100

# 查看 BGP 对等连接（需要 calicoctl）
calicoctl node status

# 查看 IP 池
calicoctl get ippool -o wide

# 典型问题：节点没有分配到 IP 池地址
# 查看节点 IP 分配情况
calicoctl get workloadendpoints -o wide

5.3 跨节点 Pod 通信测试

# 获取两个不同节点上 Pod 的 IP
kubectl get pods -o wide --all-namespaces | grep Running

# 在源 Pod 内测试到目标 Pod IP 的连通性
kubectl exec -it <源Pod> -n  -- ping -c 5 <目标PodIP>

# 如果同节点 Pod 通信正常，跨节点不通：
# 1. 检查源节点到目标节点的路由（VPC 或物理网络层）
# 2. 检查 CNI 的跨节点隧道是否正常（flannel 用 VXLAN，calico 可以用 BGP 或 VXLAN）
# 3. 检查是否有防火墙规则阻止了 CNI 隧道端口（flannel UDP 8472，Calico IP-in-IP 4）

# 测试特定端口（如果 ping 通了但服务访问不通，可能是防火墙或端口问题）
kubectl exec -it <源Pod> -n  -- nc -zv <目标PodIP> <端口>

第六步：排查 Ingress 层

如果 Service 本身正常，但通过 Ingress 访问不通，问题就在 Ingress 层。Ingress 是外部流量的入口，也是配置最复杂的一层。

6.1 确认 Ingress Controller 正常运行

# Ingress Controller 通常部署在 kube-system 命名空间
kubectl get pods -n kube-system | grep -E "ingress|nginx"

# 常见 Ingress Controller：
# nginx-ingress-controller（社区版或 Nginx Inc 版）
# ingress-nginx（Kubernetes 官方维护的 nginx-ingress）
# traefik

# 如果 Ingress Controller 没有 Running：
kubectl describe pod -n kube-system 

# 如果 Ingress Controller Pod 重启频繁：
kubectl logs -n kube-system  --previous | tail -50

6.2 查看 Ingress 规则配置

# 查看所有 Ingress 资源
kubectl get ingress -A

# 查看具体 Ingress 的配置
kubectl get ingress  -n  -o yaml

# 重点检查：
# spec.rules: Host 和 Path 配置
# spec.tls: HTTPS 证书配置
# spec.backend: 默认后端（如果没有匹配规则时使用）

6.3 确认 Ingress 和 Service 的关联

# Ingress 的 backend.service.name 必须和目标 Service 名称一致
kubectl get ingress  -n  -o jsonpath='{.spec.rules[*].http.paths[*].backend.service}'

# 确认 Ingress backend 的 port 端口和 Service port 一致
kubectl get ingress  -n  -o jsonpath='{.spec.rules[*].http.paths[*].backend.service.port}'

6.4 Ingress 日志分析

# 查看 Ingress Controller 日志
kubectl logs -n kube-system  -f --tail=100

# 搜索访问日志
# nginx-ingress-controller 日志格式：
#  -  [] "  "   "" ""

# 搜索 502 / 503 / 504 错误
kubectl logs -n kube-system  | grep " 502 | 503 | 504 "

# 搜索特定 Host 的访问
kubectl logs -n kube-system  | grep "Host: "

# 如果没有日志输出，说明请求根本没到 Ingress Controller
# 检查 DNS 解析、LB 配置、NodePort 是否正确

6.5 逐层排查 Ingress 流量路径

如果确认 Ingress 也有问题，按以下路径逐层排查：

1. 外部 -> DNS 解析 -> Ingress Controller 的外部 IP/NodePort
2. Ingress Controller -> Ingress 规则匹配 -> Backend Service
3. Backend Service -> kube-proxy -> Endpoint -> Pod

层级一：确认外部能访问到 Ingress Controller

# 获取 Ingress Controller 的 NodePort 或 LoadBalancer IP
kubectl get svc -n kube-system | grep -E "ingress|nginx"

# 测试从外部直接访问 NodePort（绕过 DNS）
curl -v http://<任意节点IP>:/

# 如果 NodePort 能访问，但域名访问不行：
# 说明 DNS 解析有问题，域名没有解析到正确的 IP

层级二：确认 Ingress 规则被正确加载

# 查看 Ingress Controller 进程的配置（nginx.conf）
kubectl exec -n kube-system  -- cat /etc/nginx/nginx.conf

# 搜索对应的 server {} 块
kubectl exec -n kube-system  -- grep -A 20 "server_name "

# 确认 upstream {} 块中的 server 列表是否包含正确的 Endpoint IP
kubectl exec -n kube-system  -- grep -A 10 "upstream "

6.6 TLS/HTTPS 相关问题

# 查看 Ingress 的 TLS 配置
kubectl get ingress  -n  -o yaml | grep -A 10 tls

# 常见 TLS 问题：
# 1. Secret 不存在
kubectl get secret  -n 
# 2. Secret 类型不是 kubernetes.io/tls
# 3. 证书过期（Let's Encrypt 证书有效期 90 天）
# 4. 证书和域名不匹配

# 测试 HTTPS 访问
curl -v https:/// --insecure

# --insecure 参数跳过证书验证，用于排查是证书问题还是连接问题
# 如果加 --insecure 能通，说明是证书配置问题

第七步：排查 DNS 解析问题

DNS 问题是导致"服务访问不通"的重灾区。Pod 访问 Service 通过 DNS 名称，如果 DNS 解析失败或缓慢，所有依赖 Service 名称的调用都会失败。

7.1 测试 DNS 解析

# 在 Pod 内测试 DNS
kubectl exec -it  -n  -- nslookup kubernetes.default
kubectl exec -it  -n  -- nslookup ..svc.cluster.local

# 如果 nslookup 不存在，用 dig
kubectl exec -it  -n  -- apt-get update && apt-get install -y dnsutils
kubectl exec -it  -n  -- dig +short kubernetes.default.svc.cluster.local

# 测试完整 DNS 名称
kubectl exec -it  -n  -- getent hosts ..svc.cluster.local

7.2 查看 CoreDNS 状态

# CoreDNS 通常以 Deployment 形式运行在 kube-system
kubectl get pods -n kube-system -l k8s-app=kube-dns

# 查看 CoreDNS 日志
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100

# 查看 CoreDNS 配置
kubectl get configmap -n kube-system coredns -o yaml

7.3 DNS 解析慢的常见原因

DNS 解析本身不应该很慢，但如果 Pod 数量很大或 DNS 查询量很高，可能出现延迟。常见原因：

DNS 查询并发限制：Linux 内核对每个进程/容器的 DNS 并发查询有限制

ndots 配置过高：K8s 默认 ndots=5，意味着任何带 5 个以下点的名称都会先查集群 DNS 再查外部 DNS，导致所有外部 DNS 查询都走集群 DNS

优化 ndots 配置（在 Pod 的 dnsPolicy 不为 Default 时生效）：

# 在 Pod spec 中添加 dnsConfig
spec:
  dnsConfig:
    options:
    - name: ndots
      value: "2"  # 默认 5，改成 2 减少集群 DNS 查询
    - name: timeout
      value: "2"
    - name: attempts
      value: "2"

第八步：排查网络策略（NetworkPolicy）

如果以上所有层都正常，但流量就是不通，可能是 NetworkPolicy 阻止了流量。

8.1 查看命名空间的 NetworkPolicy

# 查看该命名空间是否应用了 NetworkPolicy
kubectl get networkpolicy -n 

# 查看具体的 NetworkPolicy 规则
kubectl get networkpolicy  -n  -o yaml

8.2 常见 NetworkPolicy 配置错误

# 错误示例：只允许特定标签的 Pod 访问
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: nginx  # 只有带 nginx 标签的 Pod 能访问
# 但实际请求来自其他标签的 Pod，所以被阻止

临时测试：放行所有流量排查是否是 NetworkPolicy 问题

# 如果确认是 NetworkPolicy 问题，需要临时放行，可以先删除 Policy
kubectl delete networkpolicy  -n 

# 或者临时添加一条允许所有流量的 Policy
kubectl apply -f - <<'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: 
spec:
  podSelector: {}
  ingress:
  - {}
EOF

第九步：综合故障案例

案例一：Service 有 Endpoint 但返回 502

现象：Service 的 Endpoints 列表正常（有 IP 有端口），但通过 Ingress 访问返回 502。

排查过程：

# 1. 确认 Service 和 Endpoint 配置
kubectl get svc my-service -n default
kubectl get endpoints my-service -n default
# 输出正常，Endpoint 数量和 Pod 数量一致

# 2. 从 Pod 内直接访问 Service（绕过 Ingress）
kubectl run -n default curl-test --image=curlimages/curl --restart=Never -it --rm -- sh
# curl http://my-service.default.svc.cluster.local:8080/api/health
# 能正常返回

# 3. 通过 Ingress 访问返回 502
curl http:///api/health
# 返回 502

# 4. 查看 Ingress Controller 日志
kubectl logs -n kube-system nginx-ingress-controller-xxx | grep "/api/health"
# 日志显示："upstream timed out (110: Connection timed out)"

# 5. 确认问题：Ingress Controller 无法连接到后端 Service
# 检查 Ingress Controller 和后端是否在同一个网络
# 发现：Ingress Controller 在 kube-system 命名空间，应用在 default 命名空间
# 但 NetworkPolicy 默认允许同集群内通信，所以不是这个原因

# 6. 实际根因：应用的重试机制导致请求携带无效的 "Host" 头
# Ingress Controller 的 upstream 配置中 server_name 和请求头中的 Host 不匹配
# 修复：调整 Ingress 的 host 字段或者应用的 Host 头

修复方案：

# 在 Ingress 中明确指定 backend 的 serviceName 和 servicePort
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 8080

案例二：Pod 之间通过 Headless Service 无法互相发现

现象：部署了有状态应用（MySQL 主从），使用 Headless Service，但 Pod 之间无法通过 DNS 互相发现。

排查过程：

# 1. 确认 Headless Service 配置
kubectl get svc mysql-headless -n database -o yaml

# 关键字段：
# clusterIP: None  <-- 这个 None 是 Headless Service 的标志
# spec:
#   selector:
#     app: mysql

# 2. 确认 Pod 的 DNS 记录
kubectl exec -it mysql-0 -n database -- nslookup mysql-headless.database.svc.cluster.local
# 正常情况下应该返回所有匹配的 Pod IP

# 3. 如果 DNS 记录为空，检查：
# - selector 是否能匹配到 Pod label
kubectl get pods -n database -l app=mysql --show-labels

# - StatefulSet 的 serviceName 是否和 Headless Service 名称一致
kubectl get statefulset mysql -n database -o jsonpath='{.spec.serviceName}'

根因：StatefulSet 的 serviceName 必须和 Headless Service 名称完全一致，否则 Pod 的 DNS 记录不会生成。

第十步：预防措施

10.1 建立服务可达性巡检

#!/bin/bash
# save as: k8s_service_health_check.sh
# 建议配合 Prometheus 告警使用，这里提供命令行巡检方式

NAMESPACES=$(kubectl get ns -o jsonpath='{.items[*].metadata.name}' | tr ' ' '
' | grep -v kube-system)

for NS in $NAMSPACES; do
  # 找出所有非 Headless 的 ClusterIP Service
  SERVICES=$(kubectl get svc -n $NS -o json | jq -r '.items[] | select(.spec.clusterIP != "None") | select(.spec.clusterIP != "") | .metadata.name')

  for SVC in $SERVICES; do
    ENDPOINTS=$(kubectl get endpoints $SVC -n $NS -o json | jq '.subsets | length')
    if [ "$ENDPOINTS" == "0" ] || [ "$ENDPOINTS" == "null" ]; then
      echo "[ALERT] Service $SVC in namespace $NS has NO endpoints"
    fi
  done
done

echo "巡检完成"

10.2 Ingress 和 Service 关联性校验

每次部署新服务时，用以下命令校验 Ingress 和 Service 的关联是否正确：

#!/bin/bash
# 检查所有 Ingress 资源对应的 Service 是否存在且有 Endpoints

for INGRESS in $(kubectl get ingress -A -o jsonpath='{.items[*].metadata.name}'); do
  NS=$(kubectl get ingress $INGRESS -A -o jsonpath='{.items[0].metadata.namespace}')
  SVC=$(kubectl get ingress $INGRESS -n $NS -o jsonpath='{.spec.rules[0].http.paths[0].backend.service.name}')
  PORT=$(kubectl get ingress $INGRESS -n $NS -o jsonpath='{.spec.rules[0].http.paths[0].backend.service.port.number}')

  echo "Ingress: $INGRESS, Service: $SVC, Port: $PORT"

  EP_COUNT=$(kubectl get endpoints $SVC -n $NS -o json 2>/dev/null | jq '.subsets | map(.addresses) | flatten | length')
  if [ "$EP_COUNT" == "0" ] || [ "$EP_COUNT" == "null" ]; then
    echo "  [WARNING] Service $SVC has no endpoints!"
  fi
done

10.3 Pod readinessProbe 配置规范

# 标准 Spring Boot 应用的 readinessProbe 配置
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  initialDelaySeconds: 30   # 等待应用启动
  periodSeconds: 10         # 每 10 秒检查一次
  timeoutSeconds: 5         # 超时 5 秒算失败
  successThreshold: 1        # 成功 1 次即 Ready
  failureThreshold: 3        # 连续失败 3 次才标记 NotReady

# 标准 Golang 应用的 readinessProbe 配置
readinessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

总结

K8s 服务访问不通的问题，排查核心在于分层定位、逐层排除。推荐按以下优先级排查：

第一优先级（5 分钟内定位）：

Pod 是否 Running、Ready、日志是否正常

Service 的 Endpoints 是否有关联的 Pod IP

从 Pod 内直接访问 Service IP（绕过 Ingress 和 NodePort）

第二优先级（5-15 分钟）：

kube-proxy 的 iptables/ipvs 规则是否正确生成

CNI 插件是否正常（flannel.1 / calico* 接口是否存在）

Ingress Controller 是否 Running、日志是否有 502/503 错误

第三优先级（15 分钟以上）：

DNS 解析是否正常（CoreDNS 日志、ndots 配置）

NetworkPolicy 是否阻止了合法流量

跨节点网络路由是否正确（VPC/物理网络层）

关键原则：

始终从 Pod 层开始，往上排查。Pod 正常是 Service 正常的前提

用 kubectl get endpoints 判断 Service 是否有关联的 Pod，是最快速的诊断方法

Ingress 访问问题，80% 是 Ingress 和 Service 关联配置错误，20% 是 Ingress Controller 自身问题

NetworkPolicy 问题隐蔽性最强，排查到最后才考虑

记住一个排查顺序口诀：先 Pod 再 Svc，EP 不为空则网络通；Ingress 有问题先看日志，DNS 不通查 CoreDNS。

打开APP阅读更多精彩内容