资讯详情

kube-proxy 详解

在kubernets集群的每个节点都在运行kube-proxy过程负责实现Kubernetes中service组件的虚拟IP服务。目前kube-proxy有三种工作模式:

  • User space 模式
  • iptables 模式
  • IPVS 模式
  1. User space模式

    在这种模式下,kube-proxy通过观察Kubernetes中service和endpoint对象的变化,当有新的时候service创建时,所有节点kube-proxy在node在节点上随机选择端口iptables追加一个访问service请求重定向到此端口的记录,并开始监控端口的连接请求。

    例如,创建一个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  

    执行过程:

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

    这种模式的缺点是需要请求数据kube-proxy只有在用户空间中,才能确定要转发的实际服务地址,性能才会有损失。并且在应用执行过程中,kube-proxy也会影响系统的稳定性

  2. iptables 模式(目前kube-proxy默认工作模式)

    在这种模式下,kube-proxy通过观察Kubernetes中service和endpoint对象的变化,当有servcie创建时,kube-proxy在iptables添加新规则。对于service的每一个endpoint,会在iptables添加规则,设置动作作作为DNAT,将目的地址设置为真正提供服务pod地址;再为servcie增加规则,设置跳转到相应的动作endpoint的规则上,

    默认情况下,kube-proxy可以随机选择后端服务iptables中的 -m recent 模块实现session affinity功能,通过 -m statistic 负载平衡时模块的权重功能

    例如,创建了一个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  

    执行过程:

    • 当请求访问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如果你不工作,已经创建的服务仍然可以正常工作 。但在这种模式下,如果选择第一个pod如果你不能回应,请求就会失败,就像userspace模式,请求失败后kube-proxy还能对其他endpoint进行重试。

    这就需要我们的应用(pod)要提供readiness probes验证后端服务能否正常提供服务的功能,kube-proxy只会将readiness probes测试通过的pod写入到iptables为了避免将请求转发到异常的后端服务。

  3. IPVS 模式

    1. 介绍 由于在iptables模式中,kube-proxy每一个服务,每一个服务,每一个endpoint产生相应的iptables规则,当服务规模较大时,性能也会显著下降,因此kubernetes在1.8引入了IPVS模式,1.9版本中变成beta,在1.11版本中成为GA。

      在IPVS模式下,kube-proxy观察Kuernetes中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

由于IPVS的优势,所以尽可能的采用IPVS作为kube-proxy的工作模式,通过以下步骤在创建集群时启用IPVS

  1. 安装依赖工具包

    apt install -y ipvsadm ipset
    
    
    • ipset是IPVS工作时会用刀的工具包
    • ipvsadm 是一个客户端工具,可以让我们和ipvs表的数据进行交互
  2. kube-proxy启用IPVS时依赖模块:

    ip_vs
    ip_vs_rr
    ip_vs_wrr
    ip_vs_sh
    nf_conntrack
    
    

    可通过如下命令检查系统是否启用了这些模块

    $ lsmod | grep -e ip_vs -e nf_conntrack
    
    

    如果没有启用,通过如下命令启用

    $ modprobe -- ip_vs
    $ modprobe -- ip_vs_rr
    $ modprobe -- ip_vs_wrr
    $ modprobe -- ip_vs_sh
    $ modprobe -- nf_conntrack
    
    
  3. kube-proxy配置文件中追加IPVS相关配置

    proxy-mode: "ipvs"
    ipvs-min-sync-period: ipvs 规则刷新的最小时间间隔
    ipvs-scheduler: ipvs的负载算法(rr、lc等)
    ipvs-sync-period: ipvs规则刷新的最大时间间隔(30s)
    
    

