×

默认的ServiceMeshControlPlane设置并非用于生产环境;它们旨在成功安装在资源有限的默认 OpenShift Dedicated 安装中。验证成功安装 SMCP 后,应修改 SMCP 中定义的设置以适应您的环境。

默认情况下,spec.proxy 的设置是cpu: 10mmemory: 128M。如果您使用的是 Pilot,则spec.runtime.components.pilot具有相同的默认值。

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

步骤
  1. 在 OpenShift Dedicated Web 控制台中,单击**操作符** → **已安装的操作符**。

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

  3. 单击 Red Hat OpenShift 服务网格操作符。在**Istio 服务网格控制平面**列中,单击您的ServiceMeshControlPlane 的名称,例如basic

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

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

    2. 在您的ServiceMeshControlPlane 资源中设置spec.proxy.runtime.container.resources.requests.cpuspec.proxy.runtime.container.resources.requests.memorycomponents.kiali.containercomponents.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 毫秒**添加到第 90 百分位延迟。

  • 旧版istio-telemetry服务(在服务网格 2.0 中默认禁用)对使用 Mixer 的部署使用每秒 1000 个网格范围请求**0.6 vCPU**。数据平面组件(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 毫秒,超过了基线数据平面延迟。