我们构建了四层负载均衡平台，平台中四层负载均衡的服务是使用LVS。我们公司使用的linux大多数的内核是4.9.0.XXX，该版本只支持NAT，不能支持fullnat，fullnat是阿里在多年前的2.6.32版本的内核上开发支持了fullnat，并开源出来，但是该版本已经停止维护。
目的
LVS缺省只支持NAT、Tunnel和DR三种负载均衡模式，由于该版本多年没有更新和维护，所以最新的内核版本中的LVS原生都是不支持fullnat的。NAT、DR、Tunnel这三种模式都有一定的限制，需要一定的环境的支持，才能正常的工作。
- DR模式的限制：RS跟Director Server必须有一个网卡在同一个物理网络中
- TUNNEL必须在所有的realserver上绑定VIP
- NAT：RS的网关必须指向LVS缩在服务器
目前看起来只有fullnat是没有任何限制的，而我们正在向业务部门推广容器发布服务，在容器中部署的服务，很明显，上面三种模式都不可行。为了对容器中部署的服务提供LVS的负载均衡服务，那就必须突破NAT的限制，支持跨VLAN的fullnat模式呢？
基本原理
LVS的NAT服务提供了DNAT的功能，只要把经过了LVS服务的包在出LVS主机的时候，再做SNAT处理，就能够实现fullnat了。
为了实现这个目的，我们可以配合iptables规则来实现通过LVS的包，在出主机时，配上对应的SNAT规则，从而可以实现了fullnat功能。
而这种模式也是kube-proxy的实现的原理，我们的四层负载均衡平台的fullnat也就是参考kube-proxy的细节来实现的。
下面我们介绍一下kube-proxy上的ipvs实现的底层逻辑，注意这里只会介绍基于clusterip的实现细节，其他都类似。
kube-proxy中基于clusterip模式的service的负载均衡细节
准备好一台服务器，假设服务器的ip为：10.1.1.1
- 部署好lvs，启动ipvs模块
# modprobe ip_vs
- 找一台服务应用服务器，假设ip为：192.168.1.2，我们在上面部署好nginx服务
端口号为：8181，nginx.conf的内容为：
user www-data;
worker_processes 1;
worker_rlimit_nofile 262140;
error_log logs/error.log;
pid run/nginx.pid;
events
{
use epoll;
worker_connections 65535;
}
http
{
include mime.types;
default_type application/octet-stream;
sendfile on;
aio on;
directio 512;
output_buffers 1 128k;
log_not_found off;
keepalive_timeout 65;
server_tokens off;
gzip on;
gzip_comp_level 6;
gzip_min_length 1k;
gzip_buffers 4 8k;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_types text/plain application/x-javascript text/css application/xml text/javascript application/javascript application/json;
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$request_time" "$upstream_response_time"';
access_log logs/${server_name}.access.log main;
fastcgi_intercept_errors on;
error_page 500 502 503 504 /50x.html;
server_names_hash_max_size 4096;
server
{
listen 8181 default;
server_name _;
#access_log off;
location /
{
echo "hello world";
}
}
}
- 启动nginx后，验证nignx正常工作。
root@ubuntu:/usr/local/nginx/conf# curl 127.0.0.1:8181
hello world
- 在lvs机器上创建ipset
ipset create KUBE-CLUSTER-IP hash:ip,port
ipset add KUBE-CLUSTER-IP 10.1.1.1,80
- 在lvs机器上创建好相应的iptables规则
iptables -N KUBE-SERVICES -t nat
iptables -N KUBE-MARK-MASQ -t nat
iptables -t nat -N KUBE-POSTROUTING
iptables -t nat -I POSTROUTING -m comment --comment "postrouting rule" -j KUBE-POSTROUTING
iptables -t nat -I PREROUTING -m comment --comment "proxy snat" -j LVS_PROXY_CHAIN
iptables -t nat -I KUE-SERVICES -m set --match-set KUBE-CLUSTER-IP dst,dst -j KUBE-MARK-MASQ
iptables -t nat -I KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000
iptables -t nat -I KUBE-POSTROUTING -m mark --mark 0x4000/0x4000 -j MASQUERADE
- 在lvs机器上创建好相应的ipvs路由规则
ipvsadm -A -t 10.1.1.1:80 -s rr
ipvsadm -a -t 10.1.1.1:80 -r 192.168.1.2:8181 -m
- 验证负载均衡的有效性
curl http://10.1.1.1
hello world
上面的步骤中，我们没有在realserver上做任何处理，就能够支持nat，而且realserver与lvs主机的ip不在一个网段中，这样我们基于LVS实现了一个fullnat的负载均衡功能。
总结
上面简要介绍了kube-proxy中基于ipvs做负载均衡的实现的原理和细节，它通过对走lvs负载均衡的包进行打好标记后，在出主机访问到realserver时，做snat处理，从而达到了fullnat的效果。
最后还要解释一下，为什么我们不直接用k8s中的service来对外提供负载均衡的服务呢？
- 一方面，我们要统一实现部署在物理机的服务的负载均衡；
- 另一方面，对于部署在容器中的服务ip地址不能对外，我们需要把服务对外暴漏给业务方来访问；
对于第二点也许有人会说，为什么不基于NodePort来对外提供服务呢，因为基于NodePort部署的服务，外面还是需要一个高可用功能，那么可能还需要一层LVS来保证高可用性。
网友评论