K8s网络深度解析：从容器网络到Service负载均衡排障实战

容器化网络与Kubernetes网络深度解析

搞容器和Kubernetes这些年，我最大的感受是：应用跑不起来还能靠日志猜，网络不通才是真的让人抓狂。Pod间通信、Service负载均衡、Ingress接入、多集群互联，每一层都藏着不少坑。很多刚入门的朋友把精力全放在镜像构建和YAML编写上，一遇到网络问题就懵了。这篇文章我从实际运维和排障的角度，把容器化网络和Kubernetes网络拆开揉碎讲清楚，包括CNI插件怎么选、Pod通信的底层逻辑、Service的iptables规则细节、DNS解析链路、网络策略配置，以及我自己踩过的那些坑和排查套路。不管你是刚接触容器的新手，还是被K8s网络折腾过的运维，都能在里头找到点有用的东西。

1. 容器网络基础与Kubernetes网络模型

1.1 容器为什么需要自己的网络命名空间

要理解Kubernetes网络，先得把单机容器的网络机制弄明白。容器本质上是宿主机上的进程，但它跑在独立的网络命名空间（Network Namespace）里，有自己的回环接口、路由表、iptables规则和网络栈。用ip netns list能看到这些命名空间，用nsenter或docker exec进入容器后，你看到的eth0其实是一个虚拟网卡，而不是宿主机上的物理网卡。

为什么非得这么设计？如果不隔离网络栈，所有容器就得共享宿主机的IP和端口，A容器监听8080，B容器就不能再监听8080，这和直接在宿主机上跑进程没有区别，容器“环境隔离”的价值就少了一大半。有了独立的网络命名空间，每个容器可以有自己的IP、自己的端口空间、自己的防火墙规则，就像一台独立的虚拟机一样。

容器和宿主机之间的通信，靠的是虚拟以太网对（veth pair）。可以把它理解成一根虚拟网线，一头插在容器里（就是容器里的eth0），另一头插在宿主机的一个网桥上（通常叫docker0或cni0）。数据包从容器发出的过程是：进程把包交给容器内的eth0，通过veth对到达宿主机侧的对端接口，然后由网桥决定是转发给宿主机上其他容器，还是通过NAT转发到外部网络。

1.2 Kubernetes网络模型的三条铁律

Kubernetes对网络有非常明确的约束，业内称其为“Kubernetes网络模型”，核心有三条：Pod和Pod之间可以不经过NAT直接通信；节点和Pod之间可以不经过NAT直接通信；Pod自己看到的IP，和别人看到的IP是同一个。

这三点要求意味着Kubernetes集群的Pod网络必须是一个扁平的、全局可达的二层/三层网络，而不是依赖端口映射和NAT的传统容器网络模式。对比一下Docker默认的bridge网络：容器IP在宿主机内是私有的，跨宿主机访问需要-p映射端口，这显然不满足K8s的模型要求。所以Kubernetes把网络方案做成插件化的，这就是CNI（Container Network Interface）存在的意义。

容器网络接口（CNI）是一个标准规范，定义了容器运行时（containerd、CRI-O等）如何调用网络插件来给容器分配IP、挂载网络接口、配置路由。你不需要关心底层实现，只要遵守这个接口，任何CNI插件都能无缝接入K8s。这类插件选型是整个集群网络架构里最关键的决策之一，后文详细讲。

1.3 千万别忽略的本地回环网络

容器里默认有lo回环接口，IP为127.0.0.1。调试时常用curl 127.0.0.1验证本机服务是否正常，但这个操作只能验证容器内进程，不能验证Pod的网络连通性。很多新手在Pod里执行curl 127.0.0.1:8080发现通，就认为服务正常，结果跨Pod访问不通，排错了方向。

我遇到过不止一次：某应用的主进程监听的是容器的eth0IP，而不是0.0.0.0，导致Service探针存活检查失败。这不是网络模型的问题，而是应用监听地址配置不对。规范做法是让服务监听0.0.0.0，避开网络命名空间带来的这类坑。

2. Kubernetes网络核心：Pod通信的三条路径

2.1 同节点Pod通信：网桥转发

同一个节点上的Pod通信是最简单的一层。CNI插件（常见的是Calico的cali接口、Flannel的cni0、Cilium的cilium_host等）会创建一个虚拟网桥，所有Pod的veth对都插到这个网桥上。Pod A发往Pod B的数据包：A的eth0 → veth对 → 网桥 → 查MAC地址表 → 从对应veth对出去 → 进入B的eth0。

