kube-proxy代理模式详解

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来选择一个作为真实服务响应请求。
    kube-proxy代理模式详解_第1张图片

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。
    kube-proxy代理模式详解_第2张图片

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在对后端服务的选择上也提供了更多灵活的算法:

  • rr: round-robin(轮询算法)
  • lc: least connection (最小连接数算法)
  • dh: destination hashing(目的地址hash算法)
  • sh: source hashing(原地址hash算法)
  • sed: shortest expected delay(最短期望延时算法)
  • nq: never queue(永不排队算法)
    kube-proxy代理模式详解_第3张图片

4、winuserspace:同userspace,但仅工作在Windows 节点上。

今天的分享就到此结束了

欢迎点赞评论互关三连

在这里插入图片描述

你可能感兴趣的:(运维,系统安全,kubernetes,负载均衡,云原生,运维)