1.16. 性能和可扩展性

默认 ServiceMeshControlPlane 设置不适用于生产环境，它被设计为在一个默认的 OpenShift Container Platform 安装中成功安装，默认的 OpenShift Container Platform 安装是一个有限的资源环境。在验证了成功安装 SMCP 后，您应该修改 SMCP 中定义的设置以适应您的环境。

1.16.2. 加载测试结果

上游 Istio 社区负载测试网格由 1000 个服务和 2000 个 sidecars，带有 70,000 个网格范围请求每秒组成。使用 Istio 1.12.3 运行测试，生成以下结果：

  • Envoy 代理每秒每 1000 个通过代理的请求使用 0.35 vCPU 和 40 MB 内存。
  • Istiod 使用 1 vCPU 和 1.5 GB 内存。
  • Envoy 代理对 90th percentile 延迟增加了 2.65 ms。
  • 传统的 istio-telemetry 服务（在 Service Mesh 2.0 中默认禁用）用于使用 Mixer 的部署，每 1000 网格范围内请求每秒使用 0.6 vCPU 请求。数据平面组件（Envoy 代理）处理通过系统的数据流。Service Mesh control plane 组件 Istiod 配置数据平面（data plane）。data plane 和 control plane 有不同的性能问题。

1.16.2.1. Service Mesh Control plane 性能

Istiod 根据用户发布的配置文件和系统当前状态配置 sidecar 代理。在 Kubernetes 环境中，自定义资源定义（CRD）和部署由系统的配置和状态组成。Istio 配置对象，比如网关和虚拟服务，提供用户授权的配置。要生成代理的配置，Istiod 从 Kubernetes 环境和用户授权的配置处理组合配置和系统状态。

Service Mesh control plane 支持数千个服务，分布到成千上万的 pod，它们的用户作者虚拟服务和其他配置对象数量相似。Istiod 的 CPU 和内存要求扩展，以及配置数量和可能的系统状态。CPU 消耗扩展有以下因素：

  • 部署更改率。
  • 配置更改率。
  • 连接到 Istiod 的代理数量。

但这部分本质上是可横向扩展的。

1.16.2.2. data plane 性能

data plane 的性能取决于多个因素，例如：

  • 客户端连接数
  • 目标请求率
  • 请求大小和响应大小
  • 代理 worker 线程的数量
  • 协议
  • CPU 内核
  • 代理过滤器的数量和类型，特别是遥测 v2 相关的过滤器。

延迟、吞吐量以及代理的 CPU 和内存消耗作为这些因素的功能来测量。

1.16.2.2.1. CPU 和内存消耗

因为 sidecar 代理对数据路径执行额外的工作，所以它会消耗 CPU 和内存。从 Istio 1.12.3 开始，代理每秒每 1000 个请求大约消耗 0.5 个 vCPU。

代理的内存消耗取决于代理拥有的总配置状态。大量监听器、集群和路由可以增加内存用量。

因为代理通常不会缓冲传输的数据，所以请求率不会影响内存消耗。

1.16.2.2.2. 额外的延迟

因为 Istio 在数据路径上注入 sidecar 代理，所以延迟是一个重要因素。Istio 向代理添加验证过滤器、遥测过滤器和元数据交换过滤器。每个附加过滤器都会添加到代理内的路径长度中，并影响延迟。

Envoy 代理会在向客户端发送响应后收集原始遥测数据。为请求收集原始遥测所花的时间不会造成完成该请求的总时间。但是，由于 worker 忙于处理请求，因此 worker 不会立即开始处理下一个请求。这个过程为下一个请求的队列等待时间添加，并影响平均延迟和尾部延迟。实际的尾部延迟取决于流量模式。

在网格中，请求会绕过客户端代理，然后是服务器端代理。在 Istio 1.12.3（Istio 带有 telemetry v2）的默认配置中，两个代理会对 90th 和 99th percentile 延迟分布增加 1.7 ms 和 2.7 ms（超过基准数据平面的延迟）。