容器集群负载均衡是分层机制：云平台lb作外部入口，k8s service/kube-proxy负责内部分发（推荐ipvs模式），客户端lb（如spring cloud）实现微服务直连；三者协同工作。
容器集群中的负载均衡器（LoadBalancer）不是单一组件，而是分层协作的机制，核心在于“谁做分发”和“怎么分发”。它既包含云平台提供的外部入口（如 ELB、ALB），也涵盖 Kubernetes 内部的服务抽象（Service + kube-proxy），还涉及客户端侧的智能路由（如 Spring Cloud LoadBalancer）。三者定位不同，常组合使用。
云厂商 LB 作为外部流量入口
在公有云环境（如华为云 CCE、AWS EKS、阿里云 ACK），LoadBalancer 类型的 Service 会触发云平台自动创建一个托管型负载均衡器（如 ELB、NLB）。该 LB 实际运行在集群外部，具备独立 VIP 和高可用架构（通常由 Keepalived + LVS + HAProxy 构成主备节点）。它接收公网或私网请求，按监听器配置（协议/端口）转发到集群节点或直通 Pod：
- 传统模式：流量 → ELB → 节点 NodePort → kube-proxy（iptables/ipvs）→ Pod
- 直连 Pod 模式（CCE Turbo/VPC-CNI）：ELB 直接将流量发往 Pod 的弹性网卡 IP，绕过节点转发，降低时延、保留源 IP、支持 Pod 级健康检查
- 要求集群网络插件支持（如 VPC-CNI 弹性网卡模式），且 ELB 规格需匹配协议类型（TCP/UDP 或 HTTP/HTTPS）
Kubernetes Service 与 kube-proxy 的内部分发
LoadBalancer 类型 Service 本质是 ClusterIP 的扩展，其背后仍依赖 kube-proxy 实现服务发现与流量落地。kube-proxy 在每个节点上运行，通过两种主流模式将“虚拟服务 IP”映射到真实 Pod：
- iptables 模式：生成大量 NAT 规则链，简单但规则膨胀快、更新延迟高；适用于中小规模集群
- ipvs 模式（推荐）：基于 Linux 内核 LVS，支持加权轮询（WRR）、最小连接（LC）等算法，10 万并发下延迟比 iptables 低 60%，CPU 占用减少 45%
无论哪种模式，Service 的 selector 机制决定了哪些 Pod 被纳入后端池，而健康状态由 kubelet 定期探针（liveness/readiness）保障 —— 不健康的 Pod 会被自动从 endpoints 列表中剔除。
客户端负载均衡器（如 Spring Cloud LoadBalancer）
在微服务调用链路中，服务消费者（如 order-service）若使用 @LoadBalanced RestTemplate 或 OpenFeign，实际执行的是客户端负载均衡：
- 调用 http://user-service/api 用户接口时，请求被 LoadBalancerInterceptor 拦截
- 从注册中心（Nacos/Eureka）拉取 user-service 的全部实例列表，并本地缓存
- 按策略（默认 RoundRobinLoadBalancer）选择一个可用实例，将服务名替换为 IP:Port 后发起真实 HTTP 请求
- 全程无中间代理，不依赖 Nginx 或集群 LB，扩展性好、故障隔离强，但需应用自身集成并管理实例缓存与刷新逻辑
关键协同与选型建议
真实生产环境往往多层叠加：
- 外网用户 → 云 LB（负责 TLS 终结、DDoS 防护、全局健康检查）→ Service（负责集群内服务发现与基础转发）→ Pod
- 内部微服务间调用 → 直接走 Spring Cloud LoadBalancer（减少跳转、提升响应速度）
- 对源 IP、会话保持、细粒度健康检查有强需求时，优先启用 ELB 直连 Pod 模式
- 大规模集群建议启用 ipvs + externalTrafficPolicy: Local，避免 SNAT，便于审计与限流
