Databricks针对Kubernetes默认负载均衡在高性能服务通信中的不足，开发了智能客户端负载均衡系统。该系统优化了流量分配，降低了延迟，提升了gRPC等持久连接场景下的服务间通信可靠性，同时保持了对用户的透明性。

智能Kubernetes负载均衡在Databricks的应用

背景

在Databricks，Kubernetes是内部系统的核心组件。虽然默认的Kubernetes网络组件（如ClusterIP服务、CoreDNS和kube-proxy）能够满足基本服务流量路由需求，但在高性能和高可靠性场景下，这些默认配置逐渐显现出局限性。

问题与挑战

Databricks内部运行着数百个无状态服务，这些服务通过gRPC进行通信，具有高吞吐量、低延迟和大规模运行的特点。默认的负载均衡模型存在以下问题：
1. 高尾延迟：由于gRPC使用HTTP/2长连接，而Kubernetes的负载均衡发生在传输层（Layer 4），导致流量分布不均，部分Pod负载过高，尾延迟增加。
2. 资源利用率低：流量分布不均使得资源需求难以预测，部分Pod资源耗尽，而其他Pod闲置，造成资源浪费。
3. 负载均衡策略有限：kube-proxy仅支持简单的轮询或随机算法，缺乏加权轮询、错误感知路由等高级策略。

解决方案：客户端负载均衡

Databricks设计了一套基于客户端的智能负载均衡系统，其核心特点包括：
1. 实时服务发现：通过自定义控制平面（Endpoint Discovery Service）监控Kubernetes API，动态更新服务端点信息。
2. 客户端集成：在Scala编写的统一RPC框架中嵌入负载均衡逻辑，客户端直接订阅控制平面的更新，绕过DNS和kube-proxy。
3. 高级负载均衡策略：
- P2C算法（二选一）：随机选择两个后端Pod，优先选择负载较低的Pod，实现均匀流量分布。
- 区域亲和性路由：优先将流量路由到同一区域的Pod，减少跨区域网络开销。
- 可插拔策略：支持灵活扩展其他负载均衡算法。

技术实现

• 控制平面：轻量级服务发现系统，实时跟踪Kubernetes中的服务和端点变化，提供xDS协议支持Envoy等代理工具。
• 客户端逻辑：客户端直接获取后端Pod的健康状态和元数据（如区域、分片标签），实现按请求的智能路由。

成效

部署后，系统在以下方面显著提升：
1. 均匀流量分布：请求均匀分配到所有后端Pod，解决了负载不均问题。
2. 稳定的延迟：P90延迟更加稳定，尾延迟行为显著减少。
3. 资源效率提升：通过减少过度配置，Pod数量降低了约20%。

挑战与经验

• 冷启动问题：新Pod立即接收流量导致性能问题，通过慢启动和错误率偏置解决。
• 指标路由的局限性：基于CPU等指标的动态路由不可靠，最终依赖更稳定的健康信号。
• 客户端库的局限性：非支持语言或依赖基础设施负载均衡的场景仍需额外处理。

替代方案评估

1. Headless服务：虽然绕过kube-proxy，但存在DNS缓存、端点权重和元数据支持不足的问题。
2. 服务网格（如Istio）：功能强大但引入额外复杂性和性能开销，与Databricks的Scala生态不匹配。

未来方向

1. 跨集群和跨区域负载均衡：探索多区域服务发现和流量管理。
2. AI场景的高级策略：支持加权负载均衡等更精细的路由决策。

Databricks正在持续优化这一系统，并欢迎对分布式基础设施感兴趣的开发者加入（招聘信息）。

这篇评论主要围绕gRPC负载均衡和服务网格的替代方案展开讨论，主要观点如下：

1. 对"Power of Two Choices"算法的兴趣

• "I found the Power of Two Choices algorithm particularly interesting"（评论1）
• 提到gRPC标准正在向"无代理"模式发展（评论1）

2. 客户端负载平衡方案的经验分享

• kuberesolver方案："we've been doing GRPC client side load balancing...It's been rock solid"（评论2）
• HTTP keepalive问题可通过配置connection-ttl缓解（评论3）

3. 对kube-proxy功能的讨论

• "if you're using ipvs, you can configure the scheduler to just about anything ipvs supports"（评论4）
• Kubernetes本身无法表示权重等细节（评论4）

4. 替代方案建议

• 建议使用rendezvous hashing："It feels like it would solve all the requirement"（评论5）
• 该方案完全客户端实现且不需要实时更新（评论5）

5. 对服务网格的看法

• "adding a service mesh is going to add operational complexity"（评论3）
• Databricks采用客户端xDS方案被认为优于服务网格的故障模式（评论3）