kube-proxy代理模式详解

news2024/11/13 8:56:56

kube-proxy代理模式详解

kube-proxy当前支持以下几种代理模式：

1、userspace：最早的负载均衡方案，它在用户空间监听一个端口，所有服务通过iptables转发到这个端口，然后在其内部负载均衡到实际的Pod。该方式最主要的问题是效率低，有明显的性能瓶颈，不再推荐使用。

比如说创建一个service,对应的IP：1.2.3.4,port:8888，kube-proxy随机选择的端口是32890，则会在iptables中追加

-A PREROUTING -j KUBE-PORTALS-CONTAINER
 
-A KUBE-PORTALS-CONTAINER -d 1.2.3.4/32 -p tcp --dport 8888 -j REDIRECT --to-ports 32890

KUBE-PORTALS-CONTAINER 是kube-proxy在iptable中创建的规则链，在PREROUTING阶段执行

执行过程：

当有请求访问service时，在PREROUTING阶段，将请求jumpKUBE-PORTALS-CONTAINER；
KUBE-PORTALS-CONTAINER中的这条记录起作用,把请求重定向到kube-proxy刚监听的端口32890上，数据包进入kube-proxy进程内；
然后kube-proxy会从这个service对应的endpoint中根据SessionAffinity来选择一个作为真实服务响应请求。

2、iptables：目前推荐的方案，完全以 iptables 规则的方式来实现 service 负载均衡。该方式最主要的问题是在服务多的时候产生太多的 iptables 规则，非增量式更新会引入一定的时延，大规模情况下有明显的性能问题。

比如说创建了一个service，对应的IP：1.2.3.4,port:8888，对应一个后端地址：10.1.0.8:8080，则会在iptables中追加（主要规则）：

 -A PREROUTING -j KUBE-SERVICES
 
-A KUBE-SERVICES -d 1.2.3.4/32 -p tcp –dport 8888 -j KUBE-SVC-XXXXXXXXXXXXXXXX
 
-A KUBE-SVC-XXXXXXXXXXXXXXXX -j KUBE-SEP-XXXXXXXXXXXXXXXX
 
-A KUBE-SEP-XXXXXXXXXXXXXXXX -p tcp -j DNAT –to-destination 10.1.0.8:8080

KUBE-SERVICES 是kube-proxy在iptable中创建的规则链，在PREROUTING阶段执行

执行过程：

当请求访问service时，iptables在prerouting阶段，将讲求jump到KUBE-SERVICES；
在KUBE-SERVICES 中匹配到上面的第一条准则，继续jump到KUBE-SVC-XXXXXXXXXXXXXXXX；
根据这条准则jump到KUBE-SEP-XXXXXXXXXXXXXXXX；
在KUBE-SEP-XXXXXXXXXXXXXXXX规则中经过DNAT动做，访问真正的pod地址10.1.0.8:8080。

3、ipvs：为解决iptables模式的性能问题，v1.11新增了ipvs模式（v1.8开始支持测试版，并在v1.11 GA），采用增量式更新，并可以保证service更新期间连接保持不断开。

在IPVS模式下，kube-proxy观察Kubernetes中service和endpoint对象的变化，通过调用netlink接口创建相应的IPVS规则，并周期性的对Kubernetes的service、endpoint和IPVS规则进行同步，当访问一个service时，IPVS负责选择一个真实的后端提供服务。

IPVS模式也是基于netfilter的hook功能(INPUT阶段)，这点和iptables模式是一样的，但是用的是内核工作空间的hash表作为存储的数据结构，在这种模式下，iptables可通过ipset来验证具体请求是否满足某条规则。在service变成时，只用更新ipset中的记录，不用改变iptables的规则链，因此可以保证iptables中的规则不会随着服务的增加变多，在超大规模服务集群的情况下提供一致的性能效果。

在对规则进行同步时的性能也要高于iptables（只用对特定的一个hash表进行更新，而不是像iptables模式下对整个规则表进行操作），所以能提供更高的网络流量。

IPVS在对后端服务的选择上也提供了更多灵活的算法：