OpenShift 文档正在迁移，很快将只在 docs.redhat.com（所有 Red Hat 产品文档的所在地）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

性能和可扩展性

编辑

默认的ServiceMeshControlPlane设置并非用于生产环境；它们旨在成功安装在默认的Red Hat OpenShift Service on AWS安装中，这是一个资源受限的环境。验证成功安装SMCP后，应修改SMCP中定义的设置以适应您的环境。

编辑

默认情况下，spec.proxy的设置为cpu: 10m和memory: 128M。如果您使用Pilot，spec.runtime.components.pilot具有相同的默认值。

以下示例中的设置基于1000个服务和每秒1000个请求。您可以更改ServiceMeshControlPlane中的cpu和memory的值。

步骤

  1. 在Red Hat OpenShift Service on AWS Web控制台中，单击**操作员** → **已安装的操作员**。

  2. 单击**项目**菜单并选择安装服务网格控制平面的项目，例如**istio-system**。

  3. 单击Red Hat OpenShift Service Mesh Operator。在**Istio服务网格控制平面**列中，单击您的ServiceMeshControlPlane的名称，例如basic。

  4. 将您的独立Jaeger实例的名称添加到ServiceMeshControlPlane。

    1. 单击**YAML**选项卡。

    2. 设置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"

    3. 要设置Red Hat OpenShift分布式跟踪平台（Jaeger）的值，请参见“配置和部署分布式跟踪平台Jaeger”。

    4. 单击**保存**。

验证

  • 单击**重新加载**以验证ServiceMeshControlPlane资源是否已正确配置。

负载测试结果

其他资源

上游Istio社区负载测试网格包含**1000**个服务和**2000**个sidecar，每秒有70,000个网格范围内的请求。使用Istio 1.12.3运行测试，产生了以下结果

  • Envoy代理每个通过代理的每秒1000个请求使用**0.35 vCPU**和**40 MB内存**。

  • Istiod使用**1 vCPU**和**1.5 GB**内存。

  • Envoy代理将**2.65 ms**添加到第90百分位延迟。

  • 旧版istio-telemetry服务（在Service Mesh 2.0中默认禁用）对于使用Mixer的部署，每秒使用**0.6 vCPU**处理1000个网格范围内的请求。数据平面组件（Envoy代理）处理流经系统的数据。服务网格控制平面组件Istiod配置数据平面。数据平面和控制平面具有不同的性能问题。

编辑

服务网格控制平面性能

Istiod根据用户编写的配置文件和系统的当前状态配置sidecar代理。在Kubernetes环境中，自定义资源定义（CRD）和部署构成系统的配置和状态。Istio配置对象（如网关和虚拟服务）提供用户编写的配置。为了生成代理的配置，Istiod处理来自Kubernetes环境的组合配置和系统状态以及用户编写的配置。

服务网格控制平面支持数千个服务，分布在数千个Pod中，具有类似数量的用户编写的虚拟服务和其他配置对象。Istiod的CPU和内存需求随着配置数量和可能的系统状态而变化。CPU消耗量随着以下因素而变化

  • 部署更改的速率。

  • 配置更改的速率。

  • 连接到Istiod的代理数量。

但是这部分本质上是水平可扩展的。

数据平面性能

数据平面性能取决于许多因素，例如

  • 客户端连接数

  • 目标请求速率

  • 请求大小和响应大小

  • 代理工作线程数

  • 协议

  • CPU核心数

  • 代理过滤器数量和类型，特别是与遥测v2相关的过滤器。

延迟、吞吐量以及代理的CPU和内存消耗是作为这些因素的函数来衡量的。

CPU和内存消耗

由于sidecar代理在数据路径上执行额外的工作，因此它会消耗CPU和内存。截至Istio 1.12.3，代理每秒消耗约0.5 vCPU处理1000个请求。

代理的内存消耗取决于代理持有的总配置状态。大量侦听器、集群和路由会增加内存使用量。

由于代理通常不缓冲通过的数据，因此请求速率不会影响内存消耗。

额外延迟

由于Istio在数据路径上注入sidecar代理，因此延迟是一个重要的考虑因素。Istio向代理添加身份验证过滤器、遥测过滤器和元数据交换过滤器。每个额外的过滤器都会增加代理内部的路径长度并影响延迟。

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

在服务网格内，请求会遍历客户端代理，然后是服务器端代理。在 Istio 1.12.3 的默认配置（即带有遥测 v2 的 Istio）中，这两个代理分别向基线数据平面延迟的第 90 百分位和第 99 百分位延迟增加了约 1.7 毫秒和 2.7 毫秒。