问题现象
在已安装 NetworkPolicy 扩展组件（kube-router）的集群中，部分节点可能出现以下问题：
iptables 规则暴涨：节点 filter 表规则数达到数万甚至数十万条，kube-router Pod 的 CPU 使用率升高至数百 m 甚至 1 Core 以上。
端口不通：SSH（22）、kubelet（10250）等关键端口不可达，导致节点 NotReady。
其他组件规则累积：nodelocaldns 等共享 filter 表的组件规则反复追加，DNS 解析受影响。
根因分析
该问题由 kube-router 与 filter 表上其他组件（如 kube-proxy、nodelocaldns 等）之间的 iptables-nft 版本跨 v1.8.8 边界不兼容导致。
Linux iptables 存在两种后端实现：
legacy：传统的 iptables 工具，直接操作内核 iptables 模块。
nf_tables：新一代后端，通过 nftables 内核子系统实现规则管理。
netfilter 社区在 iptables-nft v1.8.8 中改变了
--dport/--sport/--mark 等匹配项的内部表达式格式。低于 v1.8.8 的 iptables-save 在读取高版本组件（如 kube-proxy v1.8.9）写入的规则时，这些参数会静默丢失。kube-router 使用全表
iptables-save/iptables-restore 同步 filter 表规则。一旦低版本的 iptables-save 丢失参数后，restore 将变形规则写回内核，导致 filter 表上所有组件（kube-proxy、nodelocaldns 等）写入的规则被破坏：规则判重失效 → 规则反复追加 → iptables 规则暴涨
REJECT 规则的
--dport 丢失 → 阻断所有 TCP 端口 → 节点不可达kube-router 各版本的 iptables 行为
组件版本 | kube-router 镜像 | iptables 策略 | 风险 |
≤ 1.0.3 | v1.3.2 / v1.3.3 | 固定 v1.8.7，不支持自适应 | v1.8.7 < v1.8.8，在所有 nf_tables 后端节点上均存在跨版本兼容性风险。 |
1.0.4 | v1.3.4 | 自适应 | 在 iptables 版本较高的节点（如 TencentOS Server 4.4）选到 v1.8.9，不受影响；在 iptables 版本较低的节点（如 TencentOS Server 3.1）可能选到低于 v1.8.8 的版本，仍有风险。 |
1.0.5 | v1.3.6 | 固定 v1.8.9 + 后端自适应 | 无风险，从根本上消除兼容性问题。 |
kube-router v1.3.4（对应 networkpolicy 组件版本 1.0.4）通过容器内置 wrapper 自适应 选择 iptables 版本和后端。在 iptables 版本较高的节点（如 TencentOS Server 4.4 自带 v1.8.9 legacy）上 wrapper 选到 v1.8.9，不受影响；但在 iptables 版本较低的节点（如 TencentOS Server 3.1 自带 v1.8.5 nft）上，wrapper 可能选到低于 v1.8.8 的 iptables 版本（v1.8.4 或 v1.8.7），仍有 nft 跨版本兼容性风险。
kube-router v1.3.6（对应 networkpolicy 组件版本 1.0.5）固定 iptables 版本为 v1.8.9，后端仍然自适应。nft 参数丢失是单向的——只有低版本读高版本会丢，高版本读低版本不会丢。固定到当前最高版本 v1.8.9 后，无论 filter 表上其他组件用什么版本，kube-router 都能完整读取其规则，从根本上消除了兼容性问题。
影响范围
以下节点操作系统因使用 nf_tables 后端且 iptables 版本较低，在运行 v1.3.4 及更早版本的 kube-router 时存在较高风险。其中 v1.3.2/v1.3.3 固定使用 iptables v1.8.7（< v1.8.8），在所有 nf_tables 后端节点上均受影响；v1.3.4 通过自适应可能选到低于 v1.8.8 的 iptables 版本，在 iptables 版本较低的 OS 上仍存在风险：
操作系统 | iptables 版本 | iptables 后端 | 风险等级 |
TencentOS Server 3.1/3.2/3.3 | v1.8.5 | nf_tables | 高 |
CentOS 8.0 | nft-only | nf_tables | 高 |
Ubuntu 22.04 LTS | v1.8.7 | nf_tables | 高 |
Ubuntu 24.04 LTS | v1.8.10 | nf_tables | 中 |
RHEL 8.6 | v1.8.5 | nf_tables | 高 |
RHEL 9.5 | v1.8.10 | nf_tables | 中 |
Rocky Linux 9.3 | v1.8.8 | nf_tables | 中 |
Debian 11 / 12 | nft-only | nf_tables | 高 |
说明：
使用 legacy 后端的操作系统（如 TencentOS Server 2.4/4.4、CentOS 7.x、Ubuntu 16.04/18.04/20.04、RHEL 7.9、OpenCloudOS 9.4）因采用传统 iptables-legacy，不受 nft 跨版本兼容性问题影响。
解决方案
将 kube-router 镜像升级到 v1.3.6。该版本固定 iptables 为 v1.8.9，后端自适应，从根本上规避了 nft 跨版本兼容性问题。
当前扩展组件管理中暂不支持产品化升级 networkpolicy 组件，需通过以下方式手动升级：
步骤 1：修改 DaemonSet 镜像
镜像地址可能因集群所在地域不同而带有地域前缀（如
ccr.ccs.tencentyun.com 或 jpccr.ccs.tencentyun.com），建议先查看当前镜像地址再替换 tag：kubectl set image daemonset/networkpolicy -n kube-system \\networkpolicy=$(kubectl get daemonset networkpolicy -n kube-system -o jsonpath='{.spec.template.spec.containers[0].image}' | sed 's/:.*/:v1.3.6/')
或通过编辑 DaemonSet 修改：
kubectl edit daemonset networkpolicy -n kube-system
将
spec.template.spec.containers 中 image 字段的 tag 修改为 v1.3.6（仅修改冒号后的版本号，保留镜像仓库地址前缀不变）。步骤 2：验证升级结果
等待所有 networkpolicy Pod 滚动更新完成，确认 Pod 均已升级到 v1.3.6 版本：
kubectl get pods -n kube-system -l k8s-app=networkpolicy -o jsonpath='{range .items[*]}{.metadata.name}{"\\t"}{.spec.containers[0].image}{"\\n"}{end}'
预期输出中所有 Pod 的镜像 tag 均为
v1.3.6。
