您正在查看 Anthos Service Mesh 1.6 的文档。查看最新文档或选择其他可用版本:

解决 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 个副本)来缓解此问题,如果您希望将集群大规模纵向扩容,也可以预扩缩。