这个过程的效率很高，完全在内核态完成，不经过用户态转发，延迟通常在微秒级。排查同节点Pod通信问题时，用bridge link查看veth对与网桥的挂载关系，用ip neigh查看邻居表是否有对应Pod的MAC地址，一般就能定位问题。

一个容易被忽略的细节：网桥上有时会有“端口隔离”配置，部分CNI插件为了保证网络策略生效，会在网桥端口上做isolation标记，导致同网桥的Pod默认隔离。遇到“明明在同一台宿主机上，Pod却互相ping不通”的情况，先看看是不是网络策略（NetworkPolicy）在起作用，而不是一上来就抓包。

2.2 跨节点Pod通信：Overlay还是BGP路由

跨节点通信是K8s网络复杂度最高的地方，也是选型时争议最多的部分。主流方案大致分两类：Overlay隧道和纯路由方案。

Overlay的典型代表是Flannel的VXLAN模式和Calico的IPIP模式。原理是在原有三层网络之上再构建一层虚拟二层网络：节点上的Pod网段是一个独立大网段（比如10.244.0.0/16），每个节点分到一个子网（比如10.244.1.0/24）。跨节点发送数据包时，源节点把原始的Pod数据包封装进UDP包（VXLAN端口通常是4789），目的IP写成目标节点IP，到对端再解封装还原。这种方式对底层网络没有要求，只要节点间三层可达就行，非常适合公有云环境，但封装和解封装会带来额外的CPU开销，时延会增加0.1ms到0.5ms，在万兆网卡和高并发场景下吞吐量会有损耗。

纯路由方案的代表是Calico的BGP模式。Calico不封装数据包，而是把每个节点当作一个BGP路由器，节点之间通过BGP协议交换Pod网段路由。数据包直接以Pod IP作为目的地址发送，通过节点的路由表一跳一跳地转发到目标Pod。这种方式性能好、延迟低，跟物理网络的路由方式一致，但它要求底层网络能允许节点间跑BGP，且不支持公有云VPC内的路由冲突场景，所以Calico在公有云一般还是建议IPIP或VXLAN模式。

怎么选？我给个实用建议：自建机房物理机部署，无特殊要求选Calico BGP，性能最好；公有云ECS选Flannel VXLAN或Calico IPIP，省心稳定；需要网络策略细致管控、服务网格或可观测性要求高的，直接选Cilium，它基于eBPF实现，性能和功能都非常优秀，但运维门槛也更高。

2.3 Service与负载均衡的精妙设计

Pod IP是动态的，每次重建都会变化，如果让客户端直连Pod IP，应用就没法稳定寻址了。Kubernetes的Service对象就是为了解决这个问题诞生的。Service有一个稳定的虚拟IP（ClusterIP），客户端只需要访问这个IP，集群内部会自动把流量转发到后端的Pod上。

Service的底层实现是依靠节点上的iptables或IPVS规则。以iptables模式为例，当Service创建时，Kube-Proxy会watch API Server中的Service和Endpoints变化，然后在所有节点上写入一套链式规则。客户端访问ClusterIP时，数据包命中KUBE-SERVICE链，被转到对应的KUBE-SVC-XXX链，再由KUBE-SEP-XXX链随机选择一台后端Pod，做DNAT把目的IP改成Pod IP，然后把包发出去。

这套机制有个非常经典的坑：客户端发起连接时，数据包经过DNAT后源IP没有变，Pod里看到的source IP是客户端IP，这是没问题的；但当一个Pod A通过Service访问Pod B时，如果A和B在同一个节点上，而B又只有一个后端副本，那么数据包从A发出→上宿主机iptables→DNAT转给B，这个包其实又绕回了本机的PodB，但Pod A发出去的时候，数据包是从Pod的veth出去的，到了宿主机后由路由和iptables处理完，又会从veth进去到Pod B。问题来了：此时Pod B会看到source IP是Pod A的veth IP吗？不会，因为数据包在节点上被转发时做了DNAT，但它没有做SNAT，所以Pod B看到的源地址是Pod A的IP，这没问题。真正的问题是当Pod A和Pod B在不同节点时，B节点收到包后回包的目的地址是A节点上Pod A的IP，这也没问题，因为Pod网段是全局路由可达的。那什么时候会出问题呢？当Service的externalTrafficPolicy设为Local时，如果客户端访问NodePort，且后端Pod不在当前节点，流量会被丢弃。这就是为什么见到“有的节点能访问，有的节点不能访问”的经典故障时，先要查这个参数。

