5.9. 调优事件配置

5.9.1. 覆盖 Knative Eventing 系统部署配置

您可以通过修改 KnativeEventing 自定义资源 (CR) 中的 deployments spec 来覆盖某些特定部署的默认配置。

5.9.1.1. 覆盖部署配置

目前,对于 eventing-controllereventing-webhookimc-controller 字段以及探测的 readinessliveness 字段支持覆盖默认配置设置。

重要

replicas spec 无法覆盖使用 Horizontal Pod Autoscaler (HPA) 的部署副本数,且不适用于 eventing-webhook 部署。

在以下示例中,KnativeEventing CR 覆盖 eventing-controller 部署,以便:

  • readiness 探测超时 eventing-controller 被设置为 10 秒。
  • 部署指定了 CPU 和内存资源限制。
  • 部署有 3 个副本。
  • 添加 example-label: label 标签。
  • 添加 example-annotation: 注解。
  • nodeSelector 字段被设置为选择带有 disktype: hdd 标签的节点。

KnativeEventing CR 示例

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  deployments:
  - name: eventing-controller
    readinessProbes: 1
      - container: controller
        timeoutSeconds: 10
    resources:
    - container: eventing-controller
      requests:
        cpu: 300m
        memory: 100Mi
      limits:
        cpu: 1000m
        memory: 250Mi
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

1
您可以使用 readinessliveness 探测覆盖来覆盖在 Kubernetes API 中指定的一个部署中的一个容器探测的所有字段,与探测 handler: exec, grpc, httpGet, 和 tcpSocket 相关的字段除外。
注意

KnativeEventing CR 标签和注解设置覆盖部署本身和生成的 Pod 的部署标签和注解。

5.9.2. 高可用性

高可用性 (HA) 是 Kubernetes API 的标准功能,有助于确保在出现中断时 API 保持正常运行。在 HA 部署中,如果活跃控制器崩溃或被删除,另一个控制器就可以使用。此控制器会接管处理由现在不可用的控制器提供服务的 API。

OpenShift Serverless 中的 HA 可通过领导选举机制获得,该机制会在安装 Knative Serving 和 Eventing control plane 后默认启用。在使用领导选举 HA 模式时,控制器实例在需要前应该已在集群内调度并运行。这些控制器实例争用共享资源,即领导选举锁定。在任何给定时间可以访问领导选举机制锁定资源的控制器实例被称为领导 (leader) 。

OpenShift Serverless 中的 HA 可通过领导选举机制获得,该机制会在安装 Knative Serving 和 Eventing control plane 后默认启用。在使用领导选举 HA 模式时,控制器实例在需要前应该已在集群内调度并运行。这些控制器实例争用共享资源,即领导选举锁定。在任何给定时间可以访问领导选举机制锁定资源的控制器实例被称为领导 (leader) 。

5.9.2.1. 为 Knative Eventing 配置高可用性副本

默认情况下,Knative Eventing eventing-controllereventing-webhookimc-controllerimc-dispatchermt-broker-controller 组件都会具有高可用性 (HA) 。您可以通过修改 KnativeEventing 自定义资源 (CR) 中的 spec.high-availability.replicas 值来更改这些组件的副本数。

注意

对于 Knative Eventing,HA 不会扩展 mt-broker-filtermt-broker-ingress 部署。如果需要多个部署,请手动扩展这些组件。

先决条件

  • 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Eventing。

流程

  1. 在 OpenShift Container Platform web 控制台的 Administrator 视角中,进入 OperatorHubInstalled Operators
  2. 选择 knative-eventing 命名空间。
  3. 点 OpenShift Serverless Operator 的 Provided APIs 列表中的 Knative Eventing 来进入 Knative Eventing 选项卡。
  4. knative-eventing,然后进入 knative-eventing 页面中的 YAML 选项卡。

    Knative Eventing YAML
  5. 修改 KnativeEventing CR 中的副本数量:

    YAML 示例

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      high-availability:
        replicas: 3

5.9.2.2. 为 Knative Kafka 配置高可用性副本

默认情况下,Knative Kafka kafka-controllerkafka-webhook-eventing 组件都会具有高可用性 (HA) ,这些组件默认配置为默认具有两个副本。您可以通过修改 KnativeKafka 自定义资源 (CR) 中的 spec.high-availability.replicas 值来更改这些组件的副本数。

先决条件

  • 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Kafka。

流程

  1. 在 OpenShift Container Platform web 控制台的 Administrator 视角中,进入 OperatorHubInstalled Operators
  2. 选择 knative-eventing 命名空间。
  3. 点 OpenShift Serverless Operator 的 Provided APIs 列表中的 Knative Kafka 进入 Knative Kafka 标签页。
  4. knative-kafka,然后进入 knative-kafka 页面中的 YAML 选项卡。

    Knative Kafka YAML
  5. 修改 KnativeKafka CR 中的副本数量:

    YAML 示例

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      name: knative-kafka
      namespace: knative-eventing
    spec:
      high-availability:
        replicas: 3