在介绍kube-proxy如何使用IPVS实现对service的请求前,先看下IPVS的简单介绍及工作原理

  1. 介绍 IPVS是Linux服务器中用来实现LVS(Linux virtual service)的一个模块,工作在内核空间是一种基于虚拟IP的负载均衡技术,通过用户空间的ipvsadm来执行规则制定,常见术语

    名称 解释
    RS Real Server 后端请求处理服务器
    CIP Client IP,客户端IP
    VIP Director Virtual IP,负载均衡器虚拟IP
    DIP Director IP,负载均衡器IP
    RIP Real Server IP,后端处理请求的真实服务器IP
  2. 工作原理

    1. 因为IPVS是hook到netfilter的input链中执行的,所以需要先了解下数据在netfilter中的流转过程

      正常流程:

      • 数据进入内核空间,到达PreRouting
      • 进行路由决策
      • 请求是发往本机的进入input
      • 进入用户空间处理
      • 处理完进入output
      • 进入postrouting
      • 发送出去
      • 请求不是本机的,进入forward
      • 进入postrouting
      • 发送出去
    2. 加入IPVS后的简化逻辑图

      • 请求到达负载均衡器的内核空间时,到达PREROUTING链
      • 当内核根据路由决策发现地址是本机时,将数据包送往INPUT链
      • 数据包到达INPUT链时,首先会被IPVS检查,如果请求的目的地址、端口信息不在自己的hash表中时,数据正常发往用户空间处理
      • 如果hash表中的规则匹配到请求记录,依据IPVS的工作模式,对请求头中的信息进行修改,之后直接交由POSTROUTING链执行
      • POSTROUTING根据IPVS修改后的请求头信息(此时目的地址是真实的服务地址),通过路由表,用正确的设备将请求转发出去

      可以看到,当IPVS模块工作后,在input链上会再次对请求做匹配,匹配到的直接做postrouting,不再进入用户空间处理,而是把请求发送到IPVS选中的提供真实服务的服务器

    3. IPVS有三种工作模式NAT(Masq)、DR、TUN,因为kube-proxy采用的是NAT模式,所以下面只对NAT模式进行分析

      NAT:Network Address Transition(网络地址转换),工作在此模式下的IPVS,首先根据scheduler策略选择一个真实的后端服务,接着将请求头中的目的地址IP、端口转换成真实服务的IP和端口,之后进入POSTROUTING,向真实的服务器发起请求。当响应数据返回时,再通过masqreade,将返回数据的源地址修改成虚拟服务器的地址,具有有如下特性:

      • Real Server应该使用私有ip地址,和client IP不在一个网段中(如果在一个网段中,real Server可以将数据直接返回客户端,不会再经过Director Server返回)

      • 一般Real Server的网关应该指向DIP,不然的话无法保证响应报文经过Director Server(IP 协议,数据发送给不在同一个网段的服务器时,会把数据发送给网关)

      • RIP要和DIP应该在同一网段内

      • 进出的报文,无论请求还是响应都要经过Directory server(满足上面三点,这个是自然而然的)

      • 支持端口映射

      • Real Server可以使用任意系统,只要端口对应即可

      其流程如下:

      • 当用户请求到达DirectorServer,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP 。

      • PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链。

      • IPVS比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP,然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP ,在这个过程完成了目标IP的转换。

      • POSTROUTING链通过选路,将数据包发送给Real Server。

      • Real Server比对发现目标为自己的IP,开始构建响应报文。 此时报文的源IP为RIP,目标IP为CIP 。

      • 因为Real Server的网关指向DIP,并且通常情况下CIP和RIP不在同一个网段内,在这种情况下,Real Server会先将数据发送给Director Server(网关),这样数据就可以沿原路返回。

      • Director Server在响应客户端前,此时会将源IP地址修改为自己的VIP地址,然后响应给客户端。 此时报文的源IP为VIP,目标IP为CIP。

      • 在此过程中CIP一直是不发生变化的

  1. 从IPVS的工作原理上可以知道,kube-proxy想使用IPVS,需要完成以下几个工作

    • 需要路由决策判断要访问的service的VIP属于本机,否则,数据不经过input,直接forward出去,IPVS就没有机会工作了
    • iptables中的规则需要允许对service请求通过,否则数据被过滤掉也不会经过IPVS
    • IPVS要能够判断出访问的service服务是属于集群服务
    • IPVS要能够根据service服务对应的VIP,找到真实的服务,之后修改请求头,向真实的服务发送请求
    • 由于在kubernetes下工作的IPVS,不一定满足经典的NAT模式的特性,所以数据返回路径不一定和请求路径一致,会出现Real Server直接返回数据给客户端的情况
  2. 为了让node节点识别对应的VIP,kube-proxy启动时创建了一个虚拟网络设备kube-ipvs0,类型是dummy,并把service的VIP都设置到这个设备下面。创建这个设备,以及向设备中追加VIP的逻辑都在代码proxier.go中

    $ ip addr 
    
    27: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
    link/ether ba:6b:cb:b9:61:89 brd ff:ff:ff:ff:ff:ff
    inet 10.254.0.1/32 brd 10.254.0.1 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.254.0.2/32 brd 10.254.0.2 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.254.199.160/32 brd 10.254.199.160 scope global kube-ipvs0
       valid_lft forever preferred_lft forever 
       
    

    对应的service

    $ kubectl get svc -A
    NAMESPACE     NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                  AGE
    default       clientip     ClusterIP   10.254.199.160   <none>        8080/TCP                 23h
    default       kubernetes   ClusterIP   10.254.0.1       <none>        443/TCP                  25d
    kube-system   kube-dns     ClusterIP   10.254.0.2       <none>        53/UDP,53/TCP,9153/TCP   23d
    kube-system   kubelet      ClusterIP   None             <none>        10250/TCP                18d
    
    

    可以看到所有的VIP都在kube-ipvs0这个设备下面

  3. 为了让iptables中的规则允许对Servcie的请求通过,kube-proxy在iptables中追加了如下几条主要规则(iptables.masqueradeAll=false;clusterCIDR=172.30.0.0/16,clusterCIDR就是集群中的pod能分配的IP地址段):

    1. NAT表中:

      $ iptables -t nat -nL
      
      Chain PREROUTING (policy ACCEPT)
      target     prot opt source               destination
      KUBE-SERVICES  all  -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes service portals */
      
      Chain OUTPUT (policy ACCEPT)
      target     prot opt source               destination
      KUBE-SERVICES  all  -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes service portals */
      
      Chain POSTROUTING (policy ACCEPT)
      target     prot opt source               destination
      KUBE-POSTROUTING  all  -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes postrouting rules */
      
      Chain KUBE-MARK-MASQ (3 references)
      target     prot opt source               destination
      MARK       all  -- 0.0.0.0/0 0.0.0.0/0 MARK or 0x4000
      
      Chain KUBE-POSTROUTING (1 references)
      target     prot opt source               destination
      MASQUERADE  all  -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes service traffic requiring SNAT */ mark match 0x4000/0x4000
      MASQUERADE  all  -- 0.0.0.0/0 0.0.0.0/0 match-set KUBE-LOOP-BACK dst,dst,src
      
      Chain KUBE-SERVICES (2 references)
      target     prot opt source               destination
      KUBE-MARK-MASQ  all  -- !172.30.0.0/16 0.0.0.0/0 match-set KUBE-CLUSTER-IP dst,dst
      ACCEPT     all  -- 0.0.0.0/0 0.0.0.0/0 match-set KUBE-CLUSTER-IP dst,dst
      
      

      有两点需要解释下

      1. 关于规则

        KUBE-MARK-MASQ  all  -- !172.30.0.0/16       0.0.0.0/0            match-set KUBE-CLUSTER-IP dst,dst
        
        

        意思是对于非集群内的pod访问集群的cluster IP时会执行masquerade,这是因为在kube-proxy的启动条件设置成了iptables.masqueradeAll=false;clusterCIDR=172.30.0.0/16才这样

        如果设置成iptables.masqueradeAll=false;clusterCIDR=,即不设置CIDR规则会变成

        KUBE-MARK-MASQ  all  --  0.0.0.0/0            0.0.0.0/0           match-set KUBE-CLUSTER-IP src,dst
        
        

        效果应该是对自己访问自己的请求做masquerade,其他请求都不做

        如果iptables.masqueradeAll=true,规则变成

        KUBE-MARK-MASQ  all  --  0.0.0.0/0            0.0.0.0/0            match-set KUBE-CLUSTER-IP dst,dst
        
        

        效果对所有请求都做masquerade

      2. 关于匹配语法 -m set --match-set 。。。 代表用set模块的对请求进行匹配

        语法如下:

         -m set --match-set name flags
         
        

        具体传入的flags要依据 name指定的set的类型来传入,具体ipset的用法可通过如下命令查看

        ipset --help
        
        

        这里以KUBE-CLUSTER-IP为例

        
        $ ipset --list KUBE-CLUSTER-IP
        Name: KUBE-CLUSTER-IP
        Type: hash:ip,port
        Revision: 5
        Header: family inet hashsize 1024 maxelem 65536
        Size in memory: 408
        References: 2
        Number of entries: 5
        Members:
        10.254.0.2,udp:53
        10.254.0.1,tcp:443
        10.254.0.2,tcp:9153
        10.254.199.160,tcp:8080
        10.254.0.2,tcp:53
        
        
        • 对应的类型信息:Type: hash:ip,port

        • 结合前面的规则

          ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            match-set KUBE-CLUSTER-IP dst,dst 
          
          

          表述的意思是请求的目的地址IP、目的端口和KUBE-CLUSTER-IP中的Members有匹配时,就接收请求

    2. filter表中

      $ iptables -nL -t filter
      Chain FORWARD (policy ACCEPT)
      target     prot opt source               destination
      KUBE-FORWARD  all  -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes forwarding rules */
      	
      Chain OUTPUT (policy ACCEPT)
      target     prot opt source               destination
      KUBE-FIREWALL  all  -- 0.0.0.0/0 0.0.0.0/0
      
      Chain KUBE-FIREWALL (2 references)
      target     prot opt source               destination
      DROP       all  -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000
      
      Chain KUBE-FORWARD (1 references)
      target     prot opt source               destination
      ACCEPT     all  -- 0.0.0.0/0 0.0.0.0/0 /* kubernetes forwarding rules */ mark match 0x4000/0x4000
      ACCEPT     all  -- 172.30.0.0/16 0.0.0.0/0 /* kubernetes forwarding conntrack pod source rule */ ctstate RELATED,ESTABLISHED
      ACCEPT     all  -- 0.0.0.0/0 172.30.0.0/16 /* kubernetes forwarding conntrack pod destination rule */ ctstate RELATED,ESTABLISHED
      
      

    通过分析kube-proxy追加的这些规则,可以看到访问service提供的服务时,iptables中的规则最终都会允许请求通过,并且通过 -m set --match-set 的规则匹配机制,kube-proxy不用随着servcie的创建和销毁来修改iptables中的规则,只用修改对应的ipset中相应的Members就能够达到效果,保证iptables的规则表固定大小,实现大规模服务集群中保持性能的稳定

  4. 请求通过了iptables中的规则后,在INPUT阶段,需要IPVS来对请求进行判断,看请求的服务是否属于集群服务,是的话还要能找出正确的真实服务地址,这个kube-proxy如何实现呢

    kube-proxy通过监听API server,当有service创建时,通过调用系统的netlink 接口,将service和对应的endpoint插入到IPVS对应的hash表中,对应代码在proxier.go中,用户可以通过ipvsadm工具查看ipvs hash表中的数据

    $ ipvsadm --list
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
      -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    TCP  promote.cache-dns.local:http rr
      -> master:6443                  Masq    1      1          0
    TCP  promote.cache-dns.local:doma rr
      -> 172.30.78.2:domain           Masq    1      0          0
    TCP  promote.cache-dns.local:9153 rr
      -> 172.30.78.2:9153             Masq    1      0          0
    TCP  promote.cache-dns.local:http rr
      -> 172.30.22.4:http-alt         Masq    1      0          0
      -> 172.30.78.4:http-alt         Masq    1      0          0
    UDP  promote.cache-dns.local:doma rr
      -> 172.30.78.2:domain           Masq    1      0          0   
      
    

    因为启用了DNS的cache功能,所以这个地方看到的service信息是DNS缓存信息

通过上述几个步骤后,kube-proxy就把需要使用IPVS的依赖条件都实现,就可以在请求到来时利用IPVS机制对请求进行转发了。

标签: 继电器rs1a23d25

锐单商城拥有海量元器件数据手册IC替代型号,打造 电子元器件IC百科大全!

锐单商城 - 一站式电子元器件采购平台