通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Istio 服务网格加载项性能和缩放

  • 项目

基于 Istio 的服务网格加载项在逻辑上分为控制平面 (istiod) 和数据平面。 数据平面由工作负载 Pod 中的 Envoy 挎斗代理组成。 Istiod 管理和配置这些 Envoy 代理。 本文介绍了修订版 asm-1-19 的控制平面和数据平面的性能，包括资源消耗、挎斗容量和延迟开销。 此外，它还提供了有关解决重负载期间潜在资源压力的建议。 本文还介绍如何自定义控制平面和网关的缩放。

控制平面性能

Istiod 的 CPU 和内存要求与部署和配置更改的速率以及连接的代理数量相关。 测试的场景包括：

  • Pod 变动：检查 Pod 变动对 istiod 的影响。 为了减少变量，所有挎斗只使用一个服务。
  • 多个服务：检查多个服务对 Istiod 可以管理的最大挎斗数（挎斗容量）的影响，其中每个服务有 N 个 挎斗，总数为最大值。

测试规范

  • 一个采用默认设置的 istiod 实例
  • 已禁用 Pod 水平自动缩放
  • 使用两个网络插件进行测试：Azure 容器网络接口 (CNI) 叠加网络和包含 Cilium 的 Azure CNI 叠加网络（建议用于大型群集的网络插件）
  • 节点 SKU：标准 D16 v3（16 个 vCPU，64 GB 内存）
  • Kubernetes 版本：1.28.5
  • Istio 修订版：asm-1-19

Pod 变动

ClusterLoader2 框架用于确定 Istiod 在发生挎斗变动时可以管理的最大挎斗数量。 变动百分比定义为测试期间减少/增加的挎斗百分比。 例如，10,000 个挎斗的变动率为 50%，这意味着减少了 5,000 个挎斗，然后增加了 5,000 个挎斗。 测试的变动百分比是根据部署部署期间的典型变动百分比确定的 (maxUnavailable)。 通过确定在完成变动过程所需的实际时间内变动的挎斗总数（增加和减少）来计算变动率。

挎斗容量及 Istiod CPU 和内存

Azure CNI 叠加网络

变动百分比 变动率（挎斗数/秒） 挎斗容量 Istiod 内存 (GB) Istiod CPU
0 -- 25000 32.1 15
25 31.2 15000 22.2 15
50 31.2 15000 25.4 15

包含 Cilium 的 Azure CNI 叠加网络

变动百分比 变动率（挎斗数/秒） 挎斗容量 Istiod 内存 (GB) Istiod CPU
0 -- 30000 41.2 15
25 41.7 25000 36.1 16
50 37.9 25000 42.7 16

多个服务

ClusterLoader2 框架用于确定 istiod 可以使用 1,000 个服务管理的最大挎斗数量。 结果可与 Pod 变动场景中的 0% 变动测试（一个服务）进行比较。 每项服务有 N 个挎斗，构成了总计最大挎斗计数。 观察 API 服务器资源使用情况，以确定该加载项是否存在任何重大压力。

挎斗容量

Azure CNI 覆盖 包含 Cilium 的 Azure CNI 叠加网络
20000 20000

CPU 和内存

资源 Azure CNI 覆盖 包含 Cilium 的 Azure CNI 叠加网络
API 服务器内存 (GB) 38.9 9.7
API 服务器 CPU 6.1 4.7
Istiod 内存 (GB) 40.4 42.6
Istiod CPU 15 16

数据平面性能

有多种因素会影响挎斗性能，例如请求大小、代理工作线程数以及客户端连接数。 此外，流经网格的任何请求会先遍历客户端代理，然后遍历服务器端代理。 因此，需要度量延迟和资源消耗才能确定数据平面性能。

Fortio 用于创建负载。 测试是使用 Istio 基准存储库进行的，该存储库经过修改，以便与加载项一起使用。

测试规范

  • 使用两个网络插件进行测试：Azure CNI 叠加网络和包含 Cilium 的 Azure CNI 叠加网络（建议用于大型群集的网络插件）
  • 节点 SKU：标准 D16 v5（16 个 vCPU，64 GB 内存）
  • Kubernetes 版本：1.28.5
  • 两个代理工作线程
  • 1-KB 有效负载
  • 不同客户端连接情况下每秒 1,000 个查询 (QPS)
  • 已启用 http/1.1 协议和相互传输层安全性 (TLS)
  • 已收集 26 个数据点

CPU 和内存

在所有网络插件场景中，对于 16 个客户端连接和 1,000 QPS，客户端和服务器代理的内存和 CPU 使用率大约为 0.4 vCPU 和 72 MB。

延迟

挎斗 Envoy 代理在响应客户端后收集原始遥测数据，这不会直接影响请求的总处理时间。 但是，此过程会延迟处理下一个请求的开头，从而增加队列等待时间并影响平均和尾部延迟。 根据流量模式，实际尾部延迟会有所不同。

以下结果评估了向数据路径添加挎斗代理的影响，展示了 P90 和 P99 延迟。

  • 挎斗流量路径：客户端 --> 客户端挎斗 --> 服务器挎斗 --> 服务器
  • 基线流量路径：客户端 --> 服务器

可在此处找到不同 Istio 加载项和 AKS 版本中的数据平面延迟性能的比较。

Azure CNI 覆盖 包含 Cilium 的 Azure CNI 叠加网络
比较 Azure CNI 叠加网络的 P99 延迟的示意图。 比较包含 Cilium 的 Azure CNI 叠加网络的 P99 延迟的示意图。
比较 Azure CNI 叠加网络的 P90 延迟的示意图。 比较包含 Cilium 的 Azure CNI 叠加网络的 P90 延迟的示意图。

缩放

水平 Pod 自动缩放自定义

为 istiod 和入口网关 Pod 启用水平 Pod 自动缩放 (HPA)。 istiod 和网关的默认配置包括：

  • 副本数下限：2
  • 副本数上限：5
  • CPU 使用率：80%

注意

为防止与 PodDisruptionBudget 冲突，加载项不允许将 minReplicas 设置为低于 2 的初始默认值。

以下是 istiod 和入口网关 HPA 资源：

NAMESPACE           NAME                                         REFERENCE
aks-istio-ingress   aks-istio-ingressgateway-external-asm-1-19   Deployment/aks-istio-ingressgateway-external-asm-1-19

aks-istio-ingress   aks-istio-ingressgateway-internal-asm-1-19   Deployment/aks-istio-ingressgateway-internal-asm-1-19

aks-istio-system    istiod-asm-1-19                              Deployment/istiod-asm-1-19

HPA 配置可以通过修补程序和直接编辑进行修改。 示例：

kubectl patch hpa aks-istio-ingressgateway-external-asm-1-19 -n aks-istio-ingress --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'

注意

请参阅 Istio 加载项升级文档，以详细了解如何在 Canary 升级期间跨两个修订应用 HPA 设置。

服务条目

使用 Istio 的 ServiceEntry 自定义资源定义可将其他服务添加到 Istio 的内部服务注册表中。 ServiceEntry 允许网格中已有的服务路由或访问指定的服务。 但是，在将 resolution 字段设置为 DNS 的情况下配置多个 ServiceEntries 可能会导致域名系统 (DNS) 服务器负载过重。 以下建议有助于减轻负载：

  • 切换到 resolution: NONE 以完全避免代理 DNS 查找。 适用于大多数用例。
  • 如果你要控制所要解析的域，请增加 TTL（生存时间）。
  • 使用 exportTo 限制 ServiceEntry 范围。