×

对于生产就绪的 Knative Eventing 部署,Red Hat 建议使用 Apache Kafka 的 Knative 代理实现。该代理是 Knative 代理的 Apache Kafka 原生实现,它将 CloudEvents 直接发送到 Kafka 实例。

Knative 代理与 Kafka 原生集成,用于存储和路由事件。这使得代理和触发器模型与 Kafka 的集成比其他代理类型更好,并减少了网络跳转。Knative 代理实现的其他优点包括:

  • 至少一次传递保证

  • 基于 CloudEvents 分区扩展的有序事件传递

  • 控制平面高可用性

  • 水平可扩展的数据平面

Apache Kafka 的 Knative 代理实现使用二进制内容模式将传入的 CloudEvents 存储为 Kafka 记录。这意味着所有 CloudEvent 属性和扩展都映射为 Kafka 记录的标头,而 CloudEvent 的 `data` 规范对应于 Kafka 记录的值。

在未将 Apache Kafka 配置为默认代理类型时创建 Apache Kafka 代理

如果您的 OpenShift Serverless 部署未配置为使用 Kafka 代理作为默认代理类型,您可以使用以下过程之一来创建基于 Kafka 的代理。

使用 YAML 创建 Apache Kafka 代理

使用 YAML 文件创建 Knative 资源使用声明式 API,使您可以声明性和可重复地描述应用程序。要使用 YAML 创建 Kafka 代理,您必须创建一个定义 `Broker` 对象的 YAML 文件,然后使用 `oc apply` 命令应用它。

前提条件
  • OpenShift Serverless Operator、Knative Eventing 和 `KnativeKafka` 自定义资源已安装在您的 OpenShift Container Platform 集群上。

  • 您已创建项目或有权访问具有在 OpenShift Container Platform 中创建应用程序和其他工作负载的相应角色和权限的项目。

  • 您已安装 OpenShift CLI(`oc`)。

步骤
  1. 将基于 Kafka 的代理创建为 YAML 文件

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: Kafka (1)
      name: example-kafka-broker
    spec:
      config:
        apiVersion: v1
        kind: ConfigMap
        name: kafka-broker-config (2)
        namespace: knative-eventing
    1 代理类。如果未指定,代理使用集群管理员配置的默认类。要使用 Kafka 代理,此值必须为 `Kafka`。
    2 Apache Kafka 代理的 Knative 默认配置映射。当集群管理员在集群上启用 Kafka 代理功能时,会创建此配置映射。
  2. 应用基于 Kafka 的代理 YAML 文件

    $ oc apply -f <filename>

创建使用外部管理的 Kafka 主题的 Apache Kafka 代理

如果您想使用 Kafka 代理而不允许它创建自己的内部主题,则可以使用外部管理的 Kafka 主题。为此,您必须创建一个使用kafka.eventing.knative.dev/external.topic 注解的 Kafka Broker 对象。

前提条件
  • OpenShift Serverless Operator、Knative Eventing 和 `KnativeKafka` 自定义资源已安装在您的 OpenShift Container Platform 集群上。

  • 您可以访问 Kafka 实例,例如 Red Hat AMQ Streams,并且已创建 Kafka 主题。

  • 您已创建项目或有权访问具有在 OpenShift Container Platform 中创建应用程序和其他工作负载的相应角色和权限的项目。

  • 您已安装 OpenShift CLI(`oc`)。

步骤
  1. 将基于 Kafka 的代理创建为 YAML 文件

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: Kafka (1)
        kafka.eventing.knative.dev/external.topic: <topic_name> (2)
    ...
    1 代理类。如果未指定,代理使用集群管理员配置的默认类。要使用 Kafka 代理,此值必须为 `Kafka`。
    2 您要使用的 Kafka 主题的名称。
  2. 应用基于 Kafka 的代理 YAML 文件

    $ oc apply -f <filename>

具有隔离数据平面的 Apache Kafka 的 Knative Broker 实现

具有隔离数据平面的 Apache Kafka 的 Knative Broker 实现仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持,并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能提供对即将推出的产品功能的早期访问,使客户能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息,请参阅 技术预览功能支持范围

用于 Apache Kafka 的 Knative Broker 实现具有 2 个平面

控制平面

由与 Kubernetes API 通信、监视自定义对象和管理数据平面的控制器组成。

数据平面

侦听传入事件、与 Apache Kafka 通信并将事件发送到事件接收器的组件集合。用于 Apache Kafka 数据平面的 Knative Broker 实现是事件流经的地方。该实现由kafka-broker-receiverkafka-broker-dispatcher 部署组成。

当您配置Kafka 类的 Broker 时,用于 Apache Kafka 的 Knative Broker 实现使用共享数据平面。这意味着knative-eventing 命名空间中的kafka-broker-receiverkafka-broker-dispatcher 部署将用于集群中的所有 Apache Kafka 代理。

