使用多集群 Istio - Devarajan Ramaswamy & Nizam Uddin 扩展到 1M RPS

IstioCon使用多集群 Istio 扩展到 1M RPS

期望要求

• 系统应能够处理500k RPS，延迟（p99）低于最坏情况中位响应时间的500%。
• 系统应展现出处理高达1m RPS（约2.5m用户）的能力。
• 用户发送http/1请求并保持连接打开，通过增加连接用户数量实现流量增加。
• 系统应自动扩展，并保持高吞吐量。

设置与拓扑

• 两个Kubernetes集群（A和B）使用Istio 1.9.8安装，包含应用服务。
• Locust服务器（主从模式）生成面向连接的HTTP流量负载。
• 负载发电机应用程序由“用户”和“产品”微服务组成，模拟create、get和getAll方法。

最小情况 ~ 1000 RPS

• 部署所有服务到一个pod中测试系统极限。
• 增加用户数量至约4000（约700 RPS）时，延迟开始增加并波动显著。

优化措施

1. 降低跟踪采样率
   • 安装默认的1%抽样率过于冗余，降低到0.01%。
2. 升级到HTTP/2
   • 复用多个请求，避免连接创建开销。

自动扩展问题

• 随着吞吐量提高，pod数量自动增加，但响应时间图表出现锯齿状波动。

第2阶段负载 > 5000 RPS

• 资源优化
  • 隔离节点池，优化资源请求、限制和HPA设置。
  • 分离控制平面和数据平面流量的节点池。
  • 首选pod反亲和力，均匀分布pod。
• 负载平衡策略
  • 最少请求数（least_request）策略优于轮询（round_robin）。
• 下游连接限制
  • 限制入口网关并发性至6个线程，避免核心数量有限导致的延迟增加。
• 工作线程之间的连接平衡
  • 下游连接分布不均导致部分线程负载过大，优化连接平衡。

第3阶段负载 > 25000 RPS

• 跨群集端点发现问题
  • 客户端代理仅看到一个NLB终结点，导致连接分布不均。
  • 跃点过多，NodePort方法效果最佳。
• 临时跨群集端点发现解决方案
  • 将远程网关公开为NodePort类型服务。
  • 调整MaxRequestsPerConnection，轻微影响延迟但改善连接分配。

满载 500,000 RPS

• NodePort方法实现更好的负载平衡，但频繁断开连接导致轻微延迟增加。
• NLB情况下，稳态连接分配略微变差，但整体延迟影响轻微。