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
×
OpenShift Serverless Serving 的可扩展性和性能
OpenShift Serverless 包含几个不同的组件，它们具有不同的资源需求和扩展行为。这些组件可以水平和垂直扩展，但它们的资源需求和配置高度依赖于实际用例。
- 控制平面组件
-
这些组件负责观察和响应自定义资源，并持续重新配置系统，例如控制器 Pod。
- 数据平面组件
-
这些组件直接参与请求和响应处理，例如 Knative Serving 的激活器组件。
使用以下测试设置记录了以下指标和发现
-
运行 OpenShift Container Platform 4.13 的集群
-
在 AWS 上运行 4 个计算节点的集群，机器类型为 m6.xlarge
-
OpenShift Serverless 1.30
OpenShift Serverless Serving 的开销
由于 OpenShift Serverless Serving 的组件是数据平面的一部分，因此来自客户端的请求将通过以下组件路由：
-
入口网关 (Kourier 或 Service Mesh)
-
激活器组件
-
每个 Knative 服务中的队列代理 sidecar 容器
这些组件引入了额外的网络跳跃并执行其他任务，例如添加可观察性和请求排队。以下是测量的延迟开销：
-
每个额外的网络跳跃都会为请求增加 0.5 毫秒到 1 毫秒的延迟。根据 Knative 服务的当前负载以及 Knative 服务在请求之前是否已缩放到零，激活器组件并不总是数据平面的一部分。
-
根据负载大小，每个组件最多消耗 1 个 vCPU 的 CPU 来处理每秒 2500 个请求。
OpenShift Serverless Serving 的已知限制
可以创建的最大 Knative 服务数量为 3000。这对应于 OpenShift Container Platform Kubernetes 服务限制为 10000，因为 1 个 Knative 服务创建 3 个 Kubernetes 服务。
OpenShift Serverless Serving 的扩展性和性能
必须根据以下参数缩放和配置 OpenShift Serverless Serving：
-
Knative 服务的数量
-
修订版数量
-
系统中并发请求的数量
-
请求负载的大小
-
用户 Web 应用程序添加的 Knative 服务的启动延迟和响应延迟
-
KnativeService 自定义资源 (CR) 随时间的变化次数
KnativeServing 默认配置
默认情况下，OpenShift Serverless Serving 配置为以高可用性和中等大小的 CPU 和内存请求和限制运行所有组件。这意味着 `KnativeServing` CR 中的 `high-available` 字段会自动设置为 `2`，并且所有系统组件都扩展到两个副本。此配置适用于中等工作负载场景，并且已通过以下测试：
-
170 个 Knative 服务
-
每个 Knative 服务 1-2 次修订
-
89 个测试场景，主要集中在控制平面的测试
-
48 个重新创建场景，其中 Knative 服务被删除并重新创建
-
41 个稳定场景，其中请求缓慢但持续地发送到系统
在这些测试用例期间，系统组件有效地消耗了
| 组件 | 已测资源 |
|---|---|
|
1 GB 内存，0.2 个 CPU 核心 |
|
5 GB 内存，2.5 个 CPU 核心 |
OpenShift Serverless Serving 的最低要求
虽然默认设置适用于中等规模的工作负载，但对于较小的设置来说可能过大，而对于高工作负载场景来说可能过小。要为最小工作负载场景配置 OpenShift Serverless Serving，您需要了解系统组件的空闲消耗。
空闲消耗
空闲消耗取决于 Knative 服务的数量。以下内存使用情况是在 knative-serving 和 knative-serving-ingress OpenShift Container Platform 项目中测量的组件。
| 组件 | 0 个服务 | 100 个服务 | 500 个服务 | 1000 个服务 |
|---|---|---|---|---|
|
55Mi |
86Mi |
300Mi |
450Mi |
|
52Mi |
102Mi |
225Mi |
350Mi |
|
100Mi |
135Mi |
310Mi |
500Mi |
|
60Mi |
60Mi |
60Mi |
60Mi |
|
20Mi |
60Mi |
190Mi |
330Mi |
|
90Mi |
170Mi |
340Mi |
430Mi |
|
已安装
|
为最小工作负载配置 Serving
步骤
-
您可以使用
KnativeServing自定义资源 (CR) 为最小工作负载配置 Knative Serving。KnativeServing CR 中的最小工作负载配置1 将其设置为 1会将所有系统组件扩展到一个副本。2 为了避免停机，激活器 (Activator) 应始终扩展到至少 2个实例。3 激活器 (Activator) 的 CPU 请求不应低于 250m，因为水平 Pod 自动缩放器 (HorizontalPodAutoscaler) 将以此作为参考进行向上和向下缩放。4 将内存请求调整到上一表中的空闲值。还应根据您的预期负载调整内存限制（这可能需要自定义测试才能找到最佳值）。 5 一个 Webhook 和一个控制器对于最小工作负载场景就足够了。 6 这些限制对于最小工作负载场景足够，但是也可能需要根据您的具体工作负载进行调整。 7 Webhook 的 CPU 请求不应低于 100m，因为水平 Pod 自动缩放器 (HorizontalPodAutoscaler) 将以此作为参考进行向上和向下缩放。8 将 `PodDistruptionBudgets` 调整为小于 `replicas` 的值，以避免在节点维护期间出现问题。
为高工作负载配置 Serving
您可以使用 KnativeServing 自定义资源 (CR) 为高工作负载配置 Knative Serving。以下发现与为高工作负载配置 Knative Serving 相关。
|
这些发现已在有效负载大小为 0-32 kb 的请求中进行了测试。在这些测试中使用的 Knative 服务后端具有 0 到 10 秒的启动延迟和 0 到 5 秒的响应时间。 |
-
所有数据平面组件在较高的请求和有效负载场景中大多会增加 CPU 使用率，因此必须测试并可能增加 CPU 请求和限制。
-
当激活器 (activator) 组件必须缓冲更多或更大的请求有效负载时，它也可能需要更多内存，因此可能需要增加内存请求和限制。
-
一个激活器 (activator) Pod 在开始增加延迟之前，大约每秒可以处理 2500 个请求，并且在某些情况下会导致错误。
-
一个
3scale-kourier-gateway或istio-ingressgatewayPod 在开始增加延迟之前，大约每秒也可以处理 2500 个请求，并且在某些情况下会导致错误。 -
每个数据平面组件消耗高达 1 个 vCPU 的 CPU 用于处理每秒 2500 个请求。请注意，这在很大程度上取决于有效负载大小和 Knative 服务后端的响应时间。
|
Knative 服务用户工作负载的快速启动和快速响应时间对于整个系统的良好性能至关重要。当 Knative 服务用户后端正在扩展或请求并发已达到其容量时，Knative Serving 组件会缓冲传入请求。如果您的 Knative 服务用户工作负载导致启动或请求延迟过长，它要么会过载 `activator` 组件（当 CPU 和内存配置过低时），要么会导致调用客户端出现错误。 |
步骤
-
要微调您的安装，请将之前的发现与您自己的测试结果结合起来，以配置
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: 11 将此参数设置为至少 2，以确保始终至少运行每个组件的两个实例。您也可以使用workloads来覆盖某些组件的副本数。2 使用 workloads列表配置特定组件。使用组件的deployment名称并设置replicas字段。3 对于使用水平 Pod 自动缩放器 (HPA) 的 activator、webhook和3scale-kourier-gateway组件，replicas字段设置副本的最小数量。副本的实际数量取决于 CPU 负载和 HPA 完成的缩放。4 根据至少空闲消耗设置请求的和限制的 CPU 和内存，同时还要考虑之前的发现和您自己的测试结果。 5 将 `PodDistruptionBudgets` 调整为小于 `replicas` 的值，以避免在节点维护期间出现问题。默认的 `minAvailable` 设置为 `1`，因此如果您增加了所需的副本数，也必须增加 `minAvailable`。
|
由于每个环境都非常具体，因此必须测试并找到您自己的理想配置。使用 OpenShift Container Platform 的监控和警报功能持续监控您的实际资源消耗，并在需要时进行调整。 如果您正在使用 OpenShift Serverless 和 Service Mesh 集成，则 `istio-proxy` sidecar 容器会添加额外的 CPU 处理。有关此方面的更多信息，请参阅 Service Mesh 文档。 |