RKE2 集群 ipvs 模式下 iptables 是否仍然被使用？原理详解

目标读者：RKE2/Kubernetes 运维、SRE、网络工程师
前置知识：kube-proxy 工作模式、iptables、ipvs 基础
文档版本：v1.0

一句话结论

会。即使在 RKE2 集群中显式指定 kube-proxy 使用 ipvs 模式，iptables 仍然会被大量使用。

ipvs 主要负责 Service 的负载均衡和 DNAT，但 iptables 仍然承担：

NodePort 的初步匹配
SNAT/MASQUERADE
访问控制与隔离
标记与辅助处理
CNI 插件（如 Calico）的网络策略

第1章 RKE2 中如何启用 ipvs 模式

1.1 RKE2 默认 kube-proxy 模式

RKE2 默认使用 iptables 模式，除非显式配置。

1.2 通过 kube-proxy ConfigMap 启用 ipvs

bash

kubectl edit configmap kube-proxy -n kube-system

修改配置：

yaml

apiVersion: v1
data:
  config.conf: |-
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    mode: "ipvs"
    ipvs:
      scheduler: rr
      minSyncPeriod: 0s
      syncPeriod: 30s
      tcpTimeout: 0s
      tcpFinTimeout: 0s
      udpTimeout: 0s

1.3 RKE2 启动参数方式

在 /etc/rancher/rke2/config.yaml 中：

yaml

kube-proxy-arg:
  - "proxy-mode=ipvs"
  - "ipvs-scheduler=rr"

重启 RKE2：

bash

systemctl restart rke2-server

1.4 确认 ipvs 模式已启用

bash

# 查看 kube-proxy 日志
kubectl logs -n kube-system -l k8s-app=kube-proxy | grep -i ipvs

# 查看 ipvs 规则
ipvsadm -Ln

# 查看节点内核模块
lsmod | grep ip_vs

第2章 ipvs 模式≠完全替代 iptables

2.1 官方定义

Kubernetes 文档明确说明：

In ipvs mode, kube-proxy programs Linux IPVS to create virtual servers for each Service. iptables is still used for NodePort and for packets that are not handled by IPVS.

即：ipvs 模式下，iptables 仍然用于 NodePort 以及不被 IPVS 处理的包。

2.2 为什么 ipvs 不能独立完成所有工作

ipvs 是一个四层负载均衡器，它的核心能力：

匹配虚拟服务器（Virtual Server）
选择真实服务器（Real Server）
做 DNAT/SNAT

但它不是完整的包过滤和路由框架，无法替代 Netfilter 的全部功能。

第3章 ipvs 模式下 iptables 仍然存在的五条核心原因

3.1 原因一：NodePort 由 iptables 初步匹配

ipvs 本身监听在具体的 IP:Port 上（如 ClusterIP:port）。但 NodePort 需要在每个节点的某个端口上接收流量，并将其导入 ipvs。

外部客户端
    │
    │ 访问 <NodeIP>:30080
    ▼
节点 eth0:30080
    │
    ▼
iptables PREROUTING / KUBE-NODEPORTS
    │
    ▼
ipvs virtual server (192.168.1.10:30080)
    │
    ▼
Real Server (Pod:targetPort)

iptables 规则示例：

bash

iptables -t nat -L KUBE-NODEPORTS -n -v

Chain KUBE-NODEPORTS (1 references)
 target     prot opt source    destination
KUBE-SVC-XXX  tcp  --  0.0.0.0/0  0.0.0.0/0    tcp dpt:30080

3.2 原因二：SNAT/MASQUERADE 由 iptables 处理

ipvs 默认使用 Masq 转发模式，但 MASQUERADE 动作本身由 iptables 的 nat 表完成。

Pod 访问 Service
    │
    ▼
ipvs 做 DNAT 到 Real Server
    │
    ▼
iptables POSTROUTING 做 SNAT/MASQUERADE
    │
    ▼
Pod 收到请求并回复

iptables 规则示例：

bash

iptables -t nat -L KUBE-POSTROUTING -n -v

