Kubernetes网络故障排查实战Service不通的6种场景与诊断指南当你深夜收到告警发现Kubernetes集群中的某个Service突然无法访问时那种头皮发麻的感觉想必每个运维都深有体会。Service作为Kubernetes的核心抽象层其背后涉及Pod网络、kube-proxy、CoreDNS等多个组件的协同工作任何环节出现问题都可能导致服务中断。本文将带你深入故障现场用6个真实案例还原Service访问失败的典型场景并提供一套可复用的诊断工具箱。1. 基础检查从Endpoints开始在开始复杂的网络抓包之前聪明的工程师总会先确认最基础的要素这个Service是否有健康的Pod在提供服务执行以下命令快速验证kubectl get endpoints service-name -n namespace健康的Endpoints应该显示类似这样的输出NAME ENDPOINTS AGE my-service 10.244.1.5:8080,10.244.2.3:8080 2d如果ENDPOINTS列为none说明根本没有任何Pod在接收流量。这时候你需要检查标签选择器是否匹配比较Service的selector和Pod的labelsPod是否Readykubectl get pods -l selector -o wide容器端口定义确认Pod的containerPort与Service的targetPort对应常见踩坑点当使用数字作为targetPort时容易与containerPort混淆。最佳实践是始终使用命名端口# Service定义示例 ports: - name: http port: 80 targetPort: web-server2. kube-proxy的沉默罢工Endpoints正常但Service仍然不通是时候检查集群的交通警察——kube-proxy了。不同运行模式下的诊断方法有所差异模式检查方法典型问题iptablessudo iptables-savegrep ipvssudo ipvsadm -ln虚拟服务未正确配置userspacenetstat -tulnpgrep kube-proxy查看kube-proxy日志时要特别关注以下错误模式# 查看kube-proxy日志 kubectl logs -n kube-system kube-proxy-pod --tail100 # 典型错误示例 E0305 14:22:41.123456 11235 proxier.go:900] Failed to execute iptables-restore: exit status 1 W0305 14:22:42.654321 11235 proxier.go:1203] Cant set sysctl net/ipv4/vs/expire_nodest_conn: permission denied实战技巧在节点上直接测试Service IP是否可达# 在节点上测试ClusterIP curl -v cluster-ip:port telnet cluster-ip port3. 被忽视的NetworkPolicy随着安全要求的提高NetworkPolicy已成为许多集群的标准配置但它也可能成为Service访问的隐形杀手。检查是否存在影响通信的网络策略kubectl get networkpolicy -n namespace --show-labels一个典型的阻断流量的NetworkPolicy可能长这样apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-ingress spec: podSelector: {} policyTypes: - Ingress诊断锦囊临时创建允许所有流量的策略进行测试kubectl apply -f - EOF apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-temporarily spec: podSelector: {} ingress: - {} policyTypes: - Ingress EOF4. CoreDNS的解析谜题当通过Service名称访问失败但直接使用ClusterIP可以时问题很可能出在DNS解析环节。以下是系统的诊断步骤验证CoreDNS Pod状态kubectl get pods -n kube-system -l k8s-appkube-dns检查解析配置kubectl exec -it test-pod -- cat /etc/resolv.conf正常输出应包含集群DNS IPnameserver 10.96.0.10 search default.svc.cluster.local svc.cluster.local cluster.local执行nslookup测试kubectl exec -it test-pod -- nslookup service-name高级技巧当怀疑是DNS缓存问题时可以查询CoreDNS的缓存命中率kubectl exec -n kube-system coredns-pod -- curl -s localhost:9153/metrics | grep coredns_cache_5. 节点网络层的交通堵塞当问题只出现在特定节点时需要深入网络插件层进行排查。不同CNI插件的检查方法Flannel网络检查# 检查flannel接口 ip addr show flannel.1 # 验证VXLAN隧道 bridge fdb show dev flannel.1Calico网络检查# 查看BGP邻居状态 calicoctl get nodes calicoctl node status # 检查路由表 ip route | grep cali通用网络检查# 检查节点防火墙规则 sudo iptables -L -n -v | grep DROP # 测试基础网络连通性 ping target-pod-ip traceroute target-pod-ip6. 那些意想不到的高级故障有些Service不通的问题隐藏得更深需要特殊的诊断技巧案例1IPVS模式下的端口冲突# 检查冲突端口 netstat -tulnp | grep port sudo ss -tulnp | grep port案例2Pod的TCP连接队列满# 检查队列溢出统计 netstat -s | grep overflowed案例3节点conntrack表满# 查看conntrack计数 cat /proc/sys/net/netfilter/nf_conntrack_count # 检查最大值 cat /proc/sys/net/netfilter/nf_conntrack_max案例4MTU不匹配导致大包丢弃# 检查MTU设置 ip link show # 测试MTU问题 ping -s 1472 -M do target-ip # 1472281500终极武器诊断流程图与命令集将上述所有检查点整合为可复用的诊断流程图基础验证[ ] Endpoints是否正常[ ] Pod是否Ready[ ] 端口映射是否正确网络层检查[ ] ClusterIP是否可达[ ] NodePort是否响应[ ] 跨节点Pod是否互通组件诊断[ ] kube-proxy日志有无异常[ ] CoreDNS解析是否正常[ ] NetworkPolicy是否阻断高级排查[ ] CNI插件是否健康[ ] 节点防火墙是否放行[ ] 系统资源是否充足完整命令集# 网络诊断全能工具箱 alias kubenet-diagkubectl get endpoints,services,pods -o wide; kubectl get networkpolicy; kubectl logs -n kube-system -l k8s-appkube-proxy; kubectl exec -it test-pod -- nslookup kubernetes.default记住好的系统工程师不仅要会解决问题更要建立预防机制。建议定期运行网络健康检查# 定期网络检查脚本 kubectl run net-checker --imagealpine --restartNever --rm -it -- sh -c ping -c 3 service-ip nc -zv service-ip port nslookup service-name