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

一个简单想法,在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

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

调度过程IP包详细图：

原理图简述：

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

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链输出。

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 ~]#