k8s实践7:ipvs结合iptables使用过程分析

ゝ一世哀愁。 2022-10-01 13:44 833阅读 0赞

一个简单想法,在k8s里部署httpd服务,服务成功running.  
外部流量怎么访问到真正提供服务的pod呢？  
示例见下:

svc：
    [root@k8s-master1 test]# kubectl get svc
    NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)       AGE
    httpd-svc     NodePort    10.254.17.8     <none>        80:8572/TCP   7s
    
    pod:
    [root@k8s-master1 test]# kubectl get pod
    NAME                        READY     STATUS    RESTARTS   AGE
    httpd-app-bbcbfb6cd-dfwbs   1/1       Running   0          37s

svc和pod的映射关系

[root@k8s-master2 ~]# kubectl describe svc httpd-svc
    Name:                     httpd-svc
    Namespace:                default
    Labels:                   <none>
    Annotations:              kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"httpd-svc","namespace":"default"},"spec":{"ports":[{"port":80}],"selector":{"a...
    Selector:                 app=httpd-app
    Type:                     NodePort
    IP:                       10.254.17.8
    Port:                     <unset>  80/TCP
    TargetPort:               80/TCP
    NodePort:                 <unset>  8572/TCP
    Endpoints:                172.30.32.4:80
    Session Affinity:         None
    External Traffic Policy:  Cluster
    Events:                   <none>

外部流量访问到svc,然后svc跳转pod访问应用.  
svc怎么跳转访问pod的呢？  
kube-proxy实现svc到pod的访问和负载均衡.  
k8s低版本1.8版本前,kube-proxy默认使用iptables模式转发流量到pod.  
1.8版本之后,kube-proxy默认使用ipvs模式.

ipvs基础知识

ipvs常用的模式:  
VS/NAT模式（Network address translation）  
VS/TUN模式（tunneling）  
VS/DR模式（Direct routing）

VS/NAT模式,基本原理和过程,  
以下图片和文字来于文档:[https://www.cnblogs.com/randomlee/p/9046612.html][https_www.cnblogs.com_randomlee_p_9046612.html]

这个是通过网络地址转换的方法来实现调度的。首先调度器(LB)接收到客户的请求数据包时（请求的目的IP为VIP），根据调度算法决定将请求发送给哪个后端的真实服务器（RS）。然后调度就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址（RIP）,这样真实服务器（RS）就能够接收到客户的请求数据包了。真实服务器响应完请求后，查看默认路由（NAT模式下我们需要把RS的默认路由设置为LB服务器。）把响应后的数据包发送给LB,LB再接收到响应包后，把包的源地址改成虚拟地址（VIP）然后发送回给客户端。

调度过程IP包详细图：

![k8s实践7:ipvs结合iptables使用过程分析][k8s_7_ipvs_iptables]  
原理图简述：

1)客户端请求数据，目标IP为VIP

2)请求数据到达LB服务器，LB根据调度算法将目的地址修改为RIP地址及对应端口（此RIP地址是根据调度算法得出的。）并在连接HASH表中记录下这个连接。

3)数据包从LB服务器到达RS服务器webserver，然后webserver进行响应。Webserver的网关必须是LB，然后将数据返回给LB服务器。

4)收到RS的返回后的数据，根据连接HASH表修改源地址VIP&目标地址CIP，及对应端口80.然后数据就从LB出发到达客户端。

5)客户端收到的就只能看到VIP\\DIP信息。

iptables基础知识

