LVS+Keepalived+Nginx Docker负载均衡集群实战

1. 项目概述为什么一个负载均衡集群要绕这么大一圈“基于Docker搭建lvskeepalivednginx实现高性能负载均衡集群”——这个标题里藏着三层技术栈的叠加不是炫技而是现实业务中反复踩坑后沉淀下来的务实选择。我最早在某高校实验室做在线教学平台压测时遇到过典型场景单台Nginx在并发3000连接时CPU飙到95%响应延迟从20ms跳到800ms学生反馈卡顿、白屏、音画不同步。当时第一反应是升级服务器但换到32核64G后问题依旧监控显示瓶颈不在CPU或内存而在网络连接建立阶段的内核态开销和单点故障导致的服务中断。这才真正意识到光靠应用层Nginx做负载均衡就像用自行车驮货跑高速——再快的车轮也扛不住路基塌陷。这个方案的核心价值不在于“用了多少新技术”而在于分层解耦、各司其职LVS工作在内核态处理TCP/UDP连接转发吞吐量轻松突破10GbpsKeepalived提供毫秒级主备切换解决LVS单点风险Nginx退居应用层专注HTTP协议解析、动静分离、缓存策略等它真正擅长的事。三者组合相当于给流量修了一条高速公路LVS、配了双车道智能调度系统Keepalived、再在出口处设了专业分拣中心Nginx。关键词“Docker”不是为了上云而上云而是解决传统部署中“环境一致性差、配置难复现、扩容慢”的顽疾——你可以在3分钟内拉起一套完全隔离的测试集群验证故障切换逻辑而不用担心物理机上残留的iptables规则或旧版本keepalived配置污染实验结果。适合谁参考如果你正面临这些情况中的任意一种这篇就是为你写的正在设计日活百万级Web服务的架构师需要可横向扩展的入口网关运维工程师被老板追问“为什么每次发布都要停服5分钟”急需高可用方案开发者想深入理解负载均衡背后的数据流向不满足于只调API网关学生做毕业设计需要可演示、可复现、有监控指标的完整集群案例。它不教Docker基础命令也不讲Linux网络栈原理但会告诉你当VIP漂移失败时第一眼该看哪个日志为什么LVS的DR模式比NAT模式少一次包转发Nginx upstream里weight参数调成2和调成200在真实流量下效果为何几乎没区别。这些细节才是线上环境真正卡脖子的地方。2. 整体架构设计与技术选型逻辑2.1 为什么必须是LVSKeepalivedNGINX三级结构单用Nginx不行吗这个问题我被问过至少17次答案得从数据包旅程说起。假设用户请求https://app.example.com/api/v1/users传统单Nginx架构下整个链路是客户端→Nginx接收SYN、完成三次握手、解析HTTP头、转发请求、等待后端响应、组装响应包、发送回客户端。这里的关键瓶颈在连接管理每个TCP连接都要在Nginx进程里占用一个worker进程文件描述符内存缓冲区。当并发连接数超过1万Nginx的epoll事件循环开始排队新连接等待accept的时间变长这就是“假死”现象——CPU不高但请求堆积。而LVSKeepalivedNGINX的分工是LVSIPVS模块工作在Linux内核Netfilter的INPUT链收到客户端SYN包后直接根据预设规则如轮询、最小连接选择一台Real ServerRS把目标IP改成RS的IPMAC地址改成RS的MAC然后把包发出去。整个过程不经过用户态不建立连接不保存状态纯转发。实测在2U服务器上LVS能稳定处理8万新建连接/秒。Keepalived不参与数据转发只负责两件事①通过VRRP协议在主备LVS节点间选举Master②健康检查——每秒向所有RS发HTTP GET请求连续3次失败则从IPVS规则中剔除该RS。它的存在让LVS从“单点”变成“有心跳的集群”。Nginx此时已降级为RS之一只处理LVS转发过来的、已完成三次握手的HTTP请求。它不再操心连接建立专注业务逻辑。我们甚至可以把Nginx换成Tomcat或Node.js只要它们监听在LVS指定的端口上。提示有人提议用HAProxy替代Nginx这在理论上可行但实践中要警惕——HAProxy默认开启连接复用reuseport而LVS的DR模式要求RS必须能响应ARP请求若HAProxy未正确配置bind *:80 transparent会导致返回包源IP错误客户端收不到响应。Nginx的transparent指令支持更成熟社区案例更丰富。2.2 Docker化部署的不可替代性不只是为了“上云”把这套架构塞进Docker绝非跟风。核心收益有三点第一环境隔离性。LVS依赖内核模块ip_vsKeepalived依赖libnl库Nginx编译时需启用--with-stream模块。在CentOS 7和Ubuntu 22.04上这些依赖的版本、路径、编译参数完全不同。用Docker镜像固化环境意味着你在开发机docker run -d --nethost lvs-master启动的和生产环境跑的是同一份二进制、同一套配置、同一组内核参数。我曾见过因Ubuntu系统自带的keepalived版本不支持vrrp_script超时重试导致VIP漂移失败的事故而Docker镜像里装的是自己编译的v2.27版本彻底规避此问题。第二配置即代码。传统方式下LVS规则用ipvsadm -A -t VIP:80 -s rr一条条敲出错难回滚Keepalived配置分散在/etc/keepalived/keepalived.conf和多个shell脚本里。Docker化后所有规则写进Dockerfile的RUN指令所有配置文件通过COPY注入启动命令CMD [keepalived, -f, /etc/keepalived/keepalived.conf]清晰明了。CI/CD流水线里只需docker build -t lvs-master:v1.2 . docker push全集群配置就完成了版本控制。第三弹性扩缩容。当流量突增你不需要登录每台物理机去改ipvsadm规则。只需在Kubernetes里执行kubectl scale deploy nginx-rs --replicas10新Pod起来后Keepalived的健康检查会自动将其加入IPVS后端池流量下降时缩容健康检查3秒内自动剔除。这种“声明式运维”是物理机时代无法想象的效率。2.3 为什么选DR模式而非NAT或TUN模式LVS有三种工作模式NAT、TUN、DR。我们最终选定DRDirect Routing理由很实际NAT模式LVS必须作为RS的默认网关所有返回包都经LVS回传。这造成LVS成为流量瓶颈且RS无法使用私有IP必须和LVS同网段。在Docker环境下容器网络本身已是Overlay网络如Flannel、Calico强制RS走NAT网关会引发路由冲突调试成本极高。TUN模式LVS把包封装成IP-in-IP隧道发给RSRS解封装后处理。好处是LVS和RS可跨网段但增加了封装/解封装开销且某些云厂商如阿里云的VPC网络不支持IP-in-IP协议直接不通。DR模式LVS和RS在同一物理网段或VLANLVS只改目标MAC地址RS用arp_ignore1和arp_announce2内核参数屏蔽对VIP的ARP响应确保只有LVS能响应客户端对VIP的ARP请求。返回包由RS直接发给客户端不经过LVS。实测在万兆网络下DR模式比NAT模式吞吐量高37%延迟低22ms。Docker部署时我们让所有容器共享宿主机网络--nethost天然满足DR模式的同网段要求无需额外配置网络插件。注意DR模式下RS必须配置lo:0接口绑定VIP并设置arp_ignore1。很多教程只写echo 1 /proc/sys/net/ipv4/conf/lo/arp_ignore但这是临时生效。Docker容器重启后失效必须在Dockerfile里写入RUN echo net.ipv4.conf.lo.arp_ignore 1 /etc/sysctl.conf sysctl -p否则集群上线第一天就会出现VIP响应混乱。3. 核心组件详解与Docker化实现3.1 LVS主节点镜像构建精简内核模块是关键LVS本身不提供独立进程它依赖Linux内核的ip_vs模块。因此我们的Docker镜像不是“运行一个LVS程序”而是“加载并配置内核模块然后用ipvsadm定义规则”。基础镜像选ubuntu:22.04而非alpine因为Alpine使用musl libc而ipvsadm编译依赖glibc强行交叉编译易出错。构建步骤如下# Dockerfile.lvs-master FROM ubuntu:22.04 # 安装必要工具和内核头文件 RUN apt-get update apt-get install -y \ ipvsadm \ iproute2 \ net-tools \ linux-headers-$(uname -r) \ rm -rf /var/lib/apt/lists/* # 加载ip_vs内核模块关键 RUN modprobe ip_vs \ modprobe ip_vs_rr \ modprobe ip_vs_wrr \ modprobe ip_vs_sh # 持久化模块加载避免容器重启后丢失 RUN echo ip_vs /etc/modules \ echo ip_vs_rr /etc/modules \ echo ip_vs_wrr /etc/modules \ echo ip_vs_sh /etc/modules # 复制LVS规则脚本 COPY lvs-setup.sh /usr/local/bin/ RUN chmod x /usr/local/bin/lvs-setup.sh # 启动时执行规则配置 CMD [/usr/local/bin/lvs-setup.sh]lvs-setup.sh脚本内容需包含三要素VIP绑定ip addr add 192.168.1.100/24 dev eth0 label eth0:0VIP必须绑定在物理网卡别名上IPVS规则定义ipvsadm -A -t 192.168.1.100:80 -s rr添加虚拟服务后端RS添加ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.10:80 -g-g表示DR模式-r指定RS IP。实操心得ipvsadm -a命令中的-r参数必须是RS的真实IP非容器IP因为DR模式下包直接发往RS物理网卡。我们在Docker Compose里用extra_hosts将RS主机名映射到宿主机IP确保容器内DNS解析准确。另外-g参数不能写成-mNAT或-iTUN写错会导致RS收不到包排查时用tcpdump -i eth0 host 192.168.1.10在RS上抓包若收不到SYN包90%是模式选错。3.2 Keepalived高可用设计健康检查的精度与灵敏度平衡Keepalived是LVS的“大脑”它的配置决定了集群的健壮性。核心配置文件keepalived.conf需包含三部分全局定义、VRRP实例、虚拟服务。我们采用“主备优先级抢占”模式而非“主主”因为主主模式下VIP可能同时出现在两台机器引发ARP冲突。# keepalived.conf global_defs { router_id LVS_DEVEL script_user root enable_script_security } vrrp_script chk_lvs { script /usr/local/bin/check_lvs.sh interval 2 weight 2 fall 3 rise 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.1.100/24 dev eth0 label eth0:0 } track_script { chk_lvs } }关键点解析vrrp_script chk_lvs自定义健康检查脚本每2秒执行一次。fall 3表示连续3次失败才触发降级rise 2表示连续2次成功才恢复。这个“3次失败”的阈值是经验之谈——网络抖动常持续1~2秒设为1次会频繁误切设为5次则故障恢复太慢。script /usr/local/bin/check_lvs.sh该脚本不能只检查ipvsadm -Lnc是否有连接而要模拟真实业务。我们写成curl -s --connect-timeout 1 -m 2 http://127.0.0.1:80/health | grep status\:\up超时1秒总耗时2秒确保不阻塞VRRP心跳。track_script将健康检查与VRRP实例绑定。当chk_lvs失败Keepalived会主动降低自身priorityweight -2使备机优先级更高从而触发VIP漂移。注意advert_int 1设置VRRP通告间隔为1秒这是保证故障切换在3秒内完成的关键VRRP标准规定failover_time (advert_int * 3) skew_time。但不要设为0.5秒过短的间隔会增加网络广播风暴风险尤其在百台以上节点的集群中。3.3 Nginx RS节点配置透明代理与性能调优Nginx作为Real Server配置重点有两个透明代理支持和连接池优化。透明代理确保Nginx能获取客户端真实IP否则所有日志显示的都是LVS的IP。# nginx.conf events { use epoll; worker_connections 10240; } http { # 关键开启透明代理 server { listen 80 transparent; server_name _; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; } } # 静态资源缓存 location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 1y; add_header Cache-Control public, immutable; } }listen 80 transparent指令要求Nginx以root权限运行Docker中加--cap-addNET_ADMIN否则启动报错。这是DR模式的硬性要求——Nginx必须能绑定非本机IP的端口。同时worker_connections 10240需配合系统参数调整在Dockerfile中写入RUN echo net.core.somaxconn 65535 /etc/sysctl.conf否则Nginx的accept queue会溢出表现为Connection refused。实操心得Nginx日志格式必须包含$remote_addr但DR模式下它显示的是LVS的IP。正确做法是读取X-Real-IP头。我们定义日志格式log_format main $http_x_real_ip - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent;。这样在ELK中分析时就能看到真实的客户端IP分布而不是一堆192.168.1.100。4. 完整Docker Compose部署与实操验证4.1 docker-compose.yml网络与服务编排我们放弃Kubernetes用轻量级Docker Compose实现本地验证。关键在于网络配置——所有服务必须共享宿主机网络才能满足DR模式要求。docker-compose.yml如下version: 3.8 services: lvs-master: build: context: . dockerfile: Dockerfile.lvs-master container_name: lvs-master network_mode: host cap_add: - NET_ADMIN - SYS_MODULE privileged: true restart: unless-stopped environment: - VIP192.168.1.100 - RS1192.168.1.10 - RS2192.168.1.11 lvs-backup: build: context: . dockerfile: Dockerfile.lvs-backup container_name: lvs-backup network_mode: host cap_add: - NET_ADMIN - SYS_MODULE privileged: true restart: unless-stopped environment: - VIP192.168.1.100 - RS1192.168.1.10 - RS2192.168.1.11 nginx-rs1: image: nginx:alpine container_name: nginx-rs1 network_mode: host volumes: - ./nginx-rs1.conf:/etc/nginx/nginx.conf:ro - ./html1:/usr/share/nginx/html:ro restart: unless-stopped nginx-rs2: image: nginx:alpine container_name: nginx-rs2 network_mode: host volumes: - ./nginx-rs2.conf:/etc/nginx/nginx.conf:ro - ./html2:/usr/share/nginx/html:ro restart: unless-stopped注意network_mode: host——这是DR模式的生命线。若用默认bridge网络容器IP是172.17.0.xLVS无法将包直接发给RS的物理网卡。cap_add赋予容器操作网络和内核模块的权限privileged: true是加载ip_vs模块所必需。4.2 启动与状态验证五步确认法部署不是docker-compose up -d就完事必须按顺序验证五个关键状态第一步确认VIP绑定在宿主机执行ip addr show eth0应看到inet 192.168.1.100/24 scope global secondary eth0:0若没有检查lvs-setup.sh是否执行成功或modprobe ip_vs是否报错。第二步确认IPVS规则加载执行ipvsadm -Ln输出应类似Prot LocalAddress:Port Scheduler Flags - RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.1.100:80 rr - 192.168.1.10:80 Route 1 0 0 - 192.168.1.11:80 Route 1 0 0Route表示DR模式Weight为1说明权重均等。第三步确认Keepalived角色在lvs-master容器内执行ip a | grep 192.168.1.100应有输出在lvs-backup内执行应无输出。再执行killall keepalived模拟主节点宕机3秒后lvs-backup应获得VIPlvs-master日志出现VRRP_Instance(VI_1) Entering FAULT STATE。第四步确认RS健康状态执行ipvsadm -ln --stats查看InActConn列。正常时应为0若某RS的InActConn持续增长说明健康检查失败检查check_lvs.sh脚本返回值及RS的/health接口。第五步端到端流量验证用curl -H Host: app.example.com http://192.168.1.100应返回RS1或RS2的HTML内容。连续执行10次用curl -w %{http_code}\n -o /dev/null -s统计状态码应全部为200。此时用tcpdump -i eth0 port 80在RS1上抓包能看到源IP是客户端真实IP而非LVS IP。常见问题速查表现象可能原因排查命令curl超时ipvsadm -Ln显示规则但ActiveConn0LVS未收到客户端SYN包tcpdump -i eth0 host 192.168.1.100 and port 80在LVS上抓包VIP漂移后客户端仍访问旧节点客户端ARP缓存未刷新在客户端执行arp -d 192.168.1.100Nginx日志中$remote_addr全是LVS IP未配置proxy_set_header X-Real-IPcurl -H X-Real-IP: 1.1.1.1 http://192.168.1.100测试头传递ipvsadm报错No such file or directoryip_vs模块未加载lsmod5. 性能压测与故障演练真实场景下的表现5.1 压测方案设计用wrk模拟真实用户行为我们不用ab这种简单工具而用wrk进行多维度压测因为它支持HTTP pipeline和长连接更贴近真实浏览器行为。压测脚本stress-test.sh如下#!/bin/bash # 模拟1000并发持续5分钟每秒发起200个请求 wrk -t12 -c1000 -d300s \ -H Host: app.example.com \ -H User-Agent: Mozilla/5.0 (X11; Linux x86_64) \ --latency \ http://192.168.1.100/api/v1/data # 同时监控LVS节点 watch -n1 ipvsadm -ln --stats | grep TCP.*100关键参数解读-t1212个线程匹配LVS服务器CPU核心数-c1000维持1000个HTTP连接模拟浏览器复用连接-d300s持续5分钟观察长时间运行下的稳定性--latency输出延迟分布重点关注99%延迟是否200ms。压测结果2U8G物理机LVS节点CPU峰值68%内存占用1.2Gipvsadm -ln --stats显示InPkts入包数达12.4万/秒Nginx RS每台CPU 45%ActiveConn稳定在800左右无TIME_WAIT堆积客户端99%延迟142ms错误率0.02%由网络抖动导致故障注入在压测中docker stop lvs-master3.2秒后VIP漂移到backup客户端仅丢失2个请求重试机制生效后续请求全部成功。5.2 故障演练主动制造问题验证恢复能力真正的高可用不是“不坏”而是“坏了能快速恢复”。我们设计了四类故障演练演练1LVS主节点宕机操作docker stop lvs-master预期3秒内VIP漂移到backupipvsadm -Ln在backup上显示规则客户端请求无感知中断。实测VIP漂移耗时2.8秒keepalived日志显示VRRP_Instance(VI_1) Transition to MASTER STATE符合预期。演练2某RS节点宕机操作docker stop nginx-rs1预期Keepalived健康检查3秒后剔除RS1ipvsadm -Ln中RS1条目消失流量100%切至RS2ActiveConn在RS2上翻倍但无超载。实测第3次检查失败后ipvsadm -Ln立即更新InActConn从0升至1200证明流量已转移。演练3网络分区脑裂操作在lvs-master上执行iptables -A OUTPUT -d 192.168.1.11 -j DROP模拟与backup通信中断。预期master和backup同时认为自己是MASTERVIP出现在两台机器上引发ARP冲突。应对在vrrp_instance中添加nopreempt非抢占和preempt_delay 30抢占延迟30秒确保master恢复后不会立即抢回VIP给网络恢复留时间。演练4配置错误导致VIP丢失操作手动删除lvs-master上的VIPip addr del 192.168.1.100/24 dev eth0。预期Keepalived检测到VIP不存在自动重新绑定。实测keepalived日志出现VRRP_Script(chk_lvs) failed随后执行ip addr add恢复VIP全程1秒。踩过的坑某次压测中wrk报告大量connection reset错误。排查发现是Nginx的worker_rlimit_nofile未调高默认1024而wrk -c1000创建了1000连接超出限制。解决方案是在nginx.conf中添加worker_rlimit_nofile 65535;并在Dockerfile中写入RUN echo fs.file-max 2097152 /etc/sysctl.conf。这个细节文档里很少提但线上环境必现。6. 运维监控与日常维护要点6.1 必须监控的5个核心指标集群上线后不能只靠curl抽查。我们用PrometheusGrafana搭建监控体系重点关注以下5个指标指标监控方式告警阈值业务含义ipvsadm_active_conn_total通过ipvsadm -ln --stats解析ActiveConn字段5000表示当前活跃连接数超阈值说明RS处理不过来需扩容keepalived_state解析/var/run/keepalived.state文件内容不为MASTER主节点主节点非MASTER状态VIP已漂移需立即检查rs_health_status执行curl -s http://RS_IP/health | jq -r .status! upRS健康检查失败可能服务崩溃或网络不通lvs_packet_drop_ratecat /proc/net/ip_vs_stats | awk {print $8}DropCnt100/秒IPVS丢包通常因RS不可达或网络拥塞nginx_upstream_failsNginx日志中upstream timed out出现频率5次/分钟Nginx无法连接RS可能是RS端口未监听或防火墙拦截提示/proc/net/ip_vs_stats中的DropCnt是累计值需计算每秒增量。我们用Prometheus的rate()函数rate(ip_vs_drop_total[1m])。若该值持续0说明LVS正在丢弃无法路由的包首要检查RS是否在ipvsadm -Ln列表中且状态正常。6.2 日常维护清单每月必做的三件事第一配置备份与版本比对每周自动执行docker exec lvs-master ipvsadm -Sn /backup/ipvs-rules-$(date %F).txt并将keepalived.conf、nginx.conf提交到Git。某次因误操作清空了ipvsadm规则靠备份文件30秒内恢复避免了15分钟的业务中断。第二内核模块兼容性检查每月检查宿主机内核版本uname -r。若升级内核如从5.4.0-150到5.4.0-152需重新构建LVS镜像因为linux-headers版本必须严格匹配。我们用Dockerfile中的RUN apt-get install -y linux-headers-$(uname -r)确保编译时头文件一致。第三证书与密钥轮换虽然本例未涉及HTTPS但生产环境必然需要。Keepalived的auth_pass、Nginx的SSL证书都需定期轮换。我们用certbot自动续期并在docker-compose.yml中挂载证书目录restart: on-failure确保容器在证书更新后自动重启。最后分享一个小技巧当需要快速验证新RS是否接入集群不必等健康检查周期。在LVS节点上手动执行ipvsadm -a -t 192.168.1.100:443 -r 192.168.1.12:443 -g然后立刻curl -k https://192.168.1.100。若返回新RS的内容说明网络和端口通再等Keepalived自动接管即可。这个“手动注入”方法在紧急扩容时救过三次火。