更优雅的方案是IPVS模式。iptables规则在Pod数量超过1000以后，链式匹配的耗时明显上升，性能断崖式下跌。IPVS是内核里专门为负载均衡设计的模块，用哈希表做查找，时间复杂度是O(1)，性能稳定。从K8s 1.11开始，kube-proxy默认支持IPVS模式，生产环境中大集群建议开启。开启方法很简单，在kube-proxy的配置里把mode改成ipvs，同时节点上确认安装了ipvsadm和内核模块。

3. 网络细节：DNS、Ingress与网络策略

3.1 服务发现与CoreDNS

K8s集群里的服务发现，默认走DNS。集群里通常运行着一个CoreDNS Deployment，它监听集群的DNS服务IP（一般是Service网段的第十个地址，比如10.96.0.10）。Kubelet在创建Pod时，会把集群DNS服务IP写进Pod的/etc/resolv.conf，同时设置search搜索域为<namespace>.svc.cluster.local svc.cluster.local cluster.local，这样Pod里访问同一个命名空间下的服务时，直接写服务名就能解析。比如curl my-service:8080，DNS解析时会依次尝试my-service.default.svc.cluster.local、my-service.svc.cluster.local、my-service.cluster.local，最终命中第一条。

这里有个常见的坑：如果/etc/resolv.conf里search域太长（超过6个或总长度超过256字符），glibc会直接忽略整个文件，导致域名解析全部失败。如果你的应用容器需要挂载自定义DNS配置，建议使用dnsPolicy: None和dnsConfig显式指定，别在镜像里乱改resolv.conf。

另外一个值得记住的点是：Pod的/etc/resolv.conf里的nameserver是集群DNS的ClusterIP，这个IP只有在节点上被kube-proxy的iptables规则处理后才能通，所以如果节点网络异常或kube-proxy挂了，所有Pod的DNS解析都会挂掉——表现为应用报“域名解析失败”，但Pod本身网络正常。

3.2 Ingress Controller：外部流量怎么进集群

Service的ClusterIP是集群内部IP，外部网络无法直接访问。想从集群外访问服务，有几种方式：NodePort类型Service、LoadBalancer类型Service、Ingress。NodePort会在每个节点上开一个高位端口（30000-32767）把流量转发给Service，如果你只有一个测试环境，这种方式最简单。LoadBalancer适合公有云，云厂商会把负载均衡器的流量引到节点端口。Ingress则是更上层的方案：它是Kubernetes的一个API对象，但本身不算控制器，真正干活的是Ingress Controller（比如nginx-ingress-controller、Traefik、HAProxy）。

Ingress的架构是这样的：Ingress Controller本身是一个Pod（通常是Deployment），对外暴露为NodePort或LoadBalancer，它负责读取Ingress规则（域名、路径匹配、后端Service），然后动态生成自己的反向代理配置文件。外部流量 → Ingress Controller → 按域名/路径路由 → 后端Service → Pod。要理解一点：Ingress规则只是声明，没有Ingress Controller，这些规则完全不生效。

用nginx-ingress-controller时，如果要上传大文件，需要在ConfigMap里改proxy-body-size；要支持WebSocket，需要在注解里加nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"。这些配置细节只有实际用的时候才体会得到，文档里不会细讲。

3.3 NetworkPolicy：微服务防火墙

默认情况下，Kubernetes集群里的Pod和Pod之间是可以自由通信的，不受任何限制。但在生产环境，安全合规要求“最小权限”，就需要用NetworkPolicy来做访问控制。NetworkPolicy是Kubernetes原生的安全策略API，它通过标签选择器（selector）来选定目标Pod组，然后定义允许哪些来源访问、允许访问哪些目的地。

以Calico为数据面时，NetworkPolicy会被翻译成Calico的felix规则，最终下发到节点的iptables或eBPF。一个典型的业务隔离需求是：只允许前端Pod访问后端Pod的8080端口，不允许其他Pod访问。对应的NetworkPolicy写法是：podSelector选出后端Pod，ingress规则里from选前端Pod的标签，ports限制为8080。

这里要特别提醒：NetworkPolicy的匹配顺序是按规则从上到下依次评估，一旦有规则匹配，就停止后续匹配。如果你的策略没有放行某个流量，那就意味着默认拒绝。很多人加了策略后应用突然不通，通常是因为from选的标签不对，或者漏掉了namespaceSelector作用范围不对。调试时用kubectl get networkpolicy -n <ns>和kubectl describe networkpolicy <name>看清规则详情，再去查Pod标签。

4. 实战复盘：容器化部署与Kubernetes网络排查

4.1 一次完整的多网卡容器化部署实战

最近我把一套“webvirtcloud”风格的云管理平台做了容器化改造，涉及Web前端、虚拟化调度后端、数据库三部分，容器网络配置踩了不少坑。说说整个流程和关键网络决策。

