解决 Anthos Service Mesh 中的 Istiod 扩缩问题
本部分介绍常见的 Anthos Service Mesh 问题以及如何解决这些问题。如果您需要其他帮助,请参阅获取支持。
影响扩缩的特性
Istiod 使用长期有效的 gRPC 流将配置发送到每个 Sidecar。它具有一些影响扩缩的特性:
- 要生成的配置的大小:
- 服务/pod 和 Istio 资源总数
- 对于大型扩缩,调整 Sidecar 的设置可以缩减配置大小。
- 环境中的更改速率:
- 创建新服务或更改 Istio 配置后,系统会将完整更新发送到代理。
- 添加新的端点以提高性能的成本很低,因为只发送增量更新。
- 为其生成配置的代理数:
- 受网关数和含有 Sidecar 的 pod 数量的影响。
扩缩注意事项
Istiod 可纵向扩缩(大型请求)和横向扩缩(更多副本)。确保您的 CPU 限制不会过于严格;如果 Istiod 达到 CPU 上限,则可能会出现节流,这会对配置分布产生负面影响。如果遇到性能问题,请考虑升级到最新版本的 Anthos Service Mesh,因为每个版本都会进行性能优化。
负载不平衡
由于长期有效的连接,大幅度更改集群大小可能导致暂时性的负载不平衡。您可以将连接时间上限缩短到 30 分钟来缓解这一问题,这可能导致 Envoy 中出现错误消息(例如 gRPC config stream
closed: 13
),从而允许负载自然地重新平衡。
您可以使用多个 Istiod 副本(默认为 2 个副本)来缓解此问题,如果您希望将集群大规模纵向扩容,也可以预扩缩。