但是,当您配置KafkaNamespaced 类的 Broker 时,Apache Kafka 代理控制器会为存在代理的每个命名空间创建一个新的数据平面。此数据平面由该命名空间中的所有KafkaNamespaced 代理使用。这提供了数据平面之间的隔离,因此用户命名空间中的kafka-broker-receiverkafka-broker-dispatcher 部署仅用于该命名空间中的代理。

由于拥有单独的数据平面,此安全功能会创建更多部署并使用更多资源。除非您有这样的隔离要求,否则请使用具有Kafka 类的**常规** Broker。

创建使用隔离数据平面的 Apache Kafka 的 Knative 代理

具有隔离数据平面的 Apache Kafka 的 Knative Broker 实现仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持,并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能提供对即将推出的产品功能的早期访问,使客户能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息,请参阅 技术预览功能支持范围

要创建KafkaNamespaced 代理,您必须将eventing.knative.dev/broker.class 注解设置为KafkaNamespaced

前提条件
  • OpenShift Serverless Operator、Knative Eventing 和 `KnativeKafka` 自定义资源已安装在您的 OpenShift Container Platform 集群上。

  • 您可以访问 Apache Kafka 实例,例如 Red Hat AMQ Streams,并且已创建 Kafka 主题。

  • 您已创建项目,或有权访问具有在 OpenShift Container Platform 中创建应用程序和其他工作负载的适当角色和权限的项目。

  • 您已安装 OpenShift CLI(`oc`)。

步骤
  1. 使用 YAML 文件创建基于 Apache Kafka 的代理

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      annotations:
        eventing.knative.dev/broker.class: KafkaNamespaced (1)
      name: default
      namespace: my-namespace (2)
    spec:
      config:
        apiVersion: v1
        kind: ConfigMap
        name: my-config (2)
    ...
    1 要使用具有隔离数据平面的 Apache Kafka 代理,代理类值必须为KafkaNamespaced
    2 引用的ConfigMap 对象my-config 必须与Broker 对象位于同一命名空间中,在本例中为my-namespace
  2. 应用基于 Apache Kafka 的代理 YAML 文件

    $ oc apply -f <filename>

spec.config 中的ConfigMap 对象必须与Broker 对象位于同一命名空间中

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
  namespace: my-namespace
data:
  ...

创建第一个具有KafkaNamespaced 类的Broker 对象后,会在命名空间中创建kafka-broker-receiverkafka-broker-dispatcher 部署。随后,同一命名空间中所有具有KafkaNamespaced 类的代理都将使用相同的数据平面。如果命名空间中不存在具有KafkaNamespaced 类的代理,则会删除命名空间中的数据平面。

配置 Apache Kafka 代理设置

您可以通过创建配置映射并在 Kafka Broker 对象中引用此配置映射来配置 Kafka 代理的复制因子、引导服务器和主题分区的数量。

Knative Eventing 支持 Kafka 支持的完整主题配置选项集。要设置这些选项,您必须使用default.topic.config. 前缀向 ConfigMap 添加键。

前提条件
  • 您具有 OpenShift Container Platform 的集群或专用管理员权限。

  • OpenShift Serverless Operator、Knative Eventing 和KnativeKafka 自定义资源 (CR) 已安装在您的 OpenShift Container Platform 集群上。

  • 您已创建项目,或有权访问具有在 OpenShift Container Platform 中创建应用程序和其他工作负载的适当角色和权限的项目。

  • 您已安装 OpenShift CLI(`oc`)。

步骤
  1. 修改kafka-broker-config 配置映射,或创建包含以下配置的自己的配置映射

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <config_map_name> (1)
      namespace: <namespace> (2)
    data:
      default.topic.partitions: <integer> (3)
      default.topic.replication.factor: <integer> (4)
      bootstrap.servers: <list_of_servers> (5)
      default.topic.config.<config_option>: <value> (6)
    1 配置映射名称。
    2 配置映射存在的命名空间。
    3 Kafka 代理的主题分区数。这控制事件发送到代理的速度。较高的分区数需要更大的计算资源。
    4 主题消息的复制因子。这可以防止数据丢失。较高的复制因子需要更大的计算资源和更多存储空间。
    5 引导服务器的逗号分隔列表。这可以在 OpenShift Container Platform 集群内部或外部,并且是代理从中接收事件并向其发送事件的 Kafka 集群列表。
    6 主题配置选项。有关更多信息,请参阅 可能的完整选项和值集

    default.topic.replication.factor 值必须小于或等于集群中 Kafka 代理实例的数量。例如,如果您只有一个 Kafka 代理,则default.topic.replication.factor 值不应超过"1"

    示例 Kafka 代理配置映射
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: kafka-broker-config
      namespace: knative-eventing
    data:
      default.topic.partitions: "10"
      default.topic.replication.factor: "3"
      bootstrap.servers: "my-cluster-kafka-bootstrap.kafka:9092"
      default.topic.config.retention.ms: "3600"
  2. 应用配置映射

    $ oc apply -f <config_map_filename>
  3. 指定 Kafka Broker 对象的配置映射

    示例 Broker 对象
    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
      name: <broker_name> (1)
      namespace: <namespace> (2)
      annotations:
        eventing.knative.dev/broker.class: Kafka (3)
    spec:
      config:
        apiVersion: v1
        kind: ConfigMap
        name: <config_map_name> (4)
        namespace: <namespace> (5)
    ...
    1 代理名称。
    2 代理所在的命名空间。
    3 代理类注解。在此示例中,代理是使用类值Kafka的Kafka代理。
    4 配置映射名称。
    5 配置映射存在的命名空间。
  4. 应用代理

    $ oc apply -f <broker_filename>

