测试环境为kubernetes集群，一台master节点，一台node节点。集群网络使用flanneld搭建。
注意：master节点上也需要进行kubelet配置。因为ipvs在有些情况下是依赖iptables的，iptables中KUBE-POSTROUTING，KUBE-MARK-MASQ， KUBE-MARK-DROP这三条链是被 kubelet创建和维护的， ipvs不会创建它们。
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
[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
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
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"
调度器:Director，又称为Balancer。 调度器主要用于接受用户请求。
真实主机:Real Server，简称为RS。用于真正处理用户的请求。
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后，本机里面的一些信息会改变。
明显的变化是，多了一个绑定很多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
查看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
[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
由于 IPVS 的 DNAT 钩子挂在 INPUT 链上，因此必须要让内核识别 VIP 是本机的 IP。这样才会过INPUT 链，要不然就通过OUTPUT链出去了。k8s 通过设置将service cluster ip 绑定到虚拟网卡kube-ipvs0。
①因为service cluster ip 绑定到虚拟网卡kube-ipvs0上，内核可以识别访问的 VIP 是本机的 IP.
②数据包到达INPUT链.
③ipvs监听到达input链的数据包，比对数据包请求的服务是为集群服务，修改数据包的目标IP地址为对应pod的IP，然后将数据包发至POSTROUTING链.
④数据包经过POSTROUTING链选路，将数据包通过flannel网卡发送出去。从flannel虚拟网卡获得源IP.
⑤pod接收到请求之后，构建响应报文，改变源地址和目的地址，返回给客户端。
本例子中有两台机器，master和node，pod都在node机器上运行。访问命令为curl 172.18.13.222:80，对应的pod的ip为10.0.7.7。
内核通过本机的路由和虚拟网卡，可以识别访问的 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
验证是否经过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确实有拒绝的包。验证成功后。
ipvs会监听到达input链的数据包，比对数据包请求的服务是为集群服务，所以修改数据包的目标IP地址为真实服务器IP，然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP，目标IP为RIP(真实ip)
数据包经过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上的网卡信息。
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