排查定位
Service 访问不通时，转发规则是整条链路里最容易被怀疑、也最容易查错的一层。适用平台是 Kubernetes。ClusterIP 的实现由每个节点上的 kube-proxy 负责：iptables 模式下写入大量规则链，IPVS 模式下写入虚拟服务与真实服务器条目，两者都依赖 Endpoints 已有就绪后端。正确顺序是「先确认有没有后端，再看 kube-proxy 组件状态，最后落到 Pod 所在节点核对规则」。
基本信息
| 适用平台 | Kubernetes（节点上的 kube-proxy 组件） |
|---|---|
| 工作模式 | iptables、IPVS，部分环境用 nftables 后端 |
| 依赖对象 | Service 与 EndpointSlice，规则由控制器在这些对象变更时刷新 |
| 检查位置 | 规则与组件都在各节点本地，不在控制面 |
典型使用场景
- 服务整体访问不通：先确认端点列表是否为空，避免在转发层白查
- 只有部分节点不通：说明是节点侧的规则或内核模块问题
- 短连接大量建连失败：怀疑 conntrack 表满或会话复用问题
- 切了 IPVS 模式后异常：核对内核模块与调度算法配置
- 节点维护前预检：确认取消调度后流量路径与端点刷新的表现符合预期
分层检查
分层检查
kubectl get svc web-svc -o wide # 先看 Service 本身的端口与类型
kubectl get endpointslices -l kubernetes.io/service-name=web-svc # 有没有就绪后端
kubectl -n kube-system get pod -l k8s-app=kube-proxy -o wide # 组件在各节点是否就绪
kubectl -n kube-system logs -l k8s-app=kube-proxy --tail=50 # 看同步报错
# 以下在 Pod 所在节点执行
iptables-save | grep -i web-svc # iptables 模式：核对规则条目
ipvsadm -Ln | head -20 # IPVS 模式：虚拟服务与真实服务器
conntrack -C # 会话表条目数，判断是否接近上限分层与结论
| 层 | 检查结果 | 结论方向 |
|---|---|---|
| Endpoints | 为空 | 选择器不匹配或后端未就绪，与转发无关 |
| Endpoints | 有地址但仍不通 | 继续查转发规则与后端监听 |
| kube-proxy | Pod 未就绪或反复重启 | 看日志里的同步失败与内核模块报错 |
| 节点规则 | 无对应条目 | 组件未同步，检查节点网络或组件版本 |
| conntrack | 条目接近上限 | 调大表容量或排查长连接泄漏 |
Endpoints 为空时任何转发规则都不会命中：先把选择器不匹配或后端未就绪这两个最常见原因排除，再看 kube-proxy。
kube-proxy 的规则在每台节点上各自维护，控制面节点查到的结果不代表 Pod 所在节点；确定故障 Pod 在哪台机器上，再登那台机器核对。