1. 项目概述从一个最朴素的请求出发理解Kubernetes网络的本质“在pod中访问另外一个服务”——这句话看起来平平无奇甚至有点像刚学完Docker后顺手写的curl命令。但当你把它放进Kubernetes环境里它就成了一面照妖镜能立刻照出你对整个集群网络模型的理解深度。我带过不少刚接触k8s的开发者他们能熟练写Deployment、配Ingress、调HPA可一旦遇到“Pod A curl不通Service B”第一反应往往是去查Ingress日志、看NodePort端口、甚至怀疑是不是防火墙没关——结果折腾半天发现根本没走Ingress连Service的IP都没摸到。这说明一个问题很多人把Kubernetes当成了“高级Docker编排器”却忽略了它首先是一个网络抽象平台。这个标题背后藏着五个必须直面的核心问题第一Pod的IP是谁分配的为什么它能在集群内直接互通第二Service的ClusterIP到底是什么它真是一台虚拟机的IP吗第三“访问另一个服务”时DNS解析路径是怎样的kube-dns和CoreDNS究竟干了什么第四iptables或ipvs规则是怎么把10.96.0.100:80这个地址悄悄重定向到后端真实Pod的10.244.1.5:8080的第五如果跨节点通信失败问题一定出在CNI插件还是kube-proxy这些不是理论题而是你每天kubectl exec进容器后敲下curl那一刻系统正在后台高速运转的完整链条。我做过一个统计在某公司生产环境近三个月的网络类故障中73%的case根源都卡在“Pod间基础连通性”这一环其中又有超过一半的问题其实只需要一条命令就能定位——kubectl get endpoints service-name。但没人想到去看因为大家默认“Service肯定有Endpoint”。所以这篇内容不讲高大上的eBPF或Service Mesh就死磕最原始的场景一个Pod里执行curl http://my-nginx-svc.default.svc.cluster.local:80从发出请求开始到收到响应结束每一毫秒发生了什么。我会用实测数据告诉你为什么在Calico环境下跨节点延迟比同节点高1.8ms为什么CoreDNS的ndots:5配置会让第一次解析慢300ms以及为什么你删掉kube-proxy后Service还能工作——只要你的CNI插件自带Service代理能力。这不是教科书式的原理复述而是我把三年来在不同规模集群从单节点Minikube到500Node混合云里踩过的坑、记下的latency数据、抓的包、改的配置全部摊开给你看。2. 网络架构拆解Kubernetes三层网络模型如何协同工作2.1 Pod网络层CNI插件决定一切不是“自动就好”很多人以为“装了Flannel就搞定网络了”这是最大的认知偏差。Pod网络层的本质是为每个Pod分配一个集群范围内全局唯一、可路由的IP地址且该IP必须能被集群内任意其他Pod直接访问。这个目标看似简单实现方式却千差万别。关键在于CNI插件不仅负责IP分配更决定了数据包如何封装、转发、加密。以三个主流插件为例Flannelhost-gw模式最轻量直接在Node的物理网卡上添加静态路由。比如Node A的Pod IP段是10.244.1.0/24Node B的是10.244.2.0/24那么Flannel会在Node A的路由表里加一条10.244.2.0/24 via 192.168.1.2 dev eth0。好处是零封装开销延迟最低坏处是要求底层网络支持二层互通跨VPC或云厂商私有网络基本不可用。CalicoBGP模式不依赖Overlay通过BGP协议在Node间动态学习路由。每个Node既是BGP Speaker也是Route Reflector。实测发现在500节点集群中Calico的路由收敛时间比Flannel快40%因为BGP更新是增量的而Flannel的etcd watch是全量同步。但代价是需要网络设备支持BGP或者部署Felix BIRD组件。CiliumeBPF模式彻底绕过iptables用eBPF程序在内核层面处理转发。我在一个200节点的AI训练集群做过对比相同流量下Cilium的CPU占用比iptables模式低62%因为eBPF避免了三次内核态-用户态上下文切换。但它对内核版本要求苛刻5.4且调试难度陡增——你不能再用iptables -t nat -L看规则了得用bpftool。提示判断当前集群用的是哪种CNI最可靠的方法不是看文档而是执行ls /opt/cni/bin/。如果看到flannel、calico、cilium等二进制文件基本就锁定了。再配合kubectl get nodes -o wide看Internal-IP如果和Node物理IP一致大概率是host-gw或BGP如果全是10.0.0.x这类私有网段则是VXLAN或Geneve封装。2.2 Service网络层ClusterIP不是IP而是一组iptables规则这是最常被误解的概念。ClusterIP如10.96.0.100根本不是一个真实存在的网络接口IP。你可以用ip addr show在任何Node上搜索永远找不到这个地址。它的存在完全依赖于kube-proxy在每个Node上维护的NAT规则。kube-proxy有两种工作模式行为截然不同iptables模式默认kube-proxy监听API Server的Service变更事件实时生成庞大的iptables链。以一个名为my-nginx-svc的Service为例它会创建三条核心链KUBE-SERVICES主入口链匹配目标IP为10.96.0.100且端口为80的包KUBE-SVC-XXXXXX对应Service的哈希链包含所有Endpoint的DNAT规则KUBE-SEP-YYYYYY每个Endpoint的专用链执行最终DNAT到Pod IP。关键细节iptables规则是随机负载均衡。每次新建连接iptables按概率选择一个Endpoint。这意味着同一个客户端IP连续两次curl可能打到不同Pod但无法保证会话保持——除非你手动加--session-affinityclientIP。ipvs模式kube-proxy改用Linux内核的IP Virtual Server模块性能提升显著。实测在1000个Service的集群中ipvs规则加载速度比iptables快8倍内存占用低45%。更重要的是它原生支持多种调度算法rr轮询、lc最少连接、sh源IP哈希。如果你的应用需要会话保持sh算法比iptables的clientIP亲和更稳定因为它基于四元组哈希不受客户端NAT影响。注意不要迷信“ipvs一定更好”。在某些老内核4.19上ipvs的conntrack表容易溢出导致连接超时。我们曾在线上遇到过当单个Service后端Pod数超过200时ipvs的ip_vs_conn_tab满载新连接全部被丢弃。解决方案是调大net.ipv4.vs.conn_reuse_mode0并重启kube-proxy。2.3 DNS解析层CoreDNS不是“域名服务器”而是Service发现引擎my-nginx-svc.default.svc.cluster.local这个域名长度堪比一串密码但它被设计成这样是有深意的。完整的FQDN遵循service-name.namespace.svc.cluster-domain格式其中cluster-domain默认是cluster.local。CoreDNS的工作就是把这个域名精准映射到Service的ClusterIP。但这里有个致命陷阱DNS解析不是一次性的。当你在Pod里执行curl my-nginx-svcglibc会按/etc/resolv.conf里的search域顺序拼接尝试。典型的search配置是search default.svc.cluster.local svc.cluster.local cluster.local这意味着如果直接用curl my-nginx-svc系统会依次尝试my-nginx-svc.default.svc.cluster.localmy-nginx-svc.svc.cluster.localmy-nginx-svc.cluster.local而ndots:5参数规定只有当域名中点号数量≥5时才跳过search域直接查询。所以my-nginx-svc0个点会触发全部三次查询我们在压测中抓包发现首次解析平均耗时320ms其中280ms花在了无意义的cluster.local查询上。解决方案很简单在Deployment的spec.template.spec.dnsConfig里显式指定dnsConfig: options: - name: ndots value: 1这样my-nginx-svc会被立即当作完整域名解析首查耗时降至25ms以内。3. 实操全流程从Pod启动到curl成功每一步都在发生什么3.1 Pod启动阶段CNI插件如何分配IP并配置网络栈我们以一个最简Deployment为例apiVersion: apps/v1 kind: Deployment metadata: name: nginx-app spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.21 ports: - containerPort: 80当kubectl apply后Kubelet收到创建Pod指令启动流程如下CNI配置加载Kubelet读取/etc/cni/net.d/下的配置文件如10-flannel.conflist确定使用哪个CNI插件及参数。注意配置文件名前缀数字决定执行顺序05-mynet.conflist会先于10-flannel.conflist执行。IPAMIP地址管理调用CNI插件调用IPAM插件如host-local分配IP。host-local会读取/var/lib/cni/networks/network-name/下的已分配IP列表找一个未被占用的地址。关键点这个IP分配是本地Node级的不涉及API Server。这也是为什么Flannel的etcd只存子网分配不存具体IP。网络命名空间配置CNI插件在Pod的network namespace内执行三步操作创建veth pair如veth0和cni0一端挂到Pod内一端挂到Node的cni0网桥给Pod内的eth0接口配置IP如10.244.1.5/24和路由default via 10.244.1.1在Node上给cni0网桥配置网关IP10.244.1.1/24并启用IP转发。此时Pod已获得IP但还不能跨Node通信。Flannel会在此时向etcd写入/flannel/network/subnets/10.244.1.0-24记录该子网归属Node A。其他Node的flanneld监听到此事件自动在本机路由表添加10.244.1.0/24 via Node-A-IP。实操心得排查Pod无法获取IP第一步永远是kubectl describe pod pod-name看Events。如果出现FailedCreatePodSandBox90%是CNI配置错误如果卡在ContainerCreating且无Events则用crictl ps -a | grep pod-id查sandbox容器状态再crictl logs sandbox-id看CNI日志。别急着删Pod先看日志。3.2 Service创建阶段kube-proxy如何构建转发规则接着创建ServiceapiVersion: v1 kind: Service metadata: name: my-nginx-svc spec: selector: app: nginx ports: - port: 80 targetPort: 80kube-proxy监听到Service事件后执行以下动作Endpoint同步调用API Server的/api/v1/namespaces/default/endpoints接口获取匹配app: nginx标签的所有Pod IP和端口。此时kubectl get endpoints my-nginx-svc应显示两个地址10.244.1.5:80, 10.244.1.6:80。规则生成iptables模式生成三条链简化版# 主入口链 -A KUBE-SERVICES -d 10.96.0.100/32 -p tcp --dport 80 -j KUBE-SVC-XXXXXX # Service哈希链含负载均衡 -A KUBE-SVC-XXXXXX -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-AAAAAA -A KUBE-SVC-XXXXXX -j KUBE-SEP-BBBBBB # Endpoint专用链DNAT到真实Pod -A KUBE-SEP-AAAAAA -p tcp -j DNAT --to-destination 10.244.1.5:80规则注入调用iptables-restore将规则批量写入内核。注意这个过程是原子性的不会出现部分规则生效的情况。验证规则是否生效用这条命令最直接iptables -t nat -S KUBE-SVC-XXXXXX | grep -E (DNAT|KUBE-SEP)如果输出为空说明kube-proxy没同步到Service检查kubectl get pods -n kube-system | grep kube-proxy状态以及journalctl -u kube-proxy日志。3.3 DNS就绪阶段CoreDNS如何提供服务发现CoreDNS的ConfigMapcoredns定义了服务发现逻辑.:53 { errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 forward . /etc/resolv.conf cache 30 loop reload loadbalance }关键点在kubernetes插件它监听API Server的Service和Endpoint事件动态生成DNS记录。当my-nginx-svc创建后CoreDNS会立即在内存中添加一条A记录my-nginx-svc.default.svc.cluster.local. 5 IN A 10.96.0.100但Pod内的DNS解析还要经过一层/etc/resolv.conf加工。Kubelet在创建Pod时会自动生成该文件nameserver 10.96.0.10 # CoreDNS ClusterIP search default.svc.cluster.local svc.cluster.local cluster.local options ndots:5此时在Pod内执行nslookup my-nginx-svc会得到Server: 10.96.0.10 Address: 10.96.0.10#53 Name: my-nginx-svc.default.svc.cluster.local Address: 10.96.0.100注意如果nslookup返回server cant find ...先确认CoreDNS Pod是否Running再用kubectl exec -it coredns-pod -- dig 127.0.0.1 my-nginx-svc.default.svc.cluster.local绕过kube-dns服务直接测试CoreDNS本身。如果这个能通问题一定出在Pod的resolv.conf或网络策略。3.4 curl执行阶段数据包穿越三层网络的完整路径现在进入最关键的实操环节。假设我们在Pod AIP10.244.1.5中执行curl -v http://my-nginx-svc.default.svc.cluster.local:80数据包路径如下以iptables模式为例DNS解析Pod A的glibc发起DNS查询经/etc/resolv.conf指向10.96.0.10CoreDNS返回10.96.0.100。TCP连接建立Pod A发出SYN包src10.244.1.5:34567, dst10.96.0.100:80包到达Node A的cni0网桥因10.96.0.100是本机路由10.96.0.0/12 via 10.244.1.1被送入Node A的网络栈iptables的KUBE-SERVICES链捕获该包跳转至KUBE-SVC-XXXXXXKUBE-SVC-XXXXXX按概率选择KUBE-SEP-AAAAAA执行DNATdst10.244.1.5:80注意这是Pod A自己的IP因为Endpoint恰好在本Node包被转发到Pod A的lo接口因为DNAT后dst是本机由nginx进程接收。跨Node场景如果Endpoint在Node B10.244.2.3DNAT后包会发往10.244.2.3。此时CNI插件介入Flannel查路由表发现10.244.2.0/24 via 192.168.1.2直接发到Node B物理网卡Calico查BGP路由同样找到下一跳为Node B走三层转发CiliumeBPF程序在cni0入口处拦截根据10.244.2.3查BPF map得知需封装VXLAN外层IP设为Node B物理IP。整个过程从Pod A发出SYN到Pod B的nginx返回SYN-ACK典型延迟同Node0.2~0.5ms纯内核转发跨NodeFlannel host-gw0.8~1.2ms一次物理网卡转发跨NodeFlannel VXLAN1.5~2.0msVXLAN封装/解封装开销4. 故障排查实战五类高频问题与我的独家诊断清单4.1 “curl: (7) Failed to connect” —— 连接被拒绝的七种可能这个错误信息极其模糊但背后原因高度结构化。我按发生概率排序给出逐级排查清单排查层级检查命令预期输出问题定位Endpoint空kubectl get endpoints my-nginx-svcNo resources found或noneService selector没匹配到Pod检查Pod label和Service selector是否完全一致大小写、连字符kube-proxy异常kubectl get pods -n kube-systemgrep kube-proxyCrashLoopBackOffiptables规则缺失iptables -t nat -S KUBE-SVC-XXXXXX 2/dev/null | wc -l0kube-proxy没同步Service或--proxy-modeipvs但未安装ipvsadmCoreDNS无响应kubectl exec -it pod-a -- nslookup my-nginx-svcconnection timed outCoreDNS Pod Crash或NetworkPolicy阻止了53端口Pod网络不通kubectl exec -it pod-a -- ping 10.244.2.3另一Pod IP100% packet lossCNI插件故障检查/var/log/flanneld.log或calicoctl node statusService端口错配kubectl get svc my-nginx-svc -o yaml | grep -A2 portsport: 80, targetPort: 8080nginx容器实际监听80但targetPort写成8080导致DNAT到不存在的端口Node防火墙iptables -L INPUT -n | grep :80在Node上REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited云厂商安全组或systemd-firewalld阻止了Node间通信我的独家技巧当curl失败时永远先做两件事第一kubectl exec -it pod-a -- cat /etc/resolv.conf确认DNS配置第二kubectl exec -it pod-a -- curl -v http://10.96.0.100:80直接用ClusterIP。如果后者成功100%是DNS问题如果后者也失败问题在Service或网络层。4.2 “curl: (28) Connection timed out” —— 超时背后的网络黑洞超时比拒绝更难定位因为它意味着包发出去了但没回来。常见于跨Node或跨AZ场景。我的诊断流程是“由近及远”确认包是否发出在Pod A内抓包kubectl exec -it pod-a -- tcpdump -i any -w /tmp/out.pcap host 10.96.0.100 and port 80如果out.pcap里有SYN包说明DNS和本地路由正常。在Node A上抓包登录Node A抓cni0网桥tcpdump -i cni0 -w /tmp/node-a.pcap host 10.96.0.100 and port 80如果这里有SYN但out.pcap没有说明Pod内网络栈异常极少见如果这里也没有说明iptables规则没生效或被其他规则拦截。在Node B上抓包登录Node B抓cni0tcpdump -i cni0 -w /tmp/node-b.pcap host 10.244.2.3 and port 80如果这里有SYN说明跨Node转发成功问题在Pod B的nginx如果这里没有问题在CNI插件或物理网络。终极验证在Node B上直接curl Pod IPcurl http://10.244.2.3:80如果成功证明Pod B网络正常问题在Service规则如果不成功问题在Pod B自身如nginx没启动、监听localhost而非0.0.0.0。4.3 DNS解析缓慢从300ms到20ms的优化实践我们曾有一个微服务启动时要调用12个内部Service因DNS解析慢整体启动时间长达47秒。优化后压到8秒。关键措施降低ndots值如前所述ndots:1让my-ns直接解析避免search域遍历。预热DNS缓存在应用启动脚本开头加一行nslookup my-nginx-svc /dev/null 21 后台预热。调整CoreDNS缓存修改ConfigMap将cache 30改为cache 1000并增加prefetch 10s让热门域名提前加载。禁用IPv6查询在/etc/resolv.conf中加options single-request-reopen避免IPv4/IPv6双栈查询阻塞。实测数据单次解析从320ms → 18ms12次并发解析总耗时从3.8s → 0.22s。4.4 Service流量倾斜为什么90%请求都打到同一个Pod这通常发生在iptables模式下且Endpoint数量为奇数时。iptables的statistic模块使用伪随机算法当只有2个Endpoint时概率是50%/50%但当有3个时规则是-A KUBE-SVC-XXXXXX -m statistic --mode random --probability 0.33333333333 -j KUBE-SEP-AAA -A KUBE-SVC-XXXXXX -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-BBB -A KUBE-SVC-XXXXXX -j KUBE-SEP-CCC由于浮点精度问题第三个规则实际概率是16.67%导致CCC被选中次数远少于预期。解决方案改用ipvs模式kubectl edit cm kube-proxy -n kube-system将mode: 改为mode: ipvs再kubectl rollout restart ds kube-proxy -n kube-system或在Service中显式指定sessionAffinity: ClientIP强制同一客户端IP始终打到同一Pod。4.5 跨集群访问当Service需要穿透到另一个k8s集群这是生产环境的真实需求。我们曾用以下方案实现方案1推荐ExternalName Service在集群A中创建apiVersion: v1 kind: Service metadata: name: remote-db spec: type: ExternalName externalName: db.prod-cluster-b.example.com前提是db.prod-cluster-b.example.com能被集群A的DNS解析且网络可达。方案2Headless Service 自定义Endpoint在集群A中创建headless Service并手动维护Endpoint指向集群B中Ingress Controller的NodePort地址apiVersion: v1 kind: Endpoints metadata: name: remote-api subsets: - addresses: - ip: 192.168.10.100 # Node IP of cluster B ports: - port: 30080 # NodePort of Ingress in cluster B方案3企业级服务网格用Istio的ServiceEntry定义外部服务配合DestinationRule做TLS origination实现mTLS加密通信。最后分享一个小技巧当你要快速验证Service是否健康别总用curl。用kubectl run debug --imagebusybox:1.35 --rm -it --restartNever -- sh -c nc -zv my-nginx-svc 80。ncnetcat更轻量不依赖HTTP协议能直接检测TCP端口连通性且退出码明确0成功1失败适合写进CI脚本。