1. 为什么需要全链路网络验证在Kubernetes集群中网络通信是最基础也是最容易出问题的环节之一。我见过太多这样的情况开发人员信誓旦旦地说我的服务在本地跑得好好的但一部署到K8s环境就出现各种连接超时、拒绝访问的问题。究其原因往往是因为对Kubernetes网络模型的理解停留在表面。Pod间的通信要经过哪些网络组件Service的虚拟IP是如何映射到实际Pod的Ingress控制器又是如何介入这个过程的这些问题如果不通过实际验证很容易在故障排查时陷入盲目猜测的境地。上周我就遇到一个典型案例某个微服务调用超时团队花了三天时间检查代码最后发现是NetworkPolicy配置错误导致流量被丢弃。2. Pod网络连通性验证2.1 基础环境准备我们先准备一个测试用的DeploymentapiVersion: apps/v1 kind: Deployment metadata: name: network-test spec: replicas: 2 selector: matchLabels: app: network-test template: metadata: labels: app: network-test spec: containers: - name: nginx image: nginx:alpine ports: - containerPort: 80应用这个配置后用以下命令获取Pod的IP地址kubectl get pods -o wide --selectorappnetwork-test2.2 同节点Pod间通信在其中一个Pod中执行kubectl exec -it pod-name -- sh # 在Pod内执行 apk add curl curl another-pod-ip预期应该看到Nginx的欢迎页面。这里有个关键点即使两个Pod在同一节点Kubernetes也不会使用主机网络直接通信而是通过CNI插件创建的虚拟网络设备。2.3 跨节点Pod通信要测试这个场景你需要确保集群有多个工作节点通过节点亲和性将Pod调度到不同节点重复上述curl测试如果跨节点通信失败常见原因包括节点间防火墙规则阻止了Pod网络CIDRCNI插件配置错误如Flannel的backend类型不匹配节点路由表缺失某些CNI需要手动配置路由3. Service网络机制解析3.1 ClusterIP Service验证创建测试ServiceapiVersion: v1 kind: Service metadata: name: test-svc spec: selector: app: network-test ports: - protocol: TCP port: 80 targetPort: 80验证步骤获取Service的ClusterIPkubectl get svc test-svc从集群内部访问kubectl run -it --rm --imagealpine test -- sh apk add curl curl cluster-ip检查iptables规则如果使用iptables模式iptables-save | grep test-svc3.2 深入理解kube-proxyService的核心是kube-proxy组件它有三种工作模式模式原理性能影响适用场景userspace流量经过用户态转发高延迟旧版本兼容iptables内核态规则匹配规则量大时性能下降大多数场景ipvs基于内核哈希表高性能大规模集群可以通过以下命令检查模式kubectl get pods -n kube-system -l k8s-appkube-proxy -o yaml | grep mode4. 全链路故障排查实战4.1 典型问题排查流程当遇到网络问题时建议按照以下顺序排查Pod内容器是否正常运行kubectl logs pod-namePod的IP能否ping通kubectl exec -it pod-name -- ping target-ipService的Endpoints是否正确kubectl get endpoints service-name网络策略是否阻止流量kubectl get networkpolicy --all-namespaces4.2 常见问题案例案例1Service无法访问检查点Service的selector是否匹配Pod标签targetPort是否与容器端口一致是否误删了kube-proxy Pod案例2跨Namespace访问失败解决方案使用完全限定域名 . .svc.cluster.local检查NetworkPolicy是否允许跨命名空间访问案例3NodePort无法外部访问排查步骤检查节点防火墙规则验证kube-proxy是否正常运行查看节点上的端口监听情况netstat -tuln | grep node-port5. 高级验证与监控5.1 网络性能测试使用iperf3进行带宽测试创建iperf serverapiVersion: apps/v1 kind: Deployment metadata: name: iperf-server spec: replicas: 1 selector: matchLabels: app: iperf-server template: metadata: labels: app: iperf-server spec: containers: - name: iperf image: networkstatic/iperf3 args: [-s] ports: - containerPort: 5201创建client Pod进行测试kubectl run -it --rm --imagenetworkstatic/iperf3 iperf-client -- -c server-pod-ip -t 205.2 网络监控方案推荐监控指标容器网络吞吐量bytes_in/bytes_out网络错误计数errors_in/errors_outTCP重传率DNS查询延迟Prometheus示例查询sum(rate(container_network_receive_bytes_total{namespacedefault}[5m])) by (pod_name)6. 生产环境最佳实践经过多年实践我总结了以下经验网络插件选择中小集群Calico性能好功能全大规模集群Cilium基于eBPF可观测性强云厂商托管优先使用云提供的CNI如AWS VPC CNIService使用建议避免使用ClusterIP直接通信优先使用DNS名称对性能敏感的服务考虑使用Headless Service外部访问统一通过Ingress收敛关键配置检查# 检查CNI插件状态 kubectl get pods -n kube-system -l k8s-appcni-component # 检查核心DNS解析 kubectl run -it --rm --imagebusybox:1.28 test -- nslookup kubernetes.default网络策略实施默认拒绝所有流量按最小权限原则开放必要通信重要业务使用独立NetworkPolicy资源