Chain KUBE-POSTROUTING (1 references)
 target          prot opt source         destination
MASQUERADE  all  --  0.0.0.0/0   0.0.0.0/0    /* kubernetes service traffic requiring SNAT */

3.3 原因三：访问控制与隔离仍依赖 iptables

ipvs 只负责负载均衡，不负责：

默认 DROP/ACCEPT 策略
节点防火墙
CNI 网络策略（NetworkPolicy）

Calico、Cilium 等 CNI 插件大量使用 iptables/eBPF 实现策略。

3.4 原因四：ipvs 需要 iptables 做辅助标记

在某些场景下，kube-proxy 需要用 iptables 做标记（MARK）来辅助 ipvs 决策。

例如：

bash

iptables -t mangle -L KUBE-IPVS-OUT -n -v

3.5 原因五：CNI 插件大量依赖 iptables

无论 kube-proxy 使用 iptables 还是 ipvs，CNI 插件都会创建自己的 iptables 规则：

CNI	iptables 用途
Calico	NetworkPolicy、NAT、标记
Flannel	转发、MASQUERADE
Cilium	eBPF 为主，但仍保留部分 iptables 兼容
Canal	Calico + Flannel 规则

第4章数据包在 ipvs 模式下的完整流转

4.1 ClusterIP 访问

Pod A
    │
    │ 目的：10.96.123.45:80
    ▼
Pod A 所在节点内核
    │
    ▼
OUTPUT / PREROUTING
    │
    ▼
iptables KUBE-SERVICES
    │
    ▼
ipvs virtual server: 10.96.123.45:80
    │
    │ 根据调度算法选择 real server
    ▼
ipvs real server: 10.244.1.10:8080
    │
    ▼
POSTROUTING（可能 SNAT）
    │
    ▼
CNI 网络转发到 Pod B

4.2 NodePort 访问

外部客户端
    │
    │ 目的：<NodeIP>:30080
    ▼
节点网卡
    │
    ▼
PREROUTING
    │
    ▼
iptables KUBE-NODEPORTS
    │
    ▼
ipvs virtual server: <NodeIP>:30080
    │
    ▼
ipvs real server: 10.244.1.10:8080
    │
    ▼
POSTROUTING
    │
    ▼
Pod B

4.3 返回路径

Pod B 回复
    │
    │ 源：10.244.1.10:8080
    │ 目的：Pod A IP:random-port
    ▼
conntrack/ipvs 反向转换
    │
    ▼
源：10.96.123.45:80
    │
    ▼
Pod A

第5章 RKE2 + ipvs 模式下 iptables 规则观察

5.1 查看 ipvs 规则

bash

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.123.45:80 rr
  -> 10.244.1.10:8080             Masq    1      0          0
  -> 10.244.1.11:8080             Masq    1      0          0
TCP  192.168.1.10:30080 rr
  -> 10.244.1.10:8080             Masq    1      0          0
  -> 10.244.1.11:8080             Masq    1      0          0

5.2 查看 iptables 规则

bash

# nat 表
iptables -t nat -L -n -v | grep KUBE

# filter 表
iptables -L -n -v | grep KUBE

# mangle 表
iptables -t mangle -L -n -v | grep KUBE

你会看到：

Chain KUBE-SERVICES
Chain KUBE-NODEPORTS
Chain KUBE-POSTROUTING
Chain KUBE-FORWARD
Chain KUBE-IPVS-OUT
Chain KUBE-IPVS-FW

5.3 关键发现

即使在 ipvs 模式下，以下 iptables 链仍然存在：

KUBE-SERVICES：匹配 ClusterIP，将流量导入 ipvs
KUBE-NODEPORTS：匹配 NodePort
KUBE-POSTROUTING：做 SNAT/MASQUERADE
KUBE-FORWARD：转发相关规则
KUBE-IPVS-OUT / KUBE-IPVS-FW：ipvs 辅助链

第6章 ipvs 与 iptables 的职责边界

