keepalived 本身不支持轮询权重，仅负责 vip 高可用；加权轮询由 haproxy 或 nginx 实现，二者分层协作实现企业级统一网关。
轮询权重本身不是 Keepalived 的原生能力，它属于七层负载均衡器（如 Nginx、HAProxy）的调度策略；Keepalived 本身不解析 HTTP 请求，也不直接支持 weight 参数做加权轮询。但你可以通过“分层协作”方式，把轮询权重逻辑交给后端负载均衡器（如 HAProxy），再由 Keepalived 为其提供 VIP 高可用保障——这才是企业级统一网关落地的关键路径。
明确角色分工：Keepalived 不做轮询，只管 VIP 生死
Keepalived 的核心职责是保障前端入口的持续在线，它通过 VRRP 协议管理一个虚拟 IP（VIP），在多个 LB 节点间自动漂移。它不处理请求分发逻辑，也不感知后端服务的权重配置。真正承担轮询、加权轮询、ip_hash 等调度策略的是运行在 LB 节点上的 HAProxy 或 Nginx。
- Keepalived 只需确保：VIP 始终绑定在一台健康的 LB 节点上
- HAProxy 负责：接收 VIP 流量，并按
balance roundrobin weight规则转发到后端 Master 或 Web 服务器 - 两者解耦部署，才能兼顾高可用性与调度灵活性
HAProxy 中实现加权轮询并接入 Keepalived
在 LB 节点上部署 HAProxy，配置 upstream 时启用 weight，例如：
backend k8s_apiserver
balance roundrobin
server master1 10.10.1.101:6443 check weight 3
server master2 10.10.1.102:6443 check weight 2
server master3 10.10.1.103:6443 check weight 1
该配置让 API Server 请求按 3:2:1 比例分发。Keepalived 则独立监听本机 HAProxy 进程健康状态（通过 Checkers 模块），一旦 HAProxy 崩溃或端口不可达，立即触发 VIP 漂移到备用 LB 节点。
- Keepalived 的 health-check 脚本可写为：
killall -0 haproxy && ss -tln | grep :6443 - 避免将 Keepalived 和 HAProxy 部署在同一台机器却共用资源——生产环境推荐 LB 节点与 Master 节点物理/网络隔离
规避脑裂与权重失效风险的实操要点
当两台 LB 节点都误判对方故障，同时抢 VIP，会导致客户端连接混乱，此时即使 HAProxy 配置了权重也失去意义——流量可能被错误导向单点。
- 必须设置
nopreempt（非抢占模式），防止主节点恢复后反复切换 - 使用双心跳通道：除默认组播外，增加单播探测 + ping 网关 + 脚本检查远端 HAProxy 状态
- VRID、优先级、认证密码三者必须严格一致，且 priority 差值建议 ≥ 50，避免因微小波动引发选举震荡
- 所有 LB 节点时间必须同步（chrony），否则 VRRP 定时器失准，易误触发切换
扩展统一网关能力：DNS 轮询 + 多 VIP 架构
单套 Keepalived 只能管理一个 VIP。若需更高吞吐或地理容灾，可部署多组 LB+Keepalived，每组分配独立 VIP，并在 DNS 层做轮询：
- www.example.com → VIP1（LB-A 主 / LB-B 备）
- www.example.com → VIP2（LB-C 主 / LB-D 备）
- 客户端 DNS 解析随机返回 VIP1 或 VIP2，天然实现流量分散
- 每组内部仍由 Keepalived 保障 VIP 不中断，HAProxy 各自按权重调度后端
这种“DNS 轮询 + Keepalived+HAProxy”三层结构，是金融、电商类企业构建统一网关的主流范式。
