保姆级教程：用`ipvsadm`和`iptables-save`命令，一步步拆解K8s Service的流量转发路径
深入拆解Kubernetes Service流量转发：从命令行视角看ipvs与iptables的协同
当你第一次在Kubernetes集群中创建一个Service时，有没有好奇过这个虚拟IP背后究竟发生了什么？为什么一个ClusterIP能够稳定地将流量路由到可能随时变化的Pod上？今天我们就用ipvsadm和iptables-save这两把"手术刀"，在真实的Minikube集群中解剖这个看似简单实则精妙的过程。
1. 实验环境准备与基础概念
在开始我们的探索之旅前，让我们先搭建一个简单的实验环境。使用Minikube创建一个本地集群是最快捷的方式：
minikube start --driver=docker --network-plugin=cni --extra-config=kube-proxy.mode=ipvs这个命令创建了一个使用ipvs模式的Kubernetes集群。为什么特别指定ipvs？因为在生产环境中，ipvs模式通常能提供更好的性能，特别是当你有大量Service时。不过别担心，我们也会探讨iptables模式的工作机制。
几个核心概念需要明确：
- Service：Kubernetes中的抽象，为一组Pod提供稳定的访问入口
- Endpoint：Service背后实际提供服务的Pod IP和端口集合
- kube-proxy：运行在每个节点上的网络代理，负责实现Service的虚拟IP机制
让我们创建一个简单的Nginx Deployment和对应的Service：
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 type: ClusterIP应用这个配置后，我们就有了一个完美的实验对象。现在，让我们进入正题。
2. 解剖iptables模式下的流量路径
虽然我们创建集群时指定了ipvs模式，但理解iptables模式仍然很重要，因为ipvs模式实际上也依赖iptables完成部分功能。让我们先看看纯iptables模式下的转发机制。
2.1 关键iptables链解析
在iptables模式下，kube-proxy会创建一系列自定义链来处理Service流量。这些链的名字通常以KUBE-SVC-和KUBE-SEP-开头。让我们看看它们的实际作用：
# 查看与我们的nginx-service相关的iptables规则 minikube ssh -- sudo iptables-save | grep -i nginx-service你会看到类似这样的输出（具体哈希值会不同）：
-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp -m comment --comment "default/nginx-service: cluster IP" -m tcp --dport 80 -j KUBE-SVC-2CMXP7HKUVJN7L6M -A KUBE-SVC-2CMXP7HKUVJN7L6M -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-XYZZY123456 -A KUBE-SVC-2CMXP7HKUVJN7L6M -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-ABCDEF789012 -A KUBE-SVC-2CMXP7HKUVJN7L6M -j KUBE-SEP-987654ZYXWVU这些规则的含义：
- 第一条规则将所有目标为Service ClusterIP(10.96.0.1)且端口为80的流量跳转到
KUBE-SVC-*链 - 后续规则实现了简单的负载均衡，使用概率将流量分配到不同的
KUBE-SEP-*链（每个对应一个Pod）
2.2 深入Endpoint链
每个KUBE-SEP-*链对应一个具体的Pod端点。让我们看看其中一个：
minikube ssh -- sudo iptables-save | grep KUBE-SEP-XYZZY123456输出可能类似：
-A KUBE-SEP-XYZZY123456 -s 10.244.0.5/32 -j KUBE-MARK-MASQ -A KUBE-SEP-XYZZY123456 -p tcp -m tcp -j DNAT --to-destination 10.244.0.5:80关键点：
- 第一条规则为来自Pod自身的流量打上标记（用于后续的SNAT）
- 第二条规则执行DNAT，将目标地址改为Pod的实际IP和端口
2.3 iptables模式的性能考量
虽然iptables模式简单可靠，但它有一个明显的缺点：随着Service和Pod数量的增加，iptables规则会呈指数级增长。这是因为：
规则数量 ≈ Service数量 × 每个Service的Endpoint数量 × 节点数量当集群规模较大时（比如超过1000个Service），iptables的线性查找性能会成为瓶颈。这就是为什么Kubernetes引入了ipvs模式。
3. ipvs模式下的流量转发机制
现在让我们回到ipvs模式，看看它是如何解决iptables的规模问题的。
3.1 ipvs基础组件
ipvs模式下，kube-proxy会创建一个名为kube-ipvs0的虚拟接口，并为每个Service分配一个IP地址：
minikube ssh -- ip addr show kube-ipvs0输出类似：
4: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default inet 10.96.0.1/32 scope global kube-ipvs0 valid_lft forever preferred_lft forever inet 10.96.0.10/32 scope global kube-ipvs0 valid_lft forever preferred_lft forever每个Service IP都绑定在这个接口上，尽管接口状态是DOWN，但这不影响ipvs的功能。
3.2 使用ipvsadm查看规则
ipvs的核心功能可以通过ipvsadm命令查看：
minikube ssh -- sudo ipvsadm -ln输出示例：
IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.96.0.1:80 rr -> 10.244.0.5:80 Masq 1 0 0 -> 10.244.0.6:80 Masq 1 0 0 -> 10.244.0.7:80 Masq 1 0 0关键信息：
rr表示使用轮询(round-robin)调度算法- 三个后端Pod被列为真实服务器(Real Server)
Masq表示使用IP伪装(MASQUERADE)，即SNAT
3.3 ipvs如何与iptables协同工作
虽然ipvs接管了主要的负载均衡工作，但iptables仍然在以下方面发挥作用：
- 包过滤：实现网络策略和基本防火墙功能
- SNAT处理：为来自Pod的流量做源地址转换
查看相关的iptables规则：
minikube ssh -- sudo iptables-save | grep -i KUBE-MARK-MASQ你会看到类似这样的规则：
-A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE这条规则为所有被打上0x4000标记的流量执行MASQUERADE（SNAT）。
4. 实战：追踪一个请求的完整旅程
现在让我们实际追踪一个请求从Service到Pod的完整路径。我们将使用tcpdump和kubectl的端口转发功能。
4.1 在Pod中启动tcpdump
选择一个Pod并在其中启动tcpdump：
# 获取Pod列表 kubectl get pods -o wide # 在其中一个Pod中启动tcpdump kubectl exec -it nginx-deployment-xxxx -- tcpdump -i eth0 port 804.2 从外部发起请求
在另一个终端中，使用kubectl port-forward将Service端口映射到本地：
kubectl port-forward service/nginx-service 8080:80然后在第三个终端中访问这个服务：
curl http://localhost:80804.3 分析流量路径
观察tcpdump的输出，你会看到类似这样的记录：
10.244.0.1.60312 > 10.244.0.5.80: Flags [S], seq 123456789, win 64860, options [mss 1412,sackOK,TS val 987654321 ecr 0,nop,wscale 7], length 0关键点：
- 源IP是
10.244.0.1（通常是节点的IP） - 目标IP是Pod的实际IP
- 这表明DNAT已经成功将Service IP转换为Pod IP
5. 性能优化与模式选择建议
在实际生产环境中，选择iptables还是ipvs模式需要考虑多个因素：
| 考虑因素 | iptables模式 | ipvs模式 |
|---|---|---|
| 小规模集群 | 简单可靠，兼容性好 | 优势不明显 |
| 大规模集群 | 规则数量多，性能下降明显 | 规则数量对性能影响小 |
| 网络策略 | 与NetworkPolicy集成更好 | 需要额外iptables规则配合 |
| 负载均衡算法 | 仅支持随机和轮询 | 支持多种算法(rr,lc,sh,dh等) |
| 调试复杂度 | 规则直观但数量多 | 规则简洁但需要结合ipvsadm和iptables |
个人经验分享：在管理一个约500节点的生产集群时，我们从iptables切换到ipvs后，kube-proxy的CPU使用率下降了约40%，特别是在Service数量超过2000后，差异更加明显。不过要注意，ipvs模式需要内核支持，某些云主机的定制内核可能需要额外配置。