做云原生的人聊负载均衡话题往往集中在Ingress Controller、Service、网关这些上层组件上很少有人愿意往回翻Linux内核那层。但有一句话我想放在最前面你在云厂商控制台里买的四层负载均衡底层大概率就是LVSLinux Virtual Server你Kubernetes集群里kube-proxy切到ipvs模式后真正干活的也是LVS。这个源于1998年的内核态项目在云原生时代不但没被淘汰反而成了流量进入集群前谁也绕不开的一道闸门。这篇内容我会从云原生的视角重新拆解LVS先说清楚它在这个链路里的位置再讲模式选型、Kubernetes集成、生产部署和调参避坑。无论你是准备自建集群入口负载均衡还是只想知道云LB背后的原理这份内容都值得花十分钟读完。1. 云原生流量入口的最后一公里LVS凭什么还在1.1 一条完整的云原生访问链路云原生架构下一次用户请求到达Pod里的进程通常会经过一条层层过滤的链路。DNS负责把域名解析成公网IP随后四层负载均衡按四元组把连接转发到集群的NodePortIngress Controller再按HTTP域名和路径把流量路由到具体的Service最终由Service转发到某个后端Pod。在这条链路上LVS通常出现在两个地方第一个是云厂商的四层负载均衡底层第二个是集群内kube-proxy的ipvs模式。也就是说你可能从来没有主动部署过LVS但你大概率已经在间接使用它。以国内某大型云厂商的SLB为例底层就是基于LVS的FULLNAT模式改造的高性能内核模块一个VIP背后是整个集群的Director节点再通过一致性哈希把流量分发到后端。这套架构很少暴露给使用者但它的稳定性和性能决定了云上全部四层流量转发的体验。假如你在自建机房LVS的位置往往更加靠前直接在物理机或虚拟机上跑KeepalivedLVS作为数据中心入口的四层负载均衡器后面再接Nginx Ingress Controller。这套组合在云原生时代依然成立因为流量无论如何都要从外部进入集群而LVS是这条路径上最稳定、最不容易出幺蛾子的环节。1.2 LVS相比用户态负载均衡的不可替代性很多人会问既然有Nginx、HAProxy这些用户态负载均衡为什么底层还需要LVS核心原因有三个。第一LVS工作在内核态。IPVS是netfilter框架上的一个模块数据包在协议栈里被直接改写和转发全程不经过用户态与内核态的上下文切换。Nginx接受一个连接要经历系统调用、用户态事件循环、缓冲区拷贝单机吞吐量和内核态转发完全不是一个量级。同配置的物理机做四层转发测试LVS可以扛住百万级并发连接而Nginx到几十万就已经很难突破了。第二LVS的转发语义非常薄几乎不含业务逻辑。它只负责按算法选后端、改写MAC或IP然后转发不做TLS终止、不做HTTP解析、不做路径匹配。这也意味着它不容易出错更不容易被应用层Bug拖垮。三层四层的转发工具就该这么纯粹。第三稳定性经过了二十多年生产验证。从早期电商平台的亿级PV到如今各大云厂商的LB集群LVS早被压出了边界。这个内核模块长期稳定运行不像用户态程序那样容易被内存泄漏、僵尸进程、依赖冲突困扰。我见过很多Nginx进程异常抖动但几乎没见IPVS模块掉过链子。2. 四种转发模式和调度算法生产选型千万不要凭感觉2.1 四种模式对比LVS支持NAT、DR、TUN、FULLNAT四种工作模式。很多刚接触的人容易被模式绕晕我直接说它们各自的特点。NAT模式里Director相当于网关请求和响应都经过它通过改写目的地址和源地址来转发。优点是RealServer不需要任何额外配置也不用绑VIP缺点是回程流量全部压在Director上容量很快见顶。DR模式只改写MAC地址请求经过Director响应由RealServer直接回给客户端。这是性能最好的模式也是生产上最常见的选型缺点是Director和RealServer必须在同一个二层网络且RealServer必须做ARP抑制否则VIP会被抢答。具体配置我在第四章会完整演示。TUN模式把原始报文封装进IP隧道再传给RealServer适合跨网段分布式部署要求RealServer支持隧道并且内核开启IPIP。实际运维中很少看到有人长期用这模式因为它带来的复杂度和收益不成正比。FULLNAT模式在NAT基础上把源地址也转换成Director的地址SNAT和DNAT都做。这个模式主要是为了在超大规模集群里规避对源IP的依赖、简化RealServer的网络配置。但FULLNAT没有进Linux主线内核是各家云厂商自己打补丁实现的你直接用标准内核装LVS基本用不上。我整理了一个对比表方便你按场景选对比项NATDRTUNFULLNAT请求是否过Director是是是隧道是响应是否过Director是否否是RealServer是否需改ARP否是否否二层要求可跨网段必须在同一二层可跨网段可跨网段性能中最高高中生产常见度小规模标准生产少见云LB底层2.2 调度算法的适用场景LVS支持的调度算法很多但生产环境真正用到的不超过五个RR、WRR、LC、WLC、SH。RR以轮询方式分发适合后端配置完全一致的情况。WRR按权重分配适合新旧机器混部通过权重控制流量进入比例。LC看活跃连接数把新请求交给当前连接数最少的后端适合长连接业务。WLC是LC的加权版本也是IPVS默认算法综合考虑权重和活跃连接数来决定调度。SH按源IP做哈希保证同一个客户端始终落到同一台后端专门用于会话保持。有一个很容易被忽略的知识点在Kubernetes的ipvs模式下Service默认调度算法是RR而不是WLC因为ClusterIP背后的Pod通常规格一致RR最公平。而传统LVS生产环境我反而更推荐WLC因为后端机器性能很难完全一致WLC能自动把压力倾斜向空闲节点。这里还想提醒一下SH模式等于云LB上的会话保持能力。如果业务本身是无状态的尽量不要开会话保持否则会人为制造热点把流量固定压在一两台后端上。我调过很多因为误开会话保持导致单机CPU飘红的问题根源都在这里。3. kube-proxy的ipvs模式LVS在Kubernetes里的正确打开方式3.1 为什么iptables模式撑不住大规模集群Kubernetes里Service的负载均衡传统上由kube-proxy通过宿主机iptables规则实现。iptables规则本质是链式遍历一个数据包要逐条匹配规则而集群规模扩大后规则数量呈线性增长每个新连接都要遍历整条链CPU消耗随之上升。Kubernetes社区的建议是Service数量达到几千、Pod数量达到几万时iptables模式就会出现明显的转发延迟和CPU消耗问题。我印象很深的一个案例是生产集群大约900个Service时部分节点的coredns解析抖动最后定位到是kube-proxy在iptables规则上消耗了太多CPU新连接建连时延明显上升。切成ipvs模式后规则被同步成内核IPVS哈希表每个Service对应一个VIP时间复杂度降为O(1)CPU占用直接回落了一大截。这里的本质是ipvs模式并不是一个外挂负载均衡器它只是让kube-proxy把Service信息同步给内核IPVS模块然后由LVS本身在内核态完成转发。换句话说Kubernetes在大规模场景下真正干活的还是LVS。3.2 启用ipvs的完整操作与验证启用需要三步内核加载ip_vs相关模块、kube-proxy以ipvs模式启动、宿主机安装ipvsadm工具。在节点上加载模块cat /etc/modules-load.d/ipvs.conf EOF ip_vs ip_vs_rr ip_vs_wrr ip_vs_lc ip_vs_wlc ip_vs_sh nf_conntrack EOF systemctl restart systemd-modules-load lsmod | grep ip_vskube-proxy如果是DaemonSet部署修改启动参数加上--proxy-modeipvs然后滚动更新如果是二进制部署直接改启动脚本重启进程。验证是否真正生效看ipvsadm -Ln最直接ipvsadm -Ln如果能看到类似这样的输出TCP 10.96.0.10:53 rr - 10.244.0.22:53 Masq 1 0 0 TCP 10.96.0.1:443 rr - 10.244.0.1:6443 Masq 1 0 0说明kube-proxy已经把Service同步到内核IPVS表里了。LocalAddress是ClusterIPRemoteAddress是Pod IPForward是Masq对应NAT模式。如果你看到的还是iptables的nat链比如KUBE-SVC这些规则说明ipvs模式没生效需要检查模块和启动参数。另外提一下坑如果节点上没装ipvsadmkube-proxy可能报错它会在日志里明确告诉你cant use ipvs due to missing ip_vs module or ipvsadm。不要只看Pod状态一定要看日志。4. KeepalivedLVS DR模式生产级部署实录4.1 拓扑规划与角色划分先明确角色。LVS里Director是负载均衡器RealServer是真正提供服务的后端。DR模式要求Director和RealServer在同一个二层网络VIP由Director持有。我这次的部署拓扑Director-Master192.168.1.10Director-Backup192.168.1.11VIP192.168.1.100RealServer-1192.168.1.20RealServer-2192.168.1.21两台Director通过Keepalived的VRRP协议组成主备正常情况下VIP在Master上Master故障后VIP自动漂移Backup。RealServer跑Nginx提供HTTP服务。这是整个数据中心最常见的四层入口架构。这里要特别提示RealServer的默认网关是192.168.1.1不需要指向Director这是DR模式和NAT模式的本质区别。DR模式下RealServer收到请求时目的IP是VIP来源MAC是Director它响应时直接把包交给网关不再回Director。正因如此Director才不会有回程压力。在云原生环境里这套Director后面接的可以直接是Nginx Ingress Controller也可以是API Server还能直接转发到NodePort绕过集群内iptables那层转换少一层开销。4.2 Director端配置与RealServer端ARP抑制Director端安装yum install -y ipvsadm keepalivedKeepalived配置我用了单播VRRP因为生产环境里组播经常被交换机策略过滤或者被跨网段丢掉单播更可控。Master节点配置global_defs { router_id LVS_MASTER } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 unicast_src_ip 192.168.1.10 unicast_peer { 192.168.1.11 } virtual_ipaddress { 192.168.1.100/24 } } virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo rr protocol TCP real_server 192.168.1.20 80 { weight 1 TCP_CHECK { connect_timeout 3 } } real_server 192.168.1.21 80 { weight 1 TCP_CHECK { connect_timeout 3 } } }Backup节点把state改成BACKUP、priority改成90、unicast_src_ip改成自己的地址即可。不要小看这些字段virtual_router_id必须在主备间保持一致priority必须不同才能决定主备关系健康检查用TCP_CHECK比HTTP_GET更可靠因为LVS是四层转发探活也只应该做四层。启动Keepalived后检查systemctl start keepalived ip addr show dev eth0看到192.168.1.100出现在Master的eth0上说明VIP漂移成功。RealServer端的关键是ARP抑制。我在每台RealServer上执行cat /etc/sysctl.d/lvs-arp.conf EOF net.ipv4.conf.all.arp_ignore 1 net.ipv4.conf.all.arp_announce 2 net.ipv4.conf.lo.arp_ignore 1 net.ipv4.conf.lo.arp_announce 2 EOF sysctl -p /etc/sysctl.d/lvs-arp.conf ip addr add 192.168.1.100/32 dev lo解释下参数arp_ignore1表示只回答目标IP是本机接收接口IP的ARP请求arp_announce2表示通告时尽量使用本接口上最合适的地址。配合把VIP以32位掩码绑到lo上RealServer既能正常收到目的IP是VIP的数据包又不会在ARP请求里抢答VIP彻底避免MAC地址冲突。我必须强调顺序很重要先配置ARP参数再绑定VIP。如果把顺序反过来在绑VIP后到ARP参数生效前这段窗口期ARP会被打乱客户端访问可能已经出现异常。4.3 连通性验证与流量分发观察一切配置完成后在Director上确认规则已生效ipvsadm -Ln看到虚拟服务和两个RealServer都在列表里后分别修改两台RealServer的index.html加入不同标识然后从客户端反复访问VIPfor i in $(seq 1 10); do curl -s http://192.168.1.100/hostname; done正常会看到两台后端交替返回。再用ipvsadm -Ln --stats观察每个RealServer的连接统计确认负载是否均匀ipvsadm -Ln --stats如果要测试高可用可以直接停掉一台RealServer的NginxKeepalived的TCP_CHECK会在超时后自动摘除对应IPVS条目之后流量只进存活的那台把服务拉起来后条目又会自动恢复。这个摘除和恢复的过程生产上相信我一定要做一次演练因为很多人的Keepalived配置写错了健康检查参数后端宕机了都不会触发摘除。5. 生产环境调参与踩坑记录5.1 一难ARP风暴DR模式最经典的问题就是ARP风暴。我遇到过的情况是刚把VIP绑到RealServer的lo上还没来得及做ARP抑制整个机房的网络就开始间歇性丢包。原因是RealServer和Director在同一个广播域客户端发出ARP请求找VIP对应的MAC时多台机器同时应答交换机学到错误的MAC表项后续报文被发错方向。排错链路大致是客户端请求VIP时延反复横跳能通但极不稳定在交换机上看VIP的MAC表发现MAC在Director和RealServer之间来回切换最后排查到是ARP抑制没生效。修复方式很简单就是严格按照先改sysctl再绑VIP的顺序把配置重做一遍。这里有个容易忽略的坑arp_ignore和arp_announce是分接口和全局生效的。有时你只配了lo但系统里conf/all前缀的值会和接口级配置冲突。所以我会直接把all和lo都配成相同值这个做法比只配lo稳妥得多。5.2 二难NAT模式下的性能瓶颈NAT模式的痛点是响应流量也必须过Director。同样一台DirectorDR模式可能轻松扛几十GbpsNAT模式往往3Gbps就顶不住了因为每个包来回都要过内核连接跟踪表还得在转发路径上反复做地址改写。如果环境限制只能用NAT模式建议做这几件事把会话超时调短用ipvsadm --set 900 120 300避免半开连接撑爆conntrack表调高nf_conntrack_max并注意观察内存占用开启net.ipv4.ip_forward1。但与其在NAT模式里反复调优我更推荐直接换DR或者买云LB。很多人以为开启tcp_tw_recycle能解决TIME_WAIT堆积实际上Linux 4.12内核之后这个参数已经没用了而且它曾引发非常严重的NAT场景问题。正确做法是用tcp_tw_reuse加tcp_fin_timeout组合结合业务连接的实际情况慢慢调。5.3 三难公有云环境里的部署困境在阿里云、腾讯云这类公有云上自建LVS DR模式会遇到硬伤云网络的VRRP组播包通常不转发VIP的ARP广播也受限你在控制台VSwitch里甚至看不到自己绑的VIP漂移。所以我的观点很明确公有云里不要为了用LVS而去自建DR模式直接使用云厂商的四层负载均衡就好底层就是LVS功能更完善、稳定性更可靠。如果确实需要在云主机上自建LVS比如为了把流量统一劫持到某个Ingress网关建议选NAT模式并把Director放在与RealServer相同的VSwitch里。同时注意放通安全组规则Keepalived的健康检查源IP如果被安全组拦截探活就会误报后端故障导致节点被摘除。5.4 调优参数与监控体系最后列一下生产环境我会主动调整的内核参数参数推荐值说明net.ipv4.ip_forward1NAT模式必须开启net.ipv4.ip_nonlocal_bind1允许非本机IP绑定DR场景可能用到net.ipv4.tcp_max_syn_backlog8192提高半连接队列缓解SYN洪泛net.ipv4.tcp_tw_reuse1主动复用TIME_WAIT连接长连接转发必需net.ipv4.tcp_fin_timeout30缩短TIME_WAIT等待时间net.core.somaxconn65535提高accept队列上限监控方面LVS的指标需要用ipvsadm来采。我线上用的是Prometheus的ipvs_exporter定时执行ipvsadm -Ln --stats把每个VIP的字节数、连接数拉成时序数据。判断负载均衡器是否健康除了看入口可用性更重要的是看各后端RealServer的活跃连接数曲线是否平滑。只要有一台机器长时间活跃连接数明显高于其他机器就说明调度算法选得不对或者业务误开了会话保持。从第一次在数据中心里敲下ipvsadm -Ln到现在我已经不太记清自己配过多少套LVS了。但这些年摸爬滚打下来体会其实可以浓缩成一句话越是离业务远的基础设施越要在背后把它看牢。LVS是一个二十多年的内核态组件它的确定性让我在排查流量问题时能聚焦在配置层面而不是担心组件本身崩溃。如果你正准备在云原生环境里安排入口负载均衡我的建议是优先考虑云LB确实要自建就一定先把DR模式和NAT模式的取舍想清楚Kubernetes里的kube-proxy能上ipvs就直接上。最后那个小技巧送给你任何一次变更之后都用ipvsadm -Ln --stats和curl做一轮全链路验证别省略这一步它能省掉你未来百分之八十的排查时间。云原生流量最前面的那几公里稳了后面一路都会稳。
