Kubernetes网络通信实战：从Pod到Service全链路验证-育师

1. Kubernetes网络通信实战概述

在容器编排领域，Kubernetes已经成为事实上的标准，而网络通信是其最核心也是最容易出问题的部分。我最近在迁移一个关键业务系统到Kubernetes集群时，就遇到了各种诡异的网络问题：有的Pod能互相ping通但就是无法建立TCP连接，Service的ClusterIP在某些节点上突然不可达，NodePort服务在外网访问时断时续...这些问题让我深刻认识到，仅仅知道Kubernetes网络模型的理论是远远不够的，必须掌握从Pod到Service的全链路验证方法。

2. Kubernetes网络基础架构解析

2.1 Pod网络通信原理

每个Pod在Kubernetes中都有自己的IP地址，这个IP是由CNI插件分配的。我常用的Calico插件会为每个Pod分配一个/26的子网。关键点在于：

同一节点上的Pod通过veth pair连接到Linux网桥
跨节点通信通过BGP协议或IPIP隧道实现
每个Pod的IP在整个集群内都是可达的

验证命令：

# 查看Pod IP分配情况 kubectl get pods -o wide # 进入Pod测试基础网络 kubectl exec -it <pod-name> -- ping <another-pod-ip>

2.2 Service网络实现机制

Service是Kubernetes抽象出来的服务发现机制，主要有三种类型：

ClusterIP：默认类型，仅在集群内部可访问
NodePort：通过节点端口暴露服务
LoadBalancer：云厂商提供的负载均衡服务

背后的实现主要依赖kube-proxy，目前有三种工作模式：

userspace（已淘汰）
iptables（默认）
ipvs（性能更好）

查看当前模式：

kubectl get configmap -n kube-system kube-proxy -o yaml | grep mode

3. 全链路验证方法论

3.1 Pod间连通性测试

这是最基础的验证环节，但需要注意以下几点：

确保测试Pod没有网络策略(NetworkPolicy)限制
检查Pod所在节点的网络插件是否正常运行
验证DNS解析是否正常

我通常会部署一个专用的网络测试Deployment：

apiVersion: apps/v1 kind: Deployment metadata: name: network-tester spec: replicas: 2 selector: matchLabels: app: network-tester template: metadata: labels: app: network-tester spec: containers: - name: netshoot image: nicolaka/netshoot command: ["sleep", "3600"]

然后执行全面的网络测试：

# 测试基础连通性 kubectl exec -it network-tester-xxx -- ping <target-pod-ip> # 测试DNS解析 kubectl exec -it network-tester-xxx -- nslookup kubernetes.default # 测试端口连通性 kubectl exec -it network-tester-xxx -- nc -zv <target-pod-ip> 8080

3.2 Service连通性验证

Service的验证要复杂得多，我总结了一套完整的验证流程：

首先确认Service Endpoints是否正确

kubectl get endpoints <service-name>

从集群内部测试ClusterIP

kubectl exec -it network-tester-xxx -- curl http://<service-cluster-ip>:<port>

测试NodePort访问

# 从集群外部访问 curl http://<any-node-ip>:<node-port> # 从集群内部访问 kubectl exec -it network-tester-xxx -- curl http://<node-ip>:<node-port>

对于LoadBalancer类型，还需要验证：

云厂商的LB是否创建成功
健康检查是否通过
流量是否均匀分配到后端Pod

4. 常见问题排查指南

4.1 典型故障场景

Pod间无法通信

检查NetworkPolicy
验证CNI插件日志
查看节点路由表

Service无法访问

确认kube-proxy是否正常运行
检查iptables/ipvs规则
验证Endpoint是否正确

DNS解析失败

检查CoreDNS Pod状态
验证resolv.conf配置
测试上游DNS服务器

4.2 实用排查命令

# 查看kube-proxy日志 kubectl logs -n kube-system <kube-proxy-pod-name> # 检查iptables规则 iptables-save | grep <service-name> # 查看ipvs规则 ipvsadm -Ln # 检查网络插件状态 kubectl get pods -n kube-system | grep -E 'calico|flannel|weave' # 节点网络诊断 kubectl debug node/<node-name> -it --image=nicolaka/netshoot

5. 高级验证技巧

5.1 网络性能测试

使用iperf3测试Pod间带宽：

# 在一个Pod中启动服务器 kubectl exec -it pod1 -- iperf3 -s # 在另一个Pod中测试 kubectl exec -it pod2 -- iperf3 -c <pod1-ip>

5.2 全链路追踪

结合Istio实现全链路追踪：

部署Istio并启用自动sidecar注入
访问服务生成追踪数据
通过Jaeger UI查看调用链

5.3 混沌工程测试

使用chaos-mesh模拟网络故障：

apiVersion: chaos-mesh.org/v1alpha1 kind: NetworkChaos metadata: name: network-loss spec: action: loss mode: one selector: namespaces: - default labelSelectors: "app": "network-tester" loss: loss: "50" correlation: "25" duration: "30s"

6. 实战经验分享

在最近的一个生产案例中，我们发现某些NodePort服务在特定节点上无法访问。经过排查发现：

首先检查了kube-proxy日志，发现没有异常
然后测试了Pod间通信，确认基础网络正常
通过iptables-save发现缺少相应的NAT规则
最终发现是节点的conntrack表满了，导致新连接无法建立

解决方案：

# 增加conntrack表大小 echo 65536 > /proc/sys/net/netfilter/nf_conntrack_max echo 300 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established

另一个常见问题是DNS解析偶尔超时，这通常是由于：

CoreDNS Pod资源不足
节点上的conntrack表溢出
上游DNS服务器不稳定

我的优化方案：

# CoreDNS配置示例 apiVersion: v1 kind: ConfigMap metadata: name: coredns namespace: kube-system data: Corefile: | .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf { prefer_udp max_concurrent 1000 } cache 30 loop reload loadbalance }