1.16. 性能和可扩展性
默认 ServiceMeshControlPlane
设置不适用于生产环境,它被设计为在一个默认的 OpenShift Container Platform 安装中成功安装,默认的 OpenShift Container Platform 安装是一个有限的资源环境。在验证了成功安装 SMCP 后,您应该修改 SMCP 中定义的设置以适应您的环境。
1.16.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
的值。版本 2.4 ServiceMeshControlPlane 示例
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic namespace: istio-system spec: version: v2.4 proxy: runtime: container: resources: requests: cpu: 600m memory: 50Mi limits: {} runtime: components: pilot: container: resources: requests: cpu: 1000m memory: 1.6Gi limits: {}
- 点 Save。
-
点 Reload 来验证
ServiceMeshControlPlane
资源已被正确配置。
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(超过基准数据平面的延迟)。