Service 与网络排障

Endpoints 缺失

现象: Service 存在但 Endpoints 为空，访问连接失败。

常见原因

• Selector 标签与 Pod 标签不匹配
• 后端 Pod 不处于 Running
• Pod 与 Service 不在同一 Namespace

排障

kubectl get svc <name> -n <ns> -o jsonpath='{.spec.selector}'
kubectl get pods -n <ns> --show-labels | grep <label-key>
kubectl get pods -n <ns> -l "<label-key>=<label-value>"

修复

• 修改 Service Selector 匹配 Pod 标签
• 或修正 Pod 标签
• 或手动创建 Endpoints 资源

DNS 解析异常

现象: Pod 内无法通过 Service 名称访问其他服务。

排障

# 检查 CoreDNS Pod
kubectl get pods -n kube-system -l k8s-app=kube-dns
# 或
kubectl get pods -n kube-system -l app.kubernetes.io/name=coredns

# 查看 CoreDNS 日志
kubectl logs -n kube-system <coredns-pod-name> --tail=50

# 检查 Pod 内 DNS 配置
kubectl exec -it <pod-name> -n <ns> -- cat /etc/resolv.conf
# 正常应类似:
# nameserver 10.96.0.10
# search <ns>.svc.cluster.local svc.cluster.local cluster.local

# 从 DNS Pod 直接测试
kubectl exec -it -n kube-system <coredns-pod-name> -- nslookup kubernetes.default

# 检查 NetworkPolicy
kubectl get networkpolicy -n <ns>

修复

• CoreDNS Pod 异常：重启 kubectl rollout restart deployment/coredns -n kube-system
• DNS Service IP 不对：检查 kubelet --cluster-dns 参数
• NetworkPolicy 阻断：调整规则允许 DNS 流量（端口 53/UDP）

NetworkPolicy 误配置

NetworkPolicy 是白名单机制——未明确允许的流量全部阻断。

# 排查
kubectl get networkpolicy -n <ns>
kubectl describe networkpolicy <name> -n <ns>

# 临时恢复（验证用）
kubectl delete networkpolicy <name> -n <ns>

正确配置示例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: <ns>
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector: {}

Ingress 故障

# 检查 Ingress Controller
kubectl get pods -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx

# 检查 Ingress 资源
kubectl describe ingress <name> -n <ns>

# 检查 Ingress Class
kubectl get ingressclass
kubectl get ingress <name> -n <ns> -o jsonpath='{.spec.ingressClassName}'

# 检查后端 Service/Endpoints
kubectl get svc -n <ns>
kubectl get endpoints <backend-svc> -n <ns>

# 从 Ingress Controller 内测试
kubectl exec -it -n ingress-nginx <controller-pod> -- \
  curl -v http://<svc>.<ns>.svc.cluster.local:<port>

kube-proxy 排查

kube-proxy 运行在每个节点上，监听 Service 和 Endpoints 的变化，动态更新本地的 iptables 或 ipvs 规则。

检查 kube-proxy 是否运行

kubectl get pods -n kube-system -l k8s-app=kube-proxy
kubectl logs -n kube-system -l k8s-app=kube-proxy --tail=50

检查转发模式

kubectl get configmap -n kube-system kube-proxy -o yaml | grep mode
# iptables 模式：默认，稳定但性能稍差
# ipvs 模式：性能更好，需内核模块支持

iptables 模式排查

# SSH 到节点查看 Service 相关规则
ssh <node> "sudo iptables -t nat -L -n | grep <service-name>"
# 输出示例：KUBE-SVC-XXXXXXXX → 对应 Service 链
#          KUBE-SEP-XXXXXXXX → 具体 Endpoint 链

# 查看 FORWARD 链
ssh <node> "sudo iptables -t filter -L FORWARD -n | grep KUBE"

如果没有 KUBE-SVC/KUBE-SEP 规则 → kube-proxy 没有为该 Service 生成规则。

ipvs 模式排查

ssh <node> "sudo ipvsadm -L -n"
# 正常输出：TCP <ServiceIP>:80 rr → <EndpointIP>:8081 Masq 1 0 0
# 检查模块是否加载
ssh <node> "lsmod | grep ip_vs"

ipvsadm 未安装或 ip_vs 模块未加载 → kube-proxy 回退到 iptables。

常见错误日志

kubectl logs -n kube-system -l k8s-app=kube-proxy | grep -i error
# "Failed to sync iptables" — 同步规则失败
# "ipvs struct not found" — ipvs 模式下连接状态异常

CNI 排查

CNI 网络插件选型对比参见 cni-comparison（Flannel vs Calico vs Cilium 完整对比）。

CNI 负责 Pod IP 分配和 Pod 之间的网络连通性。

确认 Pod 网络

# 在 Pod 内测试跨 Pod 连通性
kubectl exec -it <pod-name> -n <namespace> -- ping -c 3 <另一个Pod的IP>
# 查看默认网关
kubectl exec -it <pod-name> -n <namespace> -- ip route

# 确认 CNI 接口存在
ip addr | grep -E "flannel|calico|cni|docker"

Flannel 排查

# 查看 flannel 是否正常
kubectl get pods -n kube-system -l app=flannel

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

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

典型问题：flannel.1 没有 UP → 该节点 CNI 网络未正常初始化。

Calico 排查

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

# 查看 IP 池（需要 calicoctl）
calicoctl get ippool -o wide
calicoctl get workloadendpoints -o wide

跨节点通信故障

同节点 Pod 通信正常，跨节点不通 → 检查源到目标节点路由、CNI 隧道（flannel VXLAN/Calico BGP）、防火墙（flannel UDP 8472/Calico IP-in-IP 4）。

综合案例：Service 有 Endpoint 但返回 502

现象： Service 的 Endpoints 正常，但通过 Ingress 访问返回 502。

排查过程：

1. 确认 Service 和 Endpoint 配置正常 ✅
2. 从 Pod 内直接访问 Service 能正常返回 ✅
3. 通过 Ingress 访问返回 502 ❌
4. Ingress Controller 日志："upstream timed out (110: Connection timed out)"
5. 根因： 应用重试机制导致请求携带无效的 Host 头，Ingress Controller upstream 的 server_name 和请求头中 Host 不匹配

关联页面