1. 困在迷宫的集装箱：Kubernetes网络问题现场还原
某天深夜接到SRE团队告警："订单服务POD失联，支付失败率飙升！"当我们打开kubectl get pods -o wide时，发现两个工作节点上的Pod互相看不到对方。这就像是集装箱货轮上的货物突然无法被邻船扫描到，整个业务流水线瞬间瘫痪。
网络问题就像突然雾化的海面，我们需要雷达（工具）和航海图（排查方法）来穿透迷雾。以下是我们实战中总结的九段排查法：
2. 口袋里的瑞士军刀：核心排查工具全家福
2.1 空间折叠装置：nsenter
# 进入目标Pod所在网络命名空间（需具备节点SSH权限）
$ PID=$(docker inspect -f {{.State.Pid}} 3b6d5a1f1a32)
$ nsenter -n -t $PID
# 此时相当于直接进入容器的网络视角
[容器网络空间]# ping 10.244.2.5 # 测试跨节点Pod连通性
[容器网络空间]# curl -I http://nginx-service:80 # 验证Service解析
这个工具就像《盗梦空间》的造梦机，能让人直接进入容器的网络视角。实际案例中，曾用此方法发现某个Java应用的SNAT规则被篡改。
2.2 网络X光机：tcpdump
# 在目标节点抓取cali前缀的网卡流量（Calico环境）
$ tcpdump -i cali1a2b3c4d5e -nn -vvv
# 过滤特定协议和端口（观察DNS查询是否正常）
$ tcpdump -i any port 53 -nn -vvv
# 捕获跨节点通信的VXLAN封装数据（Flannel环境）
$ tcpdump -i flannel.1 -nn -vvv
某次重大故障中，通过此法发现CNI插件生成的veth pair存在MTU不匹配问题，导致大尺寸数据包被丢弃。
3. 经典迷宫结构：常见故障场景全解析
3.1 跨节点通信黑洞（Calico环境）
# 检查BGP邻居状态（要求节点间建立BGP会话）
$ calicoctl get node node-01 -o yaml | grep -iB 3 bgp
# 验证路由表是否正确注入
$ ip route show | grep 10.244.2.0/24
# 期望输出：10.244.2.0/24 via 192.168.5.22 dev ens3 proto bird
# 验证物理网络互通性（跳过k8s网络栈）
$ ping -c 3 192.168.5.22 -I eth0
该场景常见于BGP会话中断导致的"孤岛节点"，曾因节点防火墙阻断TCP 179端口引发全集群通信故障。
3.2 Service IP寻址谜团
# 检查kube-proxy的iptables规则链
$ iptables-save | grep KUBE-SVC-ABCDEF
# 追踪Service到Endpoints的映射关系
$ kubectl get endpoints nginx-service -o wide
NAME ENDPOINTS AGE
nginx-service 10.244.1.5:80 18h
# 强制刷新kube-proxy规则（适用于iptables模式）
$ systemctl restart kube-proxy
某个案例中，由于endpoints控制器延迟导致服务15分钟不可用，最终调整kube-controller-manager的并发参数解决问题。
4. 高级迷宫解密术：网络策略与CNI插件探秘
4.1 Calico网络策略实战
# 允许来自frontend命名空间的HTTP访问（示例政策）
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
name: allow-http
namespace: backend
spec:
ingress:
- action: Allow
protocol: TCP
source:
namespaceSelector: name == "frontend"
destination:
ports: [80]
某次安全事件后，使用三层级联策略成功实现了微服务的零信任网络，期间发现CIDR匹配规则的优先级问题。
4.2 幽灵数据包之谜：conntrack表溢出
# 检查连接追踪表状态
$ sudo sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 257836
# 验证表大小限制（默认65536）
$ sudo sysctl net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_max = 262144
# 临时清理conntrack表
$ sudo conntrack -F
在高并发电商系统中，曾遇到conntrack表项耗尽导致随机连接失败，最终通过优化服务调用模式和调整内核参数解决。
5. 经验水手的忠告：注意事项与最佳实践
- 权限迷宫：调试工具往往需要root权限，生产环境需通过kubectl debug实现安全接入
- 版本陷阱：不同K8s版本网络组件差异巨大（如从iptables到ipvs的演进）
- 插件适配：同一问题在不同CNI实现（Calico/Cilium/Flannel）的表现可能截然不同
- 性能监控：需要建立网络指标的黄金指标体系（丢包率、延迟、连接数等）
6. 迷雾散去之后：总结与展望
经过八年kubernetes网络运维实战，我们形成了"从Pod到物理网络"的七层排查法。现代云原生网络正朝着服务网格与eBPF技术深度整合的方向发展，但传统网络问题的基本排查方法仍然是技术人员的必备技能。
评论