docker swarm入口网络ipvs调优核心是协同优化而非直接更换算法：通过副本跨节点分散、健康检查增强、dns模式控制及内核参数调整（如conntrack_max、expire_nodest_conn），并优先在docker 27+中迁移到ebpf负载均衡以获得0.35ms p99延迟。
直接调优 Docker Swarm 入口网络（Ingress）的 IPVS 负载均衡算法，是提升分布式容器网关吞吐量最有效的原生路径之一。Swarm 的 Ingress 网络底层依赖 Linux 内核的 IPVS 模块实现四层转发，其默认轮询（Round Robin）策略在高并发、长连接或异构节点场景下易出现流量倾斜和延迟堆积。真正有效的调优不是“替换算法”，而是结合 IPVS 行为特征、Swarm 运行时约束与服务部署逻辑进行协同优化。
确认并验证当前 IPVS 调度模式
Swarm 不暴露直接配置 IPVS 算法的 CLI 参数，但可通过检查节点内核规则确认实际生效的调度器：
- 在任意 Swarm 节点执行：
ipvsadm -ln，观察输出中类似tcp 10.0.0.100:80 rr的行 ——rr表示轮询，lc表示最少连接，wlc表示加权最少连接 - 若显示
rr但业务存在明显不均，说明默认策略未适配负载特征；IPVS 实际使用的算法由 Swarm 内部决策，但可通过服务约束间接引导 - 注意：Docker 27+ 已逐步用 eBPF 替代 IPVS，若已升级，
ipvsadm可能无输出，需改用bpftool map dump查看 BPF 服务端点映射
通过服务部署参数引导更优 IPVS 行为
Swarm 不允许直接指定 IPVS 算法，但可通过以下方式让 IPVS 规则天然倾向更均衡的分发效果：
- 强制副本跨节点分散：
--constraint 'node.id != {{.Node.ID}}'或使用标签 +--placement-pref 'spread=node.labels.zone'，避免多副本挤在同一节点导致 IPVS 层面“单点过载” - 启用健康感知的最小连接调度（需底层支持）：虽然 Swarm 不开放
lc开关，但当服务配置了--health-cmd且docker service ps显示状态稳定时，IPVS 会自动剔除异常后端，等效提升有效连接池质量 - 禁用 DNS 轮询干扰：
--endpoint-mode vip（默认值），确保客户端始终访问统一 VIP，由 IPVS 统一做连接分发；避免dnsrr模式下客户端缓存首个解析 IP 导致长连接集中
内核级 IPVS 参数调优（需 root 权限）
在所有管理节点和工作节点上同步调整，直接影响 Ingress 数据平面效率：
- 增大连接哈希表大小（防哈希冲突）：
echo 65536 > /proc/sys/net/netfilter/nf_conntrack_max和sysctl -w net.ipv4.vs.conn_reuse_mode=1 - 缩短连接超时以释放资源：
sysctl -w net.ipv4.vs.expire_nodest_conn=300（秒），net.ipv4.vs.expire_quiescent_template=60 - 启用连接复用加速：
sysctl -w net.ipv4.vs.conn_reuse_mode=1，对短连接密集型 API 效果显著 - 注意：这些是系统级调优，需写入
/etc/sysctl.conf并持久化，重启 docker daemon 后生效
替代方案：绕过 IPVS 直接对接 eBPF（Docker 27+ 推荐）
若运行 Docker 27 或更高版本，IPVS 已非最优路径。原生 eBPF 负载均衡提供毫秒级路由、动态权重与连接级健康感知：
- 创建服务时显式启用：
docker service create --network mynet --publish published=80,target=80,mode=host --deploy endpoint_mode=dnsrr ... - 在自定义 overlay 网络驱动选项中声明：
com.docker.network.driver.overlay.lb_mode="ebpf" - eBPF 转发延迟 P99 仅 0.35ms（对比 IPVS 的 8.2ms），且自动基于 RTT、错误率、活跃连接数计算端点权重，无需人工干预算法选择
不复杂但容易忽略：IPVS 调优本质是“让 Swarm 的默认行为更贴近真实负载特征”，而非强行切换算法。重点落在副本分布、健康检查精度、DNS 解析控制和内核连接管理上。Docker 27 后，优先迁移到 eBPF LB 是吞吐提升最确定的路径。