Apache Kafka 的 Knative 代理实现的安全配置

Kafka 集群通常使用 TLS 或 SASL 身份验证方法进行保护。您可以配置 Kafka 代理或通道以使用 TLS 或 SASL 与受保护的 Red Hat AMQ Streams 集群配合使用。

Red Hat 建议同时启用 SASL 和 TLS。

配置 Apache Kafka 代理的 TLS 身份验证

传输层安全 (TLS) 用于 Apache Kafka 客户端和服务器,以加密 Knative 和 Kafka 之间的流量,以及用于身份验证。对于 Apache Kafka 的 Knative 代理实现,TLS 是唯一支持的流量加密方法。

前提条件
  • 您具有 OpenShift Container Platform 的集群或专用管理员权限。

  • OpenShift Serverless Operator、Knative Eventing 和KnativeKafka CR 已安装在您的 OpenShift Container Platform 集群上。

  • 您已创建项目或有权访问具有在 OpenShift Container Platform 中创建应用程序和其他工作负载的相应角色和权限的项目。

  • 您有一个存储为.pem文件的 Kafka 集群 CA 证书。

  • 您有一个存储为.pem文件的 Kafka 集群客户端证书和密钥。

  • 安装 OpenShift CLI (oc)。

步骤
  1. knative-eventing命名空间中将证书文件创建为密钥。

    $ oc create secret -n knative-eventing generic <secret_name> \
      --from-literal=protocol=SSL \
      --from-file=ca.crt=caroot.pem \
      --from-file=user.crt=certificate.pem \
      --from-file=user.key=key.pem

    使用密钥名称ca.crtuser.crtuser.key。请勿更改它们。

  2. 编辑KnativeKafka CR 并将对您在broker规范中的密钥的引用添加到其中。

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      broker:
        enabled: true
        defaultConfig:
          authSecretName: <secret_name>
    ...

配置 Apache Kafka 代理的 SASL 身份验证

简单身份验证和安全层 (SASL) 由 Apache Kafka 用于身份验证。如果在您的集群上使用 SASL 身份验证,则用户必须向 Knative 提供凭据才能与 Kafka 集群通信;否则,无法生成或使用事件。

前提条件
  • 您具有 OpenShift Container Platform 的集群或专用管理员权限。

  • OpenShift Serverless Operator、Knative Eventing 和KnativeKafka CR 已安装在您的 OpenShift Container Platform 集群上。

  • 您已创建项目或有权访问具有在 OpenShift Container Platform 中创建应用程序和其他工作负载的相应角色和权限的项目。

  • 您有 Kafka 集群的用户名和密码。

  • 您已选择要使用的 SASL 机制,例如PLAINSCRAM-SHA-256SCRAM-SHA-512

  • 如果启用了 TLS,您还需要 Kafka 集群的ca.crt证书文件。

  • 安装 OpenShift CLI (oc)。

步骤
  1. knative-eventing命名空间中将证书文件创建为密钥。

    $ oc create secret -n knative-eventing generic <secret_name> \
      --from-literal=protocol=SASL_SSL \
      --from-literal=sasl.mechanism=<sasl_mechanism> \
      --from-file=ca.crt=caroot.pem \
      --from-literal=password="SecretPassword" \
      --from-literal=user="my-sasl-user"
    • 使用密钥名称ca.crtpasswordsasl.mechanism。请勿更改它们。

    • 如果您想将 SASL 与公共 CA 证书一起使用,则在创建密钥时必须使用tls.enabled=true标志,而不是ca.crt参数。例如

      $ oc create secret -n <namespace> generic <kafka_auth_secret> \
        --from-literal=tls.enabled=true \
        --from-literal=password="SecretPassword" \
        --from-literal=saslType="SCRAM-SHA-512" \
        --from-literal=user="my-sasl-user"
  2. 编辑KnativeKafka CR 并将对您在broker规范中的密钥的引用添加到其中。

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      broker:
        enabled: true
        defaultConfig:
          authSecretName: <secret_name>
    ...