以下文字来源于文档:  
[https://www.cnblogs.com/ggjucheng/archive/2012/08/19/2646466.html?tdsourcetag=s\_pcqq\_aiomsg][https_www.cnblogs.com_ggjucheng_archive_2012_08_19_2646466.html_tdsourcetag_s_pcqq_aiomsg]

iptables简介  
    netfilter/iptables（简称为iptables）组成Linux平台下的包过滤防火墙，与大多数的Linux软件一样，这个包过滤防火墙是免费的，它可以代替昂贵的商业防火墙解决方案，完成封包过滤、封包重定向和网络地址转换（NAT）等功能。

iptables基础

规则（rules）其实就是网络管理员预定义的条件，规则一般的定义为“如果数据包头符合这样的条件，就这样处理这个数据包”。规则存储在内核空间的信息包过滤表中，这些规则分别指定了源地址、目的地址、传输协议（如TCP、UDP、ICMP）和服务类型（如HTTP、FTP和SMTP）等。当数据包与规则匹配时，iptables就根据规则所定义的方法来处理这些数据包，如放行（accept）、拒绝（reject）和丢弃（drop）等。配置防火墙的主要工作就是添加、修改和删除这些规则。

iptables和netfilter的关系：  
    这是第一个要说的地方，Iptables和netfilter的关系是一个很容易让人搞不清的问题。很多的知道iptables却不知道netfilter。其实iptables只是Linux防火墙的管理工具而已，位于/sbin/iptables。真正实现防火墙功能的是netfilter，它是Linux内核中实现包过滤的内部结构。

iptables传输数据包的过程  
① 当一个数据包进入网卡时，它首先进入PREROUTING链，内核根据数据包目的IP判断是否需要转送出去。  
② 如果数据包就是进入本机的，它就会沿着图向下移动，到达INPUT链。数据包到了INPUT链后，任何进程都会收到它。本机上运行的程序可以发送数据包，这些数据包会经过OUTPUT链，然后到达POSTROUTING链输出。  
③ 如果数据包是要转发出去的，且内核允许转发，数据包就会如图所示向右移动，经过FORWARD链，然后到达POSTROUTING链输出。  
![k8s实践7:ipvs结合iptables使用过程分析][k8s_7_ipvs_iptables 1]

iptables的规则表和链：  
    表（tables）提供特定的功能，iptables内置了4个表，即filter表、nat表、mangle表和raw表，分别用于实现包过滤，网络地址转换、包重构(修改)和数据跟踪处理。

链（chains）是数据包传播的路径，每一条链其实就是众多规则中的一个检查清单，每一条链中可以有一条或数条规则。当一个数据包到达一个链时，iptables就会从链中第一条规则开始检查，看该数据包是否满足规则所定义的条件。如果满足，系统就会根据该条规则所定义的方法处理该数据包；否则iptables将继续检查下一条规则，如果该数据包不符合链中任一条规则，iptables就会根据该链预先定义的默认策略来处理数据包。

规则表：  
1.filter表——三个链：INPUT、FORWARD、OUTPUT  
作用：过滤数据包  内核模块：iptables\_filter.  
2.Nat表——三个链：PREROUTING、POSTROUTING、OUTPUT  
作用：用于网络地址转换（IP、端口） 内核模块：iptable\_nat  
3.Mangle表——五个链：PREROUTING、POSTROUTING、INPUT、OUTPUT、FORWARD  
作用：修改数据包的服务类型、TTL、并且可以配置路由实现QOS内核模块：iptable\_mangle(别看这个表这么麻烦，咱们设置策略时几乎都不会用到它)  
4.Raw表——两个链：OUTPUT、PREROUTING  
作用：决定数据包是否被状态跟踪机制处理  内核模块：iptable\_raw  
(这个是REHL4没有的，不过不用怕，用的不多)

规则链：

1.INPUT——进来的数据包应用此规则链中的策略  
2.OUTPUT——外出的数据包应用此规则链中的策略  
3.FORWARD——转发数据包时应用此规则链中的策略  
4.PREROUTING——对数据包作路由选择前应用此链中的规则  
（记住！所有的数据包进来的时侯都先由这个链处理）  
5.POSTROUTING——对数据包作路由选择后应用此链中的规则  
（所有的数据包出来的时侯都先由这个链处理）

规则表之间的优先顺序：  
Raw——mangle——nat——filter  
规则链之间的优先顺序（分三种情况）：

第一种情况：入站数据流向

从外界到达防火墙的数据包，先被PREROUTING规则链处理（是否修改数据包地址等），之后会进行路由选择（判断该数据包应该发往何处），如果数据包的目标主机是防火墙本机（比如说Internet用户访问防火墙主机中的web服务器的数据包），那么内核将其传给INPUT链进行处理（决定是否允许通过等），通过以后再交给系统上层的应用程序（比如Apache服务器）进行响应。

第二冲情况：转发数据流向

来自外界的数据包到达防火墙后，首先被PREROUTING规则链处理，之后会进行路由选择，如果数据包的目标地址是其它外部地址（比如局域网用户通过网关访问QQ站点的数据包），则内核将其传递给FORWARD链进行处理（是否转发或拦截），然后再交给POSTROUTING规则链（是否修改数据包的地址等）进行处理。

第三种情况：出站数据流向  
     防火墙本机向外部地址发送的数据包（比如在防火墙主机中测试公网DNS服务器时），首先被OUTPUT规则链处理，之后进行路由选择，然后传递给POSTROUTING规则链（是否修改数据包的地址等）进行处理。

k8s中的ipvs使用

上面特意的详细记录ipvs的NAT模式基础知识和iptables的基础知识.  
因为k8s里的ipvs使用的就是NAT模式.而且ipvs并不能实现kube-proxy的全部功能,比如包过滤,源地址转换,masquared(伪装)转换等,这些都需要iptables来处理.

检索k8s集群中iptables的链,表,规则

表,见下:

[root@k8s-node1 ~]# iptables-save
    # Generated by iptables-save v1.4.21 on Tue Mar 26 09:46:00 2019
    *filter
    :INPUT ACCEPT [129:42061]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [124:9766]
    :DOCKER - [0:0]
    :DOCKER-ISOLATION - [0:0]
    :KUBE-FIREWALL - [0:0]
    :KUBE-FORWARD - [0:0]
    -A INPUT -j KUBE-FIREWALL
    -A FORWARD -m comment --comment "kubernetes forwarding rules" -j KUBE-FORWARD
    -A FORWARD -j DOCKER-ISOLATION
    -A FORWARD -o docker0 -j DOCKER
    -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i docker0 ! -o docker0 -j ACCEPT
    -A FORWARD -i docker0 -o docker0 -j ACCEPT
    -A FORWARD -s 172.30.0.0/16 -j ACCEPT
    -A FORWARD -d 172.30.0.0/16 -j ACCEPT
    -A OUTPUT -j KUBE-FIREWALL
    -A DOCKER-ISOLATION -j RETURN
    -A KUBE-FIREWALL -m comment --comment "kubernetes firewall for dropping marked packets" -m mark --mark 0x8000/0x8000 -j DROP
    -A KUBE-FORWARD -m comment --comment "kubernetes forwarding rules" -m mark --mark 0x4000/0x4000 -j ACCEPT
    -A KUBE-FORWARD -s 172.30.0.0/16 -m comment --comment "kubernetes forwarding conntrack pod source rule" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    -A KUBE-FORWARD -d 172.30.0.0/16 -m comment --comment "kubernetes forwarding conntrack pod destination rule" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    COMMIT
    # Completed on Tue Mar 26 09:46:00 2019
    # Generated by iptables-save v1.4.21 on Tue Mar 26 09:46:00 2019
    *nat
    :PREROUTING ACCEPT [0:0]
    :INPUT ACCEPT [0:0]
    :OUTPUT ACCEPT [3:180]
    :POSTROUTING ACCEPT [3:180]
    :DOCKER - [0:0]
    :KUBE-FIREWALL - [0:0]
    :KUBE-LOAD-BALANCER - [0:0]
    :KUBE-MARK-DROP - [0:0]
    :KUBE-MARK-MASQ - [0:0]
    :KUBE-NODE-PORT - [0:0]
    :KUBE-POSTROUTING - [0:0]
    :KUBE-SERVICES - [0:0]
    -A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
    -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
    -A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
    -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
    -A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING
    -A POSTROUTING -s 172.30.30.0/24 ! -o docker0 -j MASQUERADE
    -A DOCKER -i docker0 -j RETURN
    -A KUBE-FIREWALL -j KUBE-MARK-DROP
    -A KUBE-LOAD-BALANCER -j KUBE-MARK-MASQ
    -A KUBE-MARK-DROP -j MARK --set-xmark 0x8000/0x8000
    -A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000
    -A KUBE-NODE-PORT -p tcp -m comment --comment "Kubernetes nodeport TCP port for masquerade purpose" -m set --match-set KUBE-NODE-PORT-TCP dst -j KUBE-MARK-MASQ
    -A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE
    -A KUBE-POSTROUTING -m comment --comment "Kubernetes endpoints dst ip:port, source ip for solving hairpin purpose" -m set --match-set KUBE-LOOP-BACK dst,dst,src -j MASQUERADE
    -A KUBE-SERVICES ! -s 172.30.0.0/16 -m comment --comment "Kubernetes service cluster ip + port for masquerade purpose" -m set --match-set KUBE-CLUSTER-IP dst,dst -j KUBE-MARK-MASQ
    -A KUBE-SERVICES -m addrtype --dst-type LOCAL -j KUBE-NODE-PORT
    -A KUBE-SERVICES -m set --match-set KUBE-CLUSTER-IP dst,dst -j ACCEPT
    COMMIT
    # Completed on Tue Mar 26 09:46:00 2019
    [root@k8s-node1 ~]#

可见,在这里只有两种表,nat和filter

规则链,见下:

[root@k8s-node1 ~]# iptables -L -n
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination        
    KUBE-FIREWALL  all  --  0.0.0.0/0            0.0.0.0/0          
    
    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 */
    DOCKER-ISOLATION  all  --  0.0.0.0/0            0.0.0.0/0          
    DOCKER     all  --  0.0.0.0/0            0.0.0.0/0          
    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
    ACCEPT     all  --  172.30.0.0/16        0.0.0.0/0          
    ACCEPT     all  --  0.0.0.0/0            172.30.0.0/16      
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination        
    KUBE-FIREWALL  all  --  0.0.0.0/0            0.0.0.0/0          
    
    Chain DOCKER (1 references)
    target     prot opt source               destination        
    
    Chain DOCKER-ISOLATION (1 references)
    target     prot opt source               destination        
    RETURN     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

ipvs访问pod的整个过程是怎样的呢？  
这些分析和思路都是个人理解.  
结合开始svc示例,进行分析.  
见下:

示例:

svc：
    httpd-svc     NodePort    10.254.17.8     <none>        80:8572/TCP   7s
    
    pod：
    httpd-app-bbcbfb6cd-dfwbs   1/1       Running   1          22h       172.30.32.2   k8s-master3

通过nodeIP:8572访问http应用,应用访问请求到达node节点.node就是ipvs里的LB

根据iptables的规则执行顺序,首先执行的是nat里的PREROUTING规则,见下:

-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
    -A KUBE-SERVICES ! -s 172.30.0.0/16 -m comment --comment "Kubernetes service cluster ip + port for masquerade purpose" -m set --match-set KUBE-CLUSTER-IP dst,dst -j KUBE-MARK-MASQ
    -A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000

\#\#执行完PREROUTING规则,数据打上0x4000/0x4000的标记.

数据进来了,执行INPUT规则,见下:

-A INPUT -j KUBE-FIREWALL
    -A KUBE-FIREWALL -j KUBE-MARK-DROP
    -A KUBE-MARK-DROP -j MARK --set-xmark 0x8000/0x8000

\#\#如果进来的数据带有0x8000/0x8000标记,丢弃,进来的数据带有的标记是0x4000/0x4000,因此,数据正常继续前进

这时申请访问的地址是vip(svc的ip)  
内核的ipvs响应,ipvs根据调度算法将目的地址修改为后端的RL(其实就是pod的地址),数据转发,用到的规则,见下:

-A FORWARD -m comment --comment "kubernetes forwarding rules" -j KUBE-FORWARD
    -A KUBE-FORWARD -d 172.30.0.0/16 -m comment --comment "kubernetes forwarding conntrack pod destination rule" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

\#\#目的地址是172.32.0.0/16的允许转发,172.32.0.0/16就是pod的地址

访问请求数据到达pod,pod响应,响应数据到达LB,用到规则

-A KUBE-FORWARD -s 172.30.0.0/16 -m comment --comment "kubernetes forwarding conntrack pod source rule" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

\#\#源地址是172.32.0.0/16的允许转发

最后使用POSRTOUTING规则,见下:

-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING
    -A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE
    -A KUBE-POSTROUTING -m comment --comment "Kubernetes endpoints dst ip:port, source ip for solving hairpin purpose" -m set --match-set KUBE-LOOP-BACK dst,dst,src -j MASQUERADE

\#\#把后端的RL地址(pod的ip地址)修改成LB的地址,就是SNAT.输出

以上分析可见,使用的是IPVS的NAT模式.

这些过程和理解是基于上面记录的iptables基础知识里的数据包传输,见下:  
③ 如果数据包是要转发出去的，且内核允许转发，数据包就会如图所示向右移动，经过FORWARD链，然后到达POSTROUTING链输出。

ipvs的LB和vip

LB是安装ipvs的节点  
vip是service的ip,内核需要识别VIP(servicede ip)是本机的ip,因此将svc的ip绑定在node的kube-ipvs0上

10: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
        link/ether 82:88:22:c3:e1:e8 brd ff:ff:ff:ff:ff:ff
        inet 10.254.17.8/32 brd 10.254.17.8 scope global kube-ipvs0
          valid_lft forever preferred_lft forever
        inet 10.254.0.1/32 brd 10.254.0.1 scope global kube-ipvs0
          valid_lft forever preferred_lft forever
        inet 10.254.30.179/32 brd 10.254.30.179 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.173.49/32 brd 10.254.173.49 scope global kube-ipvs0
          valid_lft forever preferred_lft forever

修改ipvs模式

[root@k8s-master2 ~]# systemctl status kube-proxy
    ● kube-proxy.service - Kubernetes Kube-Proxy Server
      Loaded: loaded (/etc/systemd/system/kube-proxy.service; enabled; vendor preset: disabled)
      Active: active (running) since Tue 2019-03-26 09:04:19 CST; 1h 45min ago
        Docs: https://github.com/GoogleCloudPlatform/kubernetes
    Main PID: 892 (kube-proxy)
      Memory: 26.3M
      CGroup: /system.slice/kube-proxy.service
              ‣ 892 /opt/k8s/bin/kube-proxy --config=/etc/kubernetes/kube-proxy.config.yaml --alsologtostderr=true --logtostderr=false --log-dir=...

[root@k8s-master2 ~]# cat /etc/kubernetes/kube-proxy.config.yaml
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    bindAddress: 192.168.32.129
    clientConnection:
      kubeconfig: /etc/kubernetes/kube-proxy.kubeconfig
    clusterCIDR: 172.30.0.0/16
    healthzBindAddress: 192.168.32.129:10256
    hostnameOverride: k8s-master2
    kind: KubeProxyConfiguration
    metricsBindAddress: 192.168.32.129:10249
    mode: "ipvs"

mode这个值设置模式.

ipvs命令

[root@k8s-master1 ~]# ipvsadm -Ln
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
      -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    TCP  192.168.32.128:8572 rr
      -> 172.30.32.2:80               Masq    1      0          0                                                                             
    [root@k8s-master1 ~]#

转载于:https://blog.51cto.com/goome/2369150

[https_www.cnblogs.com_randomlee_p_9046612.html]: https://www.cnblogs.com/randomlee/p/9046612.html
[k8s_7_ipvs_iptables]: https://s1.51cto.com/images/blog/201903/26/4aa5d79ecdc6be8b7b04e5e6feb383ba.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[https_www.cnblogs.com_ggjucheng_archive_2012_08_19_2646466.html_tdsourcetag_s_pcqq_aiomsg]: https://www.cnblogs.com/ggjucheng/archive/2012/08/19/2646466.html?tdsourcetag=s_pcqq_aiomsg
[k8s_7_ipvs_iptables 1]: https://s1.51cto.com/images/blog/201903/26/36a164e4285b6e7118c64083c20f278e.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=