2.3. OpenShift Serverless Serving 扩展和性能

• 170 Knative Services
• 每个 Knative Service 的 1-2 个修订版本
• 89 测试场景主要侧重于测试 control plane
• 48 重新创建 Knative Services 被删除并重新创建的情况
• 41 稳定场景，在请求速度缓慢但持续发送到系统

流程

• 您可以使用 KnativeServing 自定义资源(CR)为最小工作负载配置 Knative Serving：

  KnativeServing CR 中的最小工作负载配置

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    high-availability:
      replicas: 1 1
    workloads:
      - name: activator
        replicas: 2 2
        resources:
          - container: activator
            requests:
              cpu: 250m 3
              memory: 60Mi 4
            limits:
              cpu: 1000m
              memory: 600Mi
      - name: controller
        replicas: 1 5
        resources:
          - container: controller
            requests:
              cpu: 10m
              memory: 100Mi
            limits: 6
              cpu: 200m
              memory: 300Mi
      - name: webhook
        replicas: 2
        resources:
          - container: webhook
            requests:
              cpu: 100m 7
              memory: 60Mi
            limits:
              cpu: 200m
              memory: 200Mi
    podDisruptionBudgets: 8
      - name: activator-pdb
        minAvailable: 1
      - name: webhook-pdb
        minAvailable: 1

  1

  把它设置为 1 可将所有系统组件扩展到一个副本。

  2

  激活器应始终扩展到至少 2 个实例，以避免停机。

  3

  Activator CPU 请求不应小于 250m，因为 HorizontalPodAutoscaler 将使用此请求作为扩展和缩减的引用。

  4

  将内存请求调整为上表中的空闲值。另外，根据您的预期负载调整内存限值（这可能需要自定义测试来查找最佳值）。

  5

  一个 Webhook 和一个控制器足以满足最小工作负载的情况

  6

  这些限制足以满足最小工作负载的情况，但可能需要根据您的具体工作负载进行调整。

  7

  Webhook CPU 请求不应小于 100m，因为 HorizontalPodAutoscaler 将使用此请求作为扩展和缩减的引用。

  8

  将 PodDistruptionBudgets 调整为小于 replicas 的值，以避免节点维护期间出现问题。

• 所有 data-plane 组件在更高的请求和限值上增加 CPU 使用量，因此必须测试并可能会增加 CPU 请求和限值。
• activator 组件可能需要更多内存，当它需要缓冲更多或较大的请求有效负载时，因此可能需要增加内存请求和限值。
• 一个 activator pod 可以在开始增加延迟前每秒处理大约 2500 个请求，在某些情况下会导致错误。
• 一个 3scale-kourier-gateway 或 istio-ingressgateway pod 也可以在开始增加延迟前每秒处理大约 2500 个请求，在某些情况下会导致错误。
• 每个 data-plane 组件最多消耗 1 个 vCPU 来每秒处理 2500 个请求。请注意，这高度依赖于有效负载大小和 Knative Service 后端的响应时间。

流程

• 要微调安装，请使用之前的发现以及您自己的测试结果来配置 KnativeServing 自定义资源：

  KnativeServing CR 中的高工作负载配置

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    high-availability:
      replicas: 2 1
    workloads:
      - name: component-name 2
        replicas: 2 3
        resources:
          - container: container-name
            requests:
              cpu: 4
              memory:
            limits:
              cpu:
              memory:
    podDisruptionBudgets: 5
      - name: name-of-pod-disruption-budget
        minAvailable: 1

  1

  将此参数设置为至少 2 个，以确保每个组件都至少有两个实例正在运行。您还可以使用 工作负载 覆盖某些组件的副本。

  2

  使用 工作负载 列表配置特定组件。使用组件的部署名称并设置 replicas 字段。

  3

  对于 activator、webhook 和 3scale-kourier-gateway 组件（使用 pod 横向自动扩展(HPAs)），replicas 字段会设置最小副本数。实际的副本数取决于 HPAs 完成的 CPU 负载和扩展。

  4

  至少根据空闲消耗设置请求和限制 CPU 和内存，同时考虑之前的发现和您自己的测试结果。

  5

  将 PodDistruptionBudgets 调整为小于 副本 的值，以避免节点维护期间出现问题。默认 minAvailable 设置为 1，因此如果您增加所需的副本，还必须增加 minAvailable。