第一步，梳理组件与端口依赖。Web前端监听80，后端服务监听8080，数据库监听3306。容器化后，为了让前端能通过固定地址访问后端，我建了一个自定义Docker网络：docker network create --driver bridge --subnet 172.20.0.0/16 app-network。这里用自定义网络而不是默认bridge网络，原因很简单：自定义网络支持容器间DNS解析，前端容器里可以直接用backend这个名字访问后端，而不是写死IP。

第二步，后端服务启动时挂到app-network网络，并设置固定IP（方便日志采集和防火墙配置）：docker run --network app-network --ip 172.20.0.10 backend。前端容器同样挂到app-network，用环境变量注入后端地址：docker run --network app-network -e BACKEND_URL=http://backend:8080 frontend。

第三步，外网访问入口。宿主机上配置Nginx做反向代理，把宿主机80端口转发到前端容器的80端口。这里不要用Docker的-p 80:80直接映射容器端口，而是用宿主机Nginx，因为后续上K8s Ingress时，Nginx的配置可以平滑迁移到Ingress Controller的注解里，架构演进成本低。

这中间有个插曲：前端容器启动后一直报“连接后端超时”。我进容器里curl backend:8080是通的，后来发现是前端代码里配置了硬编码的数据库IP，而不是通过后端API连接。改配置后问题解决。容器化改造时，最忌讳的就是把宿主机网络细节（IP、固定端口）嵌进应用代码，一定要用服务名+环境变量解耦。

4.2 从Pod访问Service超时的排查思路

有一次生产环境报障：某服务通过Service访问另一个服务，时通时不通，重启Pod后短暂恢复，过一会儿又超时。这种间歇性故障最考验排查思路。

第一步，验证Pod到后端Pod的直连是否通。进入源Pod，用curl访问后端PodIP:端口。如果直连通，问题基本锁定在Service这一层。

第二步，检查Service的Endpoints是否正常。kubectl get endpoints <service>，如果Endpoints列表为空，说明Service的selector没匹配到后端Pod，或后端Pod未就绪（readiness探针失败）。这是“时通时不通”最常见的原因：某个Pod就绪探针不稳定，被摘除后又被加入，导致部分请求正好落在已摘除的Pod上。

第三步，看kube-proxy和iptables规则。进入节点执行iptables -t nat -L KUBE-SERVICES -n -v，找对应Service的规则，看是否有DNAT记录被创建。如果规则已经存在但请求仍超时，需要检查后端Pod的存活状态和节点的conntrack表：cat /proc/sys/net/netfilter/nf_conntrack_max和cat /proc/net/nf_conntrack，连接跟踪表满了之后，新连接会被丢弃，表现为间歇性超时。

那次最终的根因就是某节点conntrack表溢出。频繁创建短连接的高并发应用很容易触发，用IPVS模式能缓解一部分，但最根本的做法是调整nf_conntrack_max，并检查应用是否用了连接池。

4.3 常见网络故障速查表

4.4 给新手的几条实战建议

第一，先学抓包。tcpdump是排网络问题最好的朋友，在关键节点上抓包能看到数据包的真实走向：tcpdump -i any -n port 8080 -w /tmp/capture.pcap，然后用Wireshark分析。不要一上来就猜。

第二，容器里默认没有tensorflow、tcpdump、ip等工具，调试时可以用kubectl debug node/<node> -it --image=nicolaka/netshoot这样的方式启动一个带全套网络调试工具的Pod，挂到目标命名空间里，非常方便。

第三，理解网络是分层排查的：先从物理层、IP层看通不通，再查端口、协议层，最后再看应用层。不要在应用代码里乱加日志排网络，那是浪费生命。

第四，监控和告警要提前做。节点带宽、TCP连接数、conntrack使用率、CoreDNS解析延迟，这些都是K8s网络健康的核心指标，用Prometheus都能轻松采集，别等到故障才想着看。

网络这块的知识面很广，从Linux网络栈、iptables到CNI插件、Service、Ingress、NetworkPolicy，每一个点都能单独写一篇大文章。这篇文章我尽量把最核心的架构和最容易踩的坑串起来了，希望能帮你少走点弯路。如果你正在做容器化改造，或者刚接触K8s网络，建议先拿一个测试集群，把Flannel、Calico、Cilium各装一遍，然后用kubectl run起几个Pod互相访问，动手验证一遍本文讲的每一条路径，比死记硬背强太多了。后面我还会针对Cilium的eBPF数据面、Ingress Controller的高可用配置，单独写几篇实测笔记，欢迎持续关注。