分享
获课:999it.top/15550/
Kubernetes 网络训练营(第2期):常见网络故障定位与排错方法论
在云原生时代,Kubernetes 已成为容器编排的事实标准。然而,随着集群规模的扩大和业务复杂度的提升,网络问题逐渐成为运维人员面临的最大挑战之一。Kubernetes 网络模型虽然抽象统一,但其底层实现涉及众多组件(如 CNI 插件、kube-proxy、CoreDNS、iptables/IPVS、Service、Ingress 等),一旦出现异常,往往牵一发而动全身。本文将从多个维度出发,系统性地梳理 Kubernetes 常见网络故障的定位思路与排错方法论,帮助运维和开发人员快速识别并解决网络问题。
一、理解 Kubernetes 网络模型是排错的前提
在排查任何网络问题前,必须对 Kubernetes 的基本网络模型有清晰认知:
Pod 间通信:所有 Pod 之间应能通过 IP 直接通信,无需 NAT。
Service 抽象:提供稳定的虚拟 IP(ClusterIP)或外部访问入口(NodePort/LoadBalancer)。
DNS 解析:通过 CoreDNS 实现服务发现,Pod 可通过 <service>.<namespace>.svc.cluster.local 访问其他服务。
网络策略(NetworkPolicy):可选的流量控制机制,用于限制 Pod 之间的通信。
只有明确这些核心概念及其依赖关系,才能在故障发生时快速判断问题可能出现在哪一层。
##二、建立分层排查思维模型
Kubernetes 网络故障通常可以按照"自底向上"或"端到端"的方式进行分层排查。推荐采用以下五层模型:
1. 基础设施层(Underlay Network)
检查节点之间的物理或虚拟网络是否连通,包括:
节点间路由是否可达
防火墙规则是否放行所需端口(如 4789 for VXLAN)
MTU 设置是否一致
是否存在丢包或高延迟
若节点间基础网络不通,上层所有通信都将失败。
2. CNI 与 Pod 网络层
确认 CNI 插件是否正常工作:
Pod 是否成功分配 IP
容器网络命名空间中的路由表是否正确
CNI 插件日志是否有错误(如 Calico、Flannel、Cilium 等)
Overlay 网络(如 VXLAN、Geneve)隧道是否建立
此层问题常表现为 Pod 无法启动、IP 冲突或跨节点 Pod 无法通信。
3. Service 与 kube-proxy 层
验证 Service 和负载均衡机制是否生效:
Service 的 Endpoints 是否包含健康的 Pod
kube-proxy 是否正常同步 iptables 规则或维护 IPVS 表
ClusterIP 是否在节点上可访问
NodePort 是否监听在正确端口
典型症状包括:能 ping 通 Pod IP,但无法通过 Service 访问;或访问 Service 时连接超时。
4. DNS 与服务发现层
排查域名解析是否正常:
CoreDNS Pod 是否运行正常
Pod 的 /etc/resolv.conf 配置是否指向正确的 nameserver
是否能解析内部服务域名(如 my-svc.default.svc.cluster.local)
是否存在 DNS 缓存或解析超时
该层问题常被误判为"服务不可用",实则是域名无法解析。
5. 应用与策略层
最后检查应用自身及网络策略:
应用是否监听在 0.0.0.0 而非 127.0.0.1
容器端口是否正确暴露
NetworkPolicy 是否意外阻止了合法流量
Ingress 控制器配置是否正确(如 TLS、路径匹配)
许多"网络不通"的案例,最终根源在于应用未正确绑定端口或策略配置错误。
三、构建标准化排错流程
面对网络故障,建议遵循以下标准化流程:
步骤 1:明确故障现象
是全部服务不可达,还是特定服务?
是 Pod 间通信失败,还是外部无法访问集群?
是间歇性故障,还是持续性中断?
精准描述问题是高效排错的第一步。
步骤 2:缩小故障范围
在相同节点 vs 不同节点的 Pod 间测试连通性
直接访问 Pod IP vs 通过 Service 访问
使用 nslookup 或 dig 测试 DNS 解析
从集群内 vs 集群外发起请求
通过对比测试,可快速锁定问题层级。
步骤 3:检查关键组件状态
kubectl get nodes:确认节点 Ready
kubectl get pods -n kube-system:查看 CNI、CoreDNS、kube-proxy 状态
kubectl describe service <svc>:检查 Endpoints 是否为空
查看相关组件日志(如 kubectl logs -n kube-system coredns-xxx)
步骤 4:使用诊断工具辅助
虽然本文不涉及代码,但应熟悉常用工具的作用:
ping / curl / telnet:测试连通性与端口开放
ip route / iptables -L:查看路由与转发规则
tcpdump:抓包分析流量走向
kubectl exec:进入 Pod 执行本地诊断
步骤 5:复现与验证
修复后,务必通过相同场景复现原始请求,确保问题真正解决,并观察是否引入新问题。
有疑问加站长微信联系(非本文作者))
入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889
关注微信13 次点击
0 回复
暂无回复
添加一条新回复
(您需要 后才能回复 没有账号 ?)
- 请尽量让自己的回复能够对别人有帮助
- 支持 Markdown 格式, **粗体**、~~删除线~~、
`单行代码` - 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
- 图片支持拖拽、截图粘贴等方式上传