# nftables、iptables与IPVS如何选择 kube-proxy是Kubernetes集群的关键组件，负责Service和其后端容器Pod之间进行负载均衡转发。 CCE当前支持nftables（1.35及以上版本）、iptables和IPVS的服务转发模式，各有优缺点。 | 特性差异 | nftables | iptables | IPVS | |:---|:---|:---|:---| | 定位 | 新一代高效灵活的kube-proxy代理模式，解决iptables性能瓶颈与扩展难题，适配大规模服务场景，提供统一配置框架整合多协议规则管理。详情请参见[nftables简介]。 | 成熟稳定的kube-proxy代理模式，但性能一般，适用于Service数量较少（小于3000）或客户端会出现大量并发短连接的场景。更多说明请参见[iptables简介]。 | 高性能的kube-proxy代理模式，适用于集群规模较大或Service数量较多的场景。更多说明请参见[IPVS简介]。 | | 吞吐量 | 较大 | 较小 | 较大 | | 复杂度 | O(1) 或 O(log n)，多数情况下nftables的规则处理效率和集群规模无关 | O(n) ，其中n随集群中服务和后端Pod的数量同步增长 | O(1)，多数情况下IPVS的连接处理效率和集群规模无关 | | 负载均衡算法 | 随机平等的选择算法 | 随机平等的选择算法 | 包含多种不同的负载均衡算法，例如轮询、最短期望延迟、最少连接以及各种哈希方法等 | | ClusterIP连通性 | 集群内部ClusterIP地址无法ping通 | 集群内部ClusterIP地址无法ping通 | 集群内部ClusterIP地址可以正常ping通 说明： 由于[社区安全加固](https://github.com/kubernetes/kubernetes/pull/108460)，v1.27及以上版本的集群中ClusterIP地址无法ping通。 | | 额外限制 | 在CCE集群v1.35及以上版本支持 | 当集群中超过3000个Service时，可能会出现网络延迟的情况。 | - 针对**服务转发模式为IPVS** 的集群，kube-proxy会在ipvs-0的网桥上挂载Service关联使用的ELB IP地址，集群内访问ELB的流量会被ipvs-0网桥劫持。因此存在以下集群内访问ELB异常的场景： - ELB Ingress和Service关联使用相同的ELB实例，集群内访问Ingress时会被ipvs-0网桥劫持到Service地址，导致无法访问。 - 本集群的Service和其他集群的Service关联使用相同的ELB实例，集群内访问其他集群的Service时会被ipvs-0网桥劫持到本集群内的Service地址，导致无法访问。 - Service配置"区间端口监听"时（例如端口范围为30000-30005），集群内访问仅支持spec.ports中配置的port端口（30000），其余端口（30001-30005）会因为ipvs-0网桥劫持访问失败。 您可以通过[为负载均衡类型的Service配置pass-through能力](https://support.huaweicloud.com/usermanual-cce/cce_10_0355.html)，这样在集群内部访问Service的ELB地址时可以不经过kube-proxy转发，从而避免该场景异常。 - 不推荐使用EulerOS 2.5、CentOS 7.6、Ubuntu 18.04的操作系统，详情请参见[CCE集群IPVS转发模式下conn_reuse_mode问题说明](https://support.huaweicloud.com/cce_faq/cce_faq_00409.html)。 | #### nftables简介 nftables是Linux内核内置的新一代数据包过滤与管理框架，旨在替代传统iptables，解决其性能瓶颈与扩展难题，提供更高效、灵活的网络流量管控能力。它基于Netfilter Hook机制构建，采用统一的配置框架，可整合IPv4、IPv6、ARP等多种协议的规则管理，无需为不同协议单独配置，同时通过哈希表等优化数据结构提升规则匹配效率，适配高并发场景。 nftables模式下，kube-proxy使用nftables替代iptables配置数据包转发与NAT规则。与iptables模式相比，nftables模式具备更简洁的语法、更灵活的规则组织方式，可动态更新规则且无需替换整个规则集，能有效优化大规模服务场景下的规则管理性能，更好地适配Kubernetes集群的扩展需求。详情请参见[nftables代理模式](https://kubernetes.io/zh-cn/docs/reference/networking/virtual-ips/#proxy-mode-nftables)。 ![](https://support.huaweicloud.com/usermanual-cce/public_sys-resources/note_3.0-zh-cn.png) kube-proxy使用nftables转发模式，需要节点操作系统内核版本\>=5.13，nft版本\>=1.01。 #### iptables简介 iptables是一个Linux内核功能，提供了大量的数据包处理和过滤方面的能力。它可以在核心数据包处理管线上用Hook挂接一系列的规则。iptables模式中kube-proxy 在NAT pre-routing Hook中实现NAT和负载均衡功能。对于每个Service，kube-proxy都会添加一个iptables规则，这些规则捕获流向Service的ClusterIP和Port的流量，并将这些流量重定向到Service后端的其中之一。默认情况下，iptables模式下的kube-proxy会随机选择一个Service后端。详情请参见[iptables代理模式](https://kubernetes.io/zh-cn/docs/reference/networking/virtual-ips/#proxy-mode-iptables)。 #### IPVS简介 IPVS（IP Virtual Server）是在Netfilter上层构建的，并作为Linux内核的一部分，实现传输层负载均衡。IPVS可以将基于TCP和UDP服务的请求定向到真实服务器，并使真实服务器的服务在单个IP地址上显示为虚拟服务。 IPVS模式下，kube-proxy使用IPVS负载均衡代替了iptables。这种模式同样有效，IPVS的设计就是用来为大量服务进行负载均衡的，它有一套优化过的API，使用优化的查找算法，而不是简单的从列表中查找规则。详情请参见[IPVS代理模式](https://kubernetes.io/zh-cn/docs/reference/networking/virtual-ips/#proxy-mode-ipvs)。 #### 相关文档 - 如果需要创建Service，请参见[服务概述](https://support.huaweicloud.com/usermanual-cce/cce_10_0249.html)。 - 若节点内核版本＜5.9时，CCE集群在IPVS模式下通过Service访问内部服务，偶发1秒延时或后端升级后访问失败，具体解决方案请参考[CCE集群IPVS转发模式下conn_reuse_mode问题说明](https://support.huaweicloud.com/cce_faq/cce_faq_00409.html)。 - 在集群使用IPVS转发的场景下，节点上升级CoreDNS后，可能出现概率性丢包，导致域名解析失败，具体解决方案请参见[IPVS缺陷导致节点上升级CoreDNS后出现概率性解析超时](https://support.huaweicloud.com/cce_faq/cce_faq_00427.html)。