2.18. 性能和可扩展性
默认 ServiceMeshControlPlane 设置不适用于生产环境，它被设计为在一个默认的 OpenShift Container Platform 安装中成功安装，默认的 OpenShift Container Platform 安装是一个有限的资源环境。在验证了成功安装 SMCP 后，您应该修改 SMCP 中定义的设置以适应您的环境。
2.18.1. 设置计算资源的限制
默认情况下, spec.proxy 具有设置 cpu:10m 和 memory:128M。如果使用 Pilot，spec.runtime.components.pilot 具有相同的默认值。
以下示例中的设置基于 1000 个服务以及每秒1000 个请求。您可以更改 ServiceMeshControlPlane 中的 cpu 和 memory 的值。
流程
-
在 OpenShift Container Platform web 控制台中，点击 Operators
Installed Operators。 - 点 Project 菜单，选择安装 Service Mesh control plane 的项目，如 istio-system。
-
点 Red Hat OpenShift Service Mesh Operator。在 Istio Service Mesh Control Plane 列中，点
ServiceMeshControlPlane的名称，例如basic。 将独立 Jaeger 实例的名称添加到
ServiceMeshControlPlane。- 点 YAML 标签。
在
ServiceMeshControlPlane资源中设置spec.proxy.runtime.container.resources.requests.cpu,spec.proxy.runtime.container.resources.requests.memory,components.kiali.container, 和components.global.oauthproxy的值。版本 2.6 ServiceMeshControlPlane 示例
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic namespace: istio-system spec: version: v2.6 proxy: runtime: container: resources: requests: cpu: 600m memory: 50Mi limits: {} runtime: components: pilot: container: resources: requests: cpu: 1000m memory: 1.6Gi limits: {} kiali: container: resources: limits: cpu: "90m" memory: "245Mi" requests: cpu: "30m" memory: "108Mi" global.oauthproxy: container: resources: requests: cpu: "101m" memory: "256Mi" limits: cpu: "201m" memory: "512Mi"- 要为 Red Hat OpenShift distributed tracing Platform (Jaeger) 设置值，请参阅"配置和部署分布式追踪平台 Jaeger"。
- 点击 Save。
验证
-
点 Reload 来验证
ServiceMeshControlPlane资源已被正确配置。
其他资源
2.18.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 有不同的性能问题。
2.18.2.1. Service Mesh Control plane 性能
Istiod 根据用户发布的配置文件和系统当前状态配置 sidecar 代理。在 Kubernetes 环境中，自定义资源定义（CRD）和部署由系统的配置和状态组成。Istio 配置对象，比如网关和虚拟服务，提供用户授权的配置。要生成代理的配置，Istiod 从 Kubernetes 环境和用户授权的配置处理组合配置和系统状态。
Service Mesh control plane 支持数千个服务，分布到成千上万的 pod，它们的用户作者虚拟服务和其他配置对象数量相似。Istiod 的 CPU 和内存要求扩展，以及配置数量和可能的系统状态。CPU 消耗扩展有以下因素：
- 部署更改率。
- 配置更改率。
- 连接到 Istiod 的代理数量。
但这部分本质上是可横向扩展的。
2.18.2.2. data plane 性能
data plane 的性能取决于多个因素，例如：
- 客户端连接数
- 目标请求率
- 请求大小和响应大小
- 代理 worker 线程的数量
- 协议
- CPU 内核
- 代理过滤器的数量和类型，特别是遥测 v2 相关的过滤器。
延迟、吞吐量以及代理的 CPU 和内存消耗作为这些因素的功能来测量。
2.18.2.2.1. CPU 和内存消耗
因为 sidecar 代理对数据路径执行额外的工作，所以它会消耗 CPU 和内存。从 Istio 1.12.3 开始，代理每秒每 1000 个请求大约消耗 0.5 个 vCPU。
代理的内存消耗取决于代理拥有的总配置状态。大量监听器、集群和路由可以增加内存用量。
因为代理通常不会缓冲传输的数据，所以请求率不会影响内存消耗。
2.18.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（超过基准数据平面的延迟）。