职责	ipvs	iptables
ClusterIP 负载均衡	✅ 主力	✅ 辅助导入
NodePort 初步匹配	❌	✅ 主力
DNAT 到 Pod	✅ 主力	❌
SNAT/MASQUERADE	❌	✅ 主力
包过滤 / 默认策略	❌	✅ 主力
NetworkPolicy	❌	✅ CNI 实现
conntrack 状态匹配	❌	✅ 主力
连接建立后的返回包	✅ 维护连接状态	✅ 辅助

第7章常见误解与澄清

误解一：启用 ipvs 后 iptables 规则会变少

事实：ipvs 模式下 iptables 规则数量与 iptables 模式相当，甚至在某些场景更多（因为既有 ipvs 辅助链，又有 CNI 规则）。

误解二：ipvs 模式性能更好是因为完全绕过了 iptables

事实：ipvs 性能好是因为：

负载均衡由内核态 IPVS 直接完成
规则结构是 virtual server + real server，不随后端数量线性膨胀
但 SNAT、NodePort 匹配等仍走 iptables

误解三：RKE2 中使用 ipvs 就不需要关心 iptables 了

事实：生产中 iptables 仍然是排障重点，尤其是：

NodePort 不通
源 IP 丢失（MASQUERADE 问题）
NetworkPolicy 拦截
conntrack 表满

误解四：ipvs 模式下所有 Service 流量都走 ipvs

事实：某些特殊流量（如 LoadBalancer health check、NodePort 未启用时）可能仍由 iptables 处理。

第8章性能与排障建议

8.1 RKE2 + ipvs 启用条件

bash

# 加载 ipvs 内核模块
modprobe ip_vs
modprobe ip_vs_rr
modprobe ip_vs_wrr
modprobe ip_vs_lc
modprobe nf_conntrack

# 确认模块
lsmod | grep ip_vs

8.2 推荐配置

yaml

# /etc/rancher/rke2/config.yaml
kube-proxy-arg:
  - "proxy-mode=ipvs"
  - "ipvs-scheduler=rr"
  - "ipvs-min-sync-period=5s"
  - "ipvs-sync-period=30s"

8.3 排障命令

bash

# 1. 确认 kube-proxy 模式
kubectl logs -n kube-system -l k8s-app=kube-proxy | grep -i "Using ipvs"

# 2. 查看 ipvs 虚拟服务
ipvsadm -Ln

# 3. 查看 ipvs 连接状态
ipvsadm -Lnc

# 4. 查看 iptables 中 kube-proxy 规则
iptables -t nat -L KUBE-SERVICES -n -v
iptables -t nat -L KUBE-NODEPORTS -n -v
iptables -t nat -L KUBE-POSTROUTING -n -v

# 5. 查看 conntrack
conntrack -L | grep <cluster-ip>

# 6. 抓包
tcpdump -i any -nn host <cluster-ip> or port <node-port>

8.4 常见问题

问题	原因	排查
ipvs 模式未生效	内核模块未加载	`lsmod \| grep ip_vs`
NodePort 不通	iptables KUBE-NODEPORTS 规则缺失	检查 kube-proxy
源 IP 丢失	MASQUERADE 规则 + externalTrafficPolicy=Cluster	改为 Local
Service 访问延迟高	ipvs 调度算法不合适	调整 scheduler
规则不同步	ipvs sync 周期问题	调整 sync 参数

第9章总结

核心观点

RKE2 中启用 ipvs 模式后，iptables 仍然大量使用。
ipvs 主要替代的是 ClusterIP 的负载均衡和 DNAT 部分。
iptables 仍然负责 NodePort 匹配、SNAT/MASQUERADE、包过滤、NetworkPolicy、辅助 ipvs。
CNI 插件（尤其是 Calico）会继续创建大量 iptables 规则。
生产排障时，需要同时关注 ipvsadm 和 iptables。

选择建议

场景	推荐模式
小规模集群、简单场景	iptables
大规模集群、大量 Service/Pod	ipvs
对延迟敏感、长连接多	ipvs
需要丰富调度算法	ipvs
老旧内核、模块加载困难	iptables

最终结论

