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-ip2.2 Service网络实现机制Service是Kubernetes抽象出来的服务发现机制主要有三种类型ClusterIP默认类型仅在集群内部可访问NodePort通过节点端口暴露服务LoadBalancer云厂商提供的负载均衡服务背后的实现主要依赖kube-proxy目前有三种工作模式userspace已淘汰iptables默认ipvs性能更好查看当前模式kubectl get configmap -n kube-system kube-proxy -o yaml | grep mode3. 全链路验证方法论3.1 Pod间连通性测试这是最基础的验证环节但需要注意以下几点确保测试Pod没有网络策略(NetworkPolicy)限制检查Pod所在节点的网络插件是否正常运行验证DNS解析是否正常我通常会部署一个专用的网络测试DeploymentapiVersion: 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 80803.2 Service连通性验证Service的验证要复杂得多我总结了一套完整的验证流程首先确认Service Endpoints是否正确kubectl get endpoints service-name从集群内部测试ClusterIPkubectl 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是否创建成功健康检查是否通过流量是否均匀分配到后端Pod4. 常见问题排查指南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 --imagenicolaka/netshoot5. 高级验证技巧5.1 网络性能测试使用iperf3测试Pod间带宽# 在一个Pod中启动服务器 kubectl exec -it pod1 -- iperf3 -s # 在另一个Pod中测试 kubectl exec -it pod2 -- iperf3 -c pod1-ip5.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: 30s6. 实战经验分享在最近的一个生产案例中我们发现某些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 }