解决 Cloud Service Mesh 中的 Istiod 伸缩问题

本部分介绍常见的 Cloud Service Mesh 问题以及如何解决 。如果您需要其他帮助，请参阅获取支持。

影响扩缩的特性

Istiod 使用长期有效的 gRPC 流将配置发送到每个 Sidecar。它具有一些影响扩缩的特性：

  • 要生成的配置的大小：
    • 服务/pod 和 Istio 资源总数
    • 对于大型扩缩，调整 Sidecar 的设置可以缩减配置大小。
  • 环境中的更改速率：
    • 创建新服务或更改 Istio 配置后，系统会将完整更新发送到代理。
    • 添加新的端点以提高性能的成本很低，因为只发送增量更新。
  • 为其生成配置的代理数：
    • 受网关数和含有 Sidecar 的 pod 数量的影响。

扩缩注意事项

Istiod 可纵向扩缩（大型请求）和横向扩缩（更多副本）。确保您的 CPU 限制不会过于严格；如果 Istiod 达到 CPU 上限，则可能会出现节流，这会对配置分布产生负面影响。如果您遇到性能问题，请考虑 升级到最新版本的 Cloud Service Mesh 性能优化。

负载不平衡

由于长期有效的连接，大幅度更改集群大小可能导致暂时性的负载不平衡。您可以将连接时间上限缩短到 30 分钟来缓解这一问题，这可能导致 Envoy 中出现错误消息（例如 gRPC config stream closed: 13），从而允许负载自然地重新平衡。

您可以使用多个 Istiod 副本（默认为 2 个副本）来缓解此问题，如果您希望将集群大规模纵向扩容，也可以预扩缩。