×

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

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

以下示例中的设置基于 1,000 个服务和每秒 1,000 个请求。您可以更改ServiceMeshControlPlane中的cpumemory的值。

步骤
  1. 在 OpenShift Container Platform Web 控制台中,单击**运算符** → **已安装的运算符**。

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

  3. 点击 Red Hat OpenShift Service Mesh Operator。在**Istio Service Mesh 控制平面**列中,点击您的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 ms**添加到第 90 百分位延迟。

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

Service Mesh 控制平面性能

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

Service Mesh 控制平面支持数千个服务,分布在数千个 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)中,两个代理分别将约 1.7 ms 和 2.7 ms 添加到第 90 百分位和第 99 百分位延迟,超过基线数据平面延迟。