基于LVS实现Fullnat

我们构建了四层负载均衡平台，平台中四层负载均衡的服务是使用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来保证高可用性。