ipvs 和 iptables 不是互斥关系，而是协作关系。 在 RKE2 中启用 ipvs 只是将 Service 负载均衡的核心工作交给 ipvs，但 iptables 仍然是 Kubernetes 网络不可或缺的基础设施。

文档生成时间：2026-07-18

RKE2 集群 ipvs 模式下 iptables 是否仍然被使用？原理详解 ​

一句话结论 ​

目录 ​

第1章 RKE2 中如何启用 ipvs 模式 ​

1.1 RKE2 默认 kube-proxy 模式 ​

1.2 通过 kube-proxy ConfigMap 启用 ipvs ​

1.3 RKE2 启动参数方式 ​

1.4 确认 ipvs 模式已启用 ​

第2章 ipvs 模式≠完全替代 iptables ​

2.1 官方定义 ​

2.2 为什么 ipvs 不能独立完成所有工作 ​

第3章 ipvs 模式下 iptables 仍然存在的五条核心原因 ​

3.1 原因一：NodePort 由 iptables 初步匹配 ​

3.2 原因二：SNAT/MASQUERADE 由 iptables 处理 ​

3.3 原因三：访问控制与隔离仍依赖 iptables ​

3.4 原因四：ipvs 需要 iptables 做辅助标记 ​

3.5 原因五：CNI 插件大量依赖 iptables ​

第4章 数据包在 ipvs 模式下的完整流转 ​

4.1 ClusterIP 访问 ​

4.2 NodePort 访问 ​

4.3 返回路径 ​

第5章 RKE2 + ipvs 模式下 iptables 规则观察 ​

5.1 查看 ipvs 规则 ​

5.2 查看 iptables 规则 ​

5.3 关键发现 ​

第6章 ipvs 与 iptables 的职责边界 ​

第7章 常见误解与澄清 ​

误解一：启用 ipvs 后 iptables 规则会变少 ​

误解二：ipvs 模式性能更好是因为完全绕过了 iptables ​

误解三：RKE2 中使用 ipvs 就不需要关心 iptables 了 ​

误解四：ipvs 模式下所有 Service 流量都走 ipvs ​

第8章 性能与排障建议 ​

8.1 RKE2 + ipvs 启用条件 ​

8.2 推荐配置 ​

8.3 排障命令 ​

8.4 常见问题 ​

第9章 总结 ​

核心观点 ​

选择建议 ​

最终结论 ​

RKE2 集群 ipvs 模式下 iptables 是否仍然被使用？原理详解

一句话结论

目录

第1章 RKE2 中如何启用 ipvs 模式

1.1 RKE2 默认 kube-proxy 模式

1.2 通过 kube-proxy ConfigMap 启用 ipvs

1.3 RKE2 启动参数方式

1.4 确认 ipvs 模式已启用

第2章 ipvs 模式≠完全替代 iptables

2.1 官方定义

2.2 为什么 ipvs 不能独立完成所有工作

第3章 ipvs 模式下 iptables 仍然存在的五条核心原因

3.1 原因一：NodePort 由 iptables 初步匹配

3.2 原因二：SNAT/MASQUERADE 由 iptables 处理

3.3 原因三：访问控制与隔离仍依赖 iptables

3.4 原因四：ipvs 需要 iptables 做辅助标记

3.5 原因五：CNI 插件大量依赖 iptables

第4章数据包在 ipvs 模式下的完整流转

4.1 ClusterIP 访问

4.2 NodePort 访问

4.3 返回路径

第5章 RKE2 + ipvs 模式下 iptables 规则观察

5.1 查看 ipvs 规则

5.2 查看 iptables 规则

5.3 关键发现

第6章 ipvs 与 iptables 的职责边界

第7章常见误解与澄清

误解一：启用 ipvs 后 iptables 规则会变少

误解二：ipvs 模式性能更好是因为完全绕过了 iptables

误解三：RKE2 中使用 ipvs 就不需要关心 iptables 了

误解四：ipvs 模式下所有 Service 流量都走 ipvs

第8章性能与排障建议

8.1 RKE2 + ipvs 启用条件

8.2 推荐配置

8.3 排障命令

8.4 常见问题

第9章总结

核心观点

选择建议

最终结论