更新时间:2024-06-26 GMT+08:00
分享

iptables与IPVS如何选择

kube-proxy是Kubernetes集群的关键组件,负责Service和其后端容器Pod之间进行负载均衡转发。

CCE当前支持iptablesIPVS两种服务转发模式,各有优缺点。

特性差异

iptables

IPVS

定位

成熟稳定的kube-proxy代理模式,但性能一般,适用于Service数量较少(小于3000)或客户端会出现大量并发短连接的场景。更多说明请参见iptables简介

高性能的kube-proxy代理模式,适用于集群规模较大或Service数量较多的场景。更多说明请参见IPVS简介

吞吐量

较小

较大

复杂度

O(n) ,其中n随集群中服务和后端Pod的数量同步增长

O(1),多数情况下IPVS的连接处理效率和集群规模无关

负载均衡算法

随机平等的选择算法

包含多种不同的负载均衡算法,例如轮询、最短期望延迟、最少连接以及各种哈希方法等

ClusterIP连通性

集群内部ClusterIP地址无法ping通

集群内部ClusterIP地址可以正常ping通

说明:

由于社区安全加固,v1.27及以上版本的集群中ClusterIP地址无法ping通。

额外限制

当集群中超过3000个Service时,可能会出现网络延迟的情况。

  • Ingress和Service使用相同ELB实例时,无法在集群内的节点和容器中访问Ingress,因为kube-proxy会在ipvs-0的网桥上挂载LB类型的Service地址,Ingress对接的ELB的流量会被ipvs-0网桥劫持。建议Ingress和Service使用不同ELB实例。
  • 不推荐使用EulerOS 2.5、CentOS 7.6、Ubuntu 18.04的操作系统,详情请参见CCE集群IPVS转发模式下conn_reuse_mode问题说明

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代理模式

IPVS简介

IPVS(IP Virtual Server)是在Netfilter上层构建的,并作为Linux内核的一部分,实现传输层负载均衡。IPVS可以将基于TCP和UDP服务的请求定向到真实服务器,并使真实服务器的服务在单个IP地址上显示为虚拟服务。

IPVS模式下,kube-proxy使用IPVS负载均衡代替了iptables。这种模式同样有效,IPVS的设计就是用来为大量服务进行负载均衡的,它有一套优化过的API,使用优化的查找算法,而不是简单的从列表中查找规则。详情请参见IPVS代理模式

相关文档