kube-proxy ipvs模式详解

 

一、kube-proxy 开启 ipvs

1、环境准备:

测试环境为kubernetes集群,一台master节点,一台node节点。集群网络使用flanneld搭建。

注意:master节点上也需要进行kubelet配置。因为ipvs在有些情况下是依赖iptables的,iptables中KUBE-POSTROUTING,KUBE-MARK-MASQ, KUBE-MARK-DROP这三条链是被 kubelet创建和维护的, ipvs不会创建它们。

2、建议关闭SELinux,firewall

firewall是Linux 的一个安全子系统,SELinux 主要作用就是最大限度地减小系统中服务进程可访问的资源。

关闭SELinux

docker1.node ➜  ~ cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of three two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

重启验证:

[root@master140 ~]# sestatus
SELinux status:                 disabled

关闭firewall

systemctl stop firewalld
systemctl disable firewalld
3、开启路由转发功能:
[root@master140 ~]# cat /etc/sysctl.conf
# sysctl settings are defined through files in
# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
#
# Vendors settings live in /usr/lib/sysctl.d/.
# To override a whole file, create a new file with the same in
# /etc/sysctl.d/ and put new settings there. To override
# only specific settings, add a file with a lexically later
# name in /etc/sysctl.d/ and put new settings there.
#
# For more information, see sysctl.conf(5) and sysctl.d(5).
net.ipv4.ip_forward=1

必须有net.ipv4.ip_forward=1,有了它,ipvs才能进行转发

执行 sysctl -p 使之生效

[root@node147 ~]# sysctl -p
net.ipv4.ip_forward = 1
4、内核模块加载
cat > /etc/sysconfig/modules/ipvs.modules <<EOF
#!/bin/bash
ipvs_modules="ip_vs ip_vs_lc ip_vs_wlc ip_vs_rr ip_vs_wrr ip_vs_lblc ip_vs_lblcr ip_vs_dh ip_vs_sh ip_vs_fo ip_vs_nq ip_vs_sed ip_vs_ftp nf_conntrack_ipv4"
for kernel_module in ${ipvs_modules}; do
    /sbin/modinfo -F filename ${kernel_module} > /dev/null 2>&1
    if [ $? -eq 0 ]; then
        /sbin/modprobe ${kernel_module}
    fi
done
EOF
chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep ip_vs

检查测试:

[root@master140 ~]# lsmod | grep ip_vs 
ip_vs_ftp              13079  0 
nf_nat                 26787  3 ip_vs_ftp,nf_nat_ipv4,nf_nat_masquerade_ipv4
ip_vs_sed              12519  0 
ip_vs_nq               12516  0 
ip_vs_sh               12688  0 
ip_vs_dh               12688  0 
ip_vs_lblcr            12922  0 
ip_vs_lblc             12819  0 
ip_vs_wrr              12697  0 
ip_vs_rr               12600  17 
ip_vs_wlc              12519  0 
ip_vs_lc               12516  0 
ip_vs                 141092  39 ip_vs_dh,ip_vs_lc,ip_vs_nq,ip_vs_rr,ip_vs_sh,ip_vs_ftp,ip_vs_sed,ip_vs_wlc,ip_vs_wrr,ip_vs_lblcr,ip_vs_lblc
nf_conntrack          133387  7 ip_vs,nf_nat,nf_nat_ipv4,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_netlink,nf_conntrack_ipv4
libcrc32c              12644  4 xfs,ip_vs,nf_nat,nf_conntrack
5、修改kube-proxy配置

Node:

KUBE_PROXY_ARGS="--bind-address=0.0.0.0 
  --hostname-override=node147 
  --kubeconfig=/etc/kubernetes/kube-proxy.conf 
  --logtostderr=true 
  --v=2 
  --feature-gates=SupportIPVSProxyMode=true 
  --proxy-mode=ipvs"

如果kubelet设置了–hostname-override选项,则kube-proxy也需要设置该选项,并且名字一致否则会出现找不到Node的情况。

Master:

KUBE_PROXY_ARGS="--proxy-mode=ipvs 
  --ipvs-scheduler=rr 
  --kubeconfig=/etc/kubernetes/kube-proxy.conf 
  --logtostderr=true 
  --v=2"

二、ipvs原理:

ipvs的模型中有两个角色:

调度器:Director,又称为Balancer。 调度器主要用于接受用户请求。

真实主机:Real Server,简称为RS。用于真正处理用户的请求。

IP地址类型分为三种:

Client IP:客户端请求源IP,简称CIP。

Director Virtual IP:调度器用于与客户端通信的IP地址,简称为VIP。

Real Server IP: 后端主机的用于与调度器通信的IP地址,简称为RIP。
在这里插入图片描述

工作过程:

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

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

3、ipvs会监听到达input链的数据包,比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP,然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP。

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

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

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

三 ipvs在kube-proxy中的使用

开启ipvs后,本机里面的一些信息会改变。

1、网卡

明显的变化是,多了一个绑定很多cluster service ip的kube-ipvs0网卡

[root@master140 ~]# ip addr
5: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default 
    link/ether d2:b0:08:01:3e:52 brd ff:ff:ff:ff:ff:ff
    inet 172.18.13.31/32 brd 172.18.13.31 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 172.18.13.1/32 brd 172.18.13.1 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 172.18.13.187/32 brd 172.18.13.187 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 172.18.13.113/32 brd 172.18.13.113 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 172.18.13.222/32 brd 172.18.13.222 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
2、router

查看router时候,会发现多了一下一些route信息。这些route信息是和上面的网卡信息对应的。

[root@master140 ~]# ip route show table local
local 172.18.13.1 dev kube-ipvs0 proto kernel scope host src 172.18.13.1 
local 172.18.13.31 dev kube-ipvs0 proto kernel scope host src 172.18.13.31 
local 172.18.13.113 dev kube-ipvs0 proto kernel scope host src 172.18.13.113 
local 172.18.13.187 dev kube-ipvs0 proto kernel scope host src 172.18.13.187 
local 172.18.13.222 dev kube-ipvs0 proto kernel scope host src 172.18.13.222 
3、ipvs 规则
[root@master140 ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  127.0.0.1:30001 rr
TCP  127.0.0.1:30002 rr
  -> 10.0.3.5:8080                Masq    1      0          0         
  -> 10.0.3.7:8080                Masq    1      0          0         
TCP  127.0.0.1:30094 rr
  -> 10.0.3.2:80                  Masq    1      0          0         
TCP  172.17.0.1:30001 rr
TCP  172.17.0.1:30002 rr
  -> 10.0.3.5:8080                Masq    1      0          0         
  -> 10.0.3.7:8080                Masq    1      0          0         
TCP  172.17.0.1:30094 rr
  -> 10.0.3.2:80                  Masq    1      0          0         
TCP  172.18.13.1:443 rr
  -> 192.168.204.142:6443         Masq    1      0          0         
TCP  172.18.13.31:80 rr
TCP  172.18.13.113:8082 rr
  -> 10.0.3.5:8080                Masq    1      0          0         
  -> 10.0.3.7:8080                Masq    1      0          0         
TCP  172.18.13.187:3306 rr
  -> 10.0.3.4:3306                Masq    1      0          0         
TCP  172.18.13.222:80 rr
  -> 10.0.3.2:80                  Masq    1      0          0         
TCP  192.168.204.142:30001 rr
TCP  192.168.204.142:30002 rr
  -> 10.0.3.5:8080                Masq    1      0          0         
  -> 10.0.3.7:8080                Masq    1      0          0         
TCP  192.168.204.142:30094 rr
  -> 10.0.3.2:80                  Masq    1      0          0         
TCP  10.0.1.0:30001 rr
TCP  10.0.1.0:30002 rr
  -> 10.0.3.5:8080                Masq    1      0          0         
  -> 10.0.3.7:8080                Masq    1      0          0         
TCP  10.0.1.0:30094 rr
  -> 10.0.3.2:80                  Masq    1      0          0         
4、新增网卡和route的作用

由于 IPVS 的 DNAT 钩子挂在 INPUT 链上,因此必须要让内核识别 VIP 是本机的 IP。这样才会过INPUT 链,要不然就通过OUTPUT链出去了。k8s 通过设置将service cluster ip 绑定到虚拟网卡kube-ipvs0。

5、使用ipvs的kube-proxy的工作原理

![屏幕快照 2019-05-15 下午1.00.20](/Users/tcy/Documents/Typora/Picture/屏幕快照 2019-05-15 下午1.00.20.png)
在这里插入图片描述
①因为service cluster ip 绑定到虚拟网卡kube-ipvs0上,内核可以识别访问的 VIP 是本机的 IP.

②数据包到达INPUT链.

③ipvs监听到达input链的数据包,比对数据包请求的服务是为集群服务,修改数据包的目标IP地址为对应pod的IP,然后将数据包发至POSTROUTING链.

④数据包经过POSTROUTING链选路,将数据包通过flannel网卡发送出去。从flannel虚拟网卡获得源IP.

⑤pod接收到请求之后,构建响应报文,改变源地址和目的地址,返回给客户端。

四、实例-集群内部通过clusterIP访问到pod的流程

本例子中有两台机器,master和node,pod都在node机器上运行。访问命令为curl 172.18.13.222:80,对应的pod的ip为10.0.7.7。

![屏幕快照 2019-05-15 上午9.36.27](/Users/tcy/Documents/Typora/Picture/屏幕快照 2019-05-15 上午9.36.27.png)
在这里插入图片描述

1、本机接受请求

内核通过本机的路由和虚拟网卡,可以识别访问的 VIP 是本机的 IP

//路由
local 172.18.13.222 dev kube-ipvs0 proto kernel scope host src 172.18.13.222
//网卡
inet 172.18.13.222/32 brd 172.18.13.222 scope global kube-ipvs0
valid_lft forever preferred_lft forever
2、将数据包送至INPUT链。

验证是否经过INPUT链

首先、我们在INPUT链中加入一条如下过滤规则。该规则的意思是当有目的地址为172.18.13.222时,都拒绝掉。

iptables -t filter -I INPUT -d 172.18.13.222 -j DROP

查看INPUT链,确实多了此条规则。
在这里插入图片描述
之后,我们watch INPUT链

watch -n 0.1 "iptables --line-number -nvxL INPUT"

当我们访问172.18.13.222时

curl 172.18.13.222

发现无法访问,并且watch到INPUT确实有拒绝的包。验证成功后。
在这里插入图片描述

3、ipvs对请求做转发

ipvs会监听到达input链的数据包,比对数据包请求的服务是为集群服务,所以修改数据包的目标IP地址为真实服务器IP,然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP(真实ip)
在这里插入图片描述

4、通过网卡发出数据包

数据包经过POSTROUTING链选路,将数据包通过flannel网卡发送出去,pod所在机器也通过flannel网卡进行接收。数据包经过master上的flannel网卡第一次被赋予源IP。此时源IP,目的IP分别是10.0.6.0,10.0.7.7

验证是否通过flnanel网卡进行通信:

首先:master上flannel网卡信息是10.0.6.0/16。
在这里插入图片描述
node上flannel网卡信息是10.0.7.0/16。在这里插入图片描述
当我们从master上进行curl命令时
在这里插入图片描述
对pod所在机器node的flannel网卡进行监听,发现是请求从10.0.6.0发送过来的。10.0.6.0正是master上的网卡信息。
在这里插入图片描述

5、pod接收到请求,处理,返回

pod接收到请求之后,开始构建响应报文返回给客户端。 此时报文的源IP为pod的IP:10.0.7.7,目标IP为10.0.6.0。最终又通过flannel网络将响应报文发回master。

注意:

我们上文所说的通过flannel网络进行通信,最终还是要过机器的真实网卡,因为flannel网络设置的网卡也是虚拟的。

例如我们监听机器的真实网卡eth0

tcpdump -nn -i eth0 src port not 22  and dst port not 22

在这里插入图片描述
我们是能够发现通过flannel网络进行通信还是会经过真实网卡eth0

原文地址:https://www.cnblogs.com/cheyunhua/p/14314647.html