lvs与容器网络集成需解决地址可见性、路径一致性等关键问题，核心是打通宿主机ipvs与cni网络平面；主流方式包括nat（兼容性强）、dr（高性能需同二层）、tun（跨子网适用），并须处理健康检查、服务发现、连接跟踪及vip冲突等细节。
LVS 负载均衡与容器网络集成，核心在于让 LVS 的四层流量调度能力穿透容器网络的抽象层，把请求准确、高效地分发到 Pod 或容器实例上。这不是简单叠加，而是要解决地址可见性、网络路径一致性、健康检查适配和会话保持等关键问题。
LVS 与容器网络集成的关键前提
LVS 运行在宿主机内核层（IPVS 模块），而容器通常通过 CNI 插件（如 Calico、Flannel、Cilium）构建独立网络平面。二者天然隔离，所以必须打通三层互通，并确保 LVS 能“看到”后端容器的真实 IP 或可路由地址。
- 容器网络需支持 hostNetwork 模式或提供可路由的 Pod CIDR
- LVS Director（调度器）必须能直接访问 Real Server（即运行容器的节点或 Pod IP）
- 若使用 DR 或 TUN 模式，要求容器网络允许修改 MAC 或支持 IPIP 隧道（如 Calico 的 IPIP 模式）
- NAT 模式最易集成，但需注意容器节点默认网关是否指向 LVS
三种主流集成方式及适用场景
-
NAT 模式：适配度最高，适合大多数容器平台
LVS Director 作为容器集群的统一入口网关，将 VIP 请求 DNAT 到容器所在节点的 NodePort 或 HostPort 服务。- 容器服务暴露为 HostPort（如 nginx 容器监听宿主机 8080）
- LVS 规则指向各节点的
node-ip:8080，用-m参数配置 NAT - 优点：无需改动 CNI，兼容所有容器运行时（Docker、containerd、Podman）
- 注意：响应包需经 LVS SNAT 回传，吞吐受 Director 网卡带宽限制
-
DR 模式：高性能首选，需容器网络配合
要求容器 Pod IP 可被 LVS 直接路由（如使用 BGP 模式 Calico 或裸金属容器），且所有节点与 LVS 同二层网络。- 在每个容器节点的 lo 接口绑定 VIP（
ip addr add vip/32 dev lo）并关闭 ARP 响应 - LVS 使用
-g参数添加 real server，直接改写目标 MAC 发往对应节点 - 容器应用需监听 VIP + 端口（如
0.0.0.0:80），响应直接返回客户端 - 优势：零拷贝、低延迟、横向扩展性强；单集群轻松支撑数万 Pod
- 在每个容器节点的 lo 接口绑定 VIP（
-
TUN 模式：跨子网容器集群的理想选择
当容器分布在不同机房或 VPC，无法二层互通时，用 IP 隧道封装请求。- LVS 将请求封装进 IPIP 包，目的地址设为容器节点的物理 IP
- 节点内核自动解包，交付给对应 Pod（需加载
ipip模块） - Cilium、Weave 等支持隧道的 CNI 可原生配合；Flannel 默认即为 host-gw 或 vxlan，需切换为 IPIP 后启用
- 缺点：增加 20 字节隧道头开销，部分云厂商限制 IPIP 协议
实际部署中必须处理的细节
健康检查不能只 ping IP
容器可能存活但服务未就绪（如 readiness probe 失败）。LVS 自带的 TCP 端口探测不够，建议结合 kube-proxy 或自定义脚本调用 Kubernetes API 获取 Endpoint 状态，再动态更新 ipvs 规则。服务发现需与 Kubernetes 同步
不要手动写死ipvsadm -a -t vip:80 -r pod-ip:80。推荐用 operator（如 lvs-operator）监听 Endpoints/EndpointSlices 变更，实时增删 real server。连接跟踪与会话保持需调优
容器场景连接生命周期短、新建频繁，nf_conntrack_max默认值（65536）极易打满。建议：<font color="red">sysctl -w net.netfilter.nf_conntrack_max=2097152</font>
同时开启ip_vs_sh（源哈希）算法，避免同一客户端反复跳转后端。VIP 冲突防护不可少
容器节点若运行了 kube-proxy 的 iptables/ipvs 模式，会抢占相同 VIP。务必关闭 kube-proxy 的代理功能（--proxy-mode=none），或将其降级为仅管理 NodePort，由 LVS 全权接管 ClusterIP 流量。
不复杂但容易忽略
