Serverless

OpenShift Container Platform 4.7

OpenShift Serverless 的安装、使用与发行注记

Red Hat OpenShift Documentation Team

摘要

本文档提供有关如何在 OpenShift Container Platform 中使用 OpenShift Serverless 的信息.

第 1 章 OpenShift Serverless 发行注记

如需了解 OpenShift Serverless 功能概述,请参阅了解 OpenShift Serverless

1.1. Red Hat OpenShift Serverless 1.13.0 发行注记

1.1.1. 新功能

  • OpenShift Serverless 现在使用 Knative Serving 0.19.0。
  • OpenShift Serverless 使用 Knative Eventing 0.19.2。
  • OpenShift Serverless 现在使用 Kourier 0.19.0。
  • OpenShift Serverless 现在使用 Knative kn CLI 0.19.1。
  • OpenShift Serverless 现在使用 Knative Kafka 0.19.1。
  • 在 OpenShift Serverless 中添加了 DomainMapping 自定义资源(CR)以便用户将自定义域名映射到 Knative Service。请参阅 Knative 文档中有关在自定义域名和 Knative Service 之间创建映射的内容。
  • 在 Knative Serving 0.19.0 中,删除了 ServiceRouteConfigurationRevision 资源的v1alpha1v1beta1 版本 。OpenShift Serverless Operator 会自动将旧资源升级到 v1,因此不需要用户进行任何操作。

    注意

    新资源不能以 v1alpha1v1beta1 版本创建,因为这可能导致错误,且不能自动升级这些资源。

1.2. Red Hat OpenShift Serverless 1.12.0 发行注记

1.2.1. 新功能

  • OpenShift Serverless 现在使用 Knative Serving 0.18.2。
  • OpenShift Serverless 使用 Knative Eventing 0.18.6。
  • OpenShift Serverless 现在使用 Kourier 0.18.0。
  • OpenShift Serverless 现在使用 Knative kn CLI 0.18.4。
  • OpenShift Serverless 现在使用 Knative Kafka 0.18.0。

1.2.2. 修复的问题

  • 在以前的版本中,如果您在 OpenShift Serverless 中使用 ping 源,在卸载和删除所有其他 Knative Eventing 组件后,pingsource-jobrunner 部署不会被删除。这个问题现已解决,pingsource-jobrunner 部署已被重命名为 pingsource-mt-adapter
  • 在以前的版本中,在删除 SinkBinding 资源前删除 sink 会导致资源删除挂起。这个问题现已解决。

1.2.3. 已知问题

  • 不支持为 KafkaChannel 对象使用 eventing.knative.dev/scope: namespace 注解。

1.3. Red Hat OpenShift Serverless 1.11.0 发行注记

1.3.1. 新功能

  • OpenShift Serverless 上的 Knative Eventing 现已正式发布(GA)。
  • 在 OpenShift Serverless 中,Apache Kafka 的功能现在作为技术预览提供,如 Kafka 频道和 Kafka 事件源。Kafka 集成通过 OpenShift Serverless Operator 进行,不需要单独安装 community Operator。如需更多信息,请参阅在 OpenShift Serverless 中使用 Apache Kafka 的文档
  • OpenShift Serverless 功能现在通过标准 Knative kn CLI 安装作为开发者预览提供。红帽尚不支持在生产环境的部署,但可用于开发和测试。有关通过 kn purc CLI 使用 OpenShift Serverless 功能的更多信息,请参阅 OpenShift Serverless Functions 开发者预览文档
  • OpenShift Serverless 现在使用 Knative Serving 0.17.3。
  • OpenShift Serverless 使用 Knative kning 0.17.2。
  • OpenShift Serverless 现在使用 Kourier 0.17.0。
  • OpenShift Serverless 现在使用 Knative kn CLI 0.17.3。
  • OpenShift Serverless 现在使用 Knative Kafka 0.17.1。

1.3.2. 已知问题

  • 当 Pod 横向自动扩展(HPA)扩展了 broker-ingress pod 时,imc-dispatcher pod 有时无法转发回复。这是因为新的 broker-ingress pod 在接受连接前是 Ready,因为它们缺少就绪度探测。如果使用 HPA 自动扩展且不想手动扩展 broker-ingress pod,您必须在 Broker.Spec.Delivery 中配置重试。
  • 不支持在 Kafka 频道中使用 eventing.knative.dev/scope: namespace 注解。

1.4. Red Hat OpenShift Serverless 1.10.0 发行注记

1.4.1. 新功能

  • OpenShift Serverless 现在使用 Knative Operator 0.16.0。
  • OpenShift Serverless 现在使用 Knative Serving 0.16.0。
  • OpenShift Serverless 使用 Knative Eventing 0.16.0。
  • OpenShift Serverless 现在使用 Kourier 0.16.0。
  • OpenShift Serverless 现在使用 Knative kn CLI 0.16.1。
  • 以前,用来为代理创建添加注解的 knative-eventing-injection=enabled 注解现已弃用。新注解为 eventing.knative.dev/injection=enabled。如需更多信息,请参阅有关代理和触发器的文档。
  • 现在,Knative 上提供了多容器支持作为技术预览功能。您可以在 config-features 配置映射中启用多容器支持。如需更多信息,请参阅 Knative 文档

1.4.2. 修复的问题

  • 在以前的版本中,Knative Serving 为 queue-proxy 有一个固定的最小 CPU 请求 25m。如果您的集群设置了与这个值冲突的值,例如,如果您为 defaultRequest 设定了大于 25m 的最小 CPU 请求,Knative Service 将无法部署。这个问题在 1.10.0 中解决。

1.5. 其他资源

OpenShift Serverless 基于开源的 Knative 项目。

第 2 章 OpenShift Serverless 支持

2.1. 获取支持

如果您在执行本文档所述的某个流程时遇到问题,请访问红帽客户门户网站 http://access.redhat.com。通过客户门户网站,您可以:

  • 搜索或浏览红帽知识库,了解有关红帽产品的技术支持文章。
  • 向红帽全球支持服务 (GSS) 提交支持问题单
  • 访问其他产品文档

如果您对本文档有任何改进建议,或发现了任何错误,请访问 http://bugzilla.redhat.com,针对 OpenShift Container Platform 产品的 Documentation组件提交 Bugzilla 报告。请提供具体信息,如章节号、指南名称和 OpenShift Serverless 版本,以便我们可以快速地找到相关内容。

2.2. 为支持收集诊断信息

在提交问题单时同时提供您的集群信息,可以帮助红帽支持为您进行排除故障。

您可使用 must-gather 工具来收集有关 OpenShift Container Platform 集群的诊断信息,包括与 OpenShift Serverless 相关的数据。

为了获得快速支持,请提供 OpenShift Container Platform 和 OpenShift Serverless 的诊断信息。

2.2.1. 关于 must-gather 工具

oc adm must-gather CLI 命令可收集最有助于解决问题的集群信息,如:

  • 资源定义
  • 审计日志
  • 服务日志

您在运行该命令时,可通过包含 --image 参数来指定一个或多个镜像。指定镜像后,该工具便会收集有关相应功能或产品的信息。

在运行 oc adm must-gather 时,集群上会创建一个新 pod。在该 pod 上收集数据,并保存至以 must-gather.local 开头的一个新目录中。此目录在当前工作目录中创建。

2.2.2. 关于收集 OpenShift Serverless 数据

您可使用 oc adm must-gather CLI 命令来收集有关集群的信息,包括与 OpenShift Serverless 相关的功能和对象:要使用 must-gather 来收集 OpenShift Serverless 数据,您必须指定 OpenShift Serverless 镜像。

流程

  • 输入命令:

    $ oc adm must-gather --image=registry.redhat.io/openshift-serverless-1/svls-must-gather-rhel8

第 3 章 OpenShift Serverless 入门

OpenShift Serverless 可减少开发人员需要进行的基础架构设置或后端开发的操作,从而简化了代码从开发到在生产环境中应用的过程。

3.1. OpenShift Serverless 的工作原理

使用 OpenShift Serverless 的开发人员可使用所提供的 Kubernetes 原生 API,以及熟悉的语言和框架来部署应用程序和容器工作负载。

在 OpenShift Container Platform 中使用 OpenShift Serverless,可通过自动化操作在单一多云容器平台中运行所有无状态以及无服务器的工作负载。开发人员能够使用单一平台托管其微服务、资产和无服务器的应用程序。

OpenShift Serverless 基于开源 Knative 项目,通过启用企业级无服务器平台在混合和多云环境之间实现可移植性和一致性。

3.2. 支持的配置

OpenShift Serverless 支持的功能、配置和集成(当前和过去的版本)包括在 支持的配置页面中

3.3. 后续步骤

第 4 章 安装 Knative CLI(kn

注意

kn 本身没有自己的登录机制。要登录到集群,您必须安装 oc CLI 并使用 oc 登录。

oc CLI 的安装选项会因您的操作系统而异。

有关为您的操作系统安装 oc CLI 并使用 oc 登录的更多信息,请参阅 OpenShift CLI 启动文档

4.1. 使用 OpenShift Container Platform web 控制台安装 kn CLI

安装 OpenShift Serverless Operator 后,您会在 OpenShift Container Platform web 控制台的 Command Line Tools 页中看到下载用于 Linux 、macOS 和 Windows 的 kn CLI 的链接。

您可以点击 web 控制台右上角的 question circle 图标进入 Command Line Tools 页,然后在下拉菜单中选择 Command Line Tools

流程

  1. Command Line Tools 页下载 kn CLI。
  2. 解包存档:

    $ tar -xf <file>
  3. kn 二进制文件迁移至 PATH 上的目录中。
  4. 要查看路径,请运行:

    $ echo $PATH
    注意

    如果不使用 RHEL 或 Fedora,请确保将 libc 安装在库路径的目录中。如果 libc 不可用,您在运行 CLI 命令时可能会看到以下错误:

    $ kn: No such file or directory

4.2. 使用 RPM 为 Linux 安装 kn CLI

对于 Red Hat Enterprise Linux (RHEL),如果您的红帽帐户上已有活跃的 OpenShift Container Platform 订阅,则可将 kn 安装为 RPM。

流程

  1. 输入命令:

    # subscription-manager register
  2. 输入命令:

    # subscription-manager refresh
  3. 输入命令:

    # subscription-manager attach --pool=<pool_id> 1
    1
    活跃的 OpenShift Container Platform 订阅的池 ID
  4. 输入命令:

    # subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-x86_64-rpms"
  5. 输入命令:

    # yum install openshift-serverless-clients

4.3. 为 Linux 安装 kn CLI

对于 Linux 系统,您可以直接将 CLI 下载为 tar.gz 存档。

流程

  1. 下载 CLI
  2. 解包存档:

    $ tar -xf <file>
  3. kn 二进制文件迁移至 PATH 上的目录中。
  4. 要查看路径,请运行:

    $ echo $PATH
    注意

    如果不使用 RHEL 或 Fedora,请确保将 libc 安装在库路径的目录中。如果 libc 不可用,您在运行 CLI 命令时可能会看到以下错误:

    $ kn: No such file or directory

4.4. 为 macOS 安装 kn CLI

用于 macOS 的 kntar.gz 存档形式提供。

流程

  1. 下载 CLI
  2. 解包和解压存档。
  3. kn 二进制文件迁移至 PATH 上的目录中。
  4. 要查看 PATH,请打开终端窗口并运行:

    $ echo $PATH

4.5. 为 Windows 安装 kn CLI

用于 Windows 的 CLI 以 zip 存档形式提供。

流程

  1. 下载 CLI
  2. 使用 ZIP 程序解压存档。
  3. kn 二进制文件迁移至 PATH 上的目录中。
  4. 要查看您的 PATH,请打开命令提示并运行以下命令:

    C:\> path

第 5 章 管理指南

5.1. 安装 OpenShift Serverless

本指南指导集群管理员将 OpenShift Serverless Operator 安装至 OpenShift Container Platform 集群。

注意

OpenShift Serverless 支持在受限网络环境中安装。如需更多信息,请参阅 在受限网络中使用 Operator Lifecycle Manager

重要

升级到最新的 Serverless 版本前,您必须删除社区版本的 Knative Eventing Operator。安装 Knative Eventing Operator 后,您将无法使用 OpenShift Serverless Operator 安装最新版本的 Knative Eventing。

5.1.1. 为 OpenShift Serverless 安装定义集群大小要求

要安装和使用 OpenShift Serverless,OpenShift Container Platform 集群必须正确定义大小。OpenShift Serverless 的最低要求是集群有 10 个 CPU 和 40GB 内存。运行 OpenShift Serverless 的总大小要求取决于部署的应用程序。默认情况下,每个 pod 请求大约 400m CPU,因此最低要求会基于此值。在提供的大小要求中,应用程序最多可扩展至 10 个副本。降低应用程序的实际 CPU 请求可增加可能的副本数。

注意

所提供的要求仅与 OpenShift Container Platform 集群的 worker 机器池相关。Master 节点不用于常规调度,它不在要求的范围内。

注意

以下限制适用于所有 OpenShift Serverless 部署:

  • Knative 服务的最大数量: 1000
  • Knative 修订版本的最大数量: 1000

5.1.2. 高级用例所需的额外资源

对于更复杂的用例,如日志、OpenShift Container Platform 指标数据等,必须部署更多资源。对这类用例的推荐要求为 24 个 CPU 和 96GB 内存。

如果您在集群中启用了高可用性 (HA),需要 0.5 - 1.5 个内核,每个 Knative Serving control plane 副本需要 200MB 到 2GB 内存。一些 Knative Serving 组件在默认情况下启用了 HA。您可以按照在 OpenShift Serverless 中配置高可用性副本的文档中的内容禁用 HA。

5.1.3. 使用机器集扩展集群

您可以使用 OpenShift Container Platform MachineSet API 手动将集群扩展至所需大小。最低要求通常意味着,您需要将一个默认机器集进行扩展,增加两个额外的机器。请参阅手动扩展机器集

5.1.4. 安装 OpenShift Serverless Operator

本节介绍了使用 OpenShift Container Platform Web 控制台从 OperatorHub 安装并订阅 OpenShift Serverless Operator 的方法。

流程

  1. 在 OpenShift Container Platform web 控制台中导航至 OperatorsOperatorHub 页。
  2. 滚动页面,或在 Filter by keyword 框中输入关键字 Serverless 以查找 OpenShift Serverless Operator。

    OpenShift Serverless Operator in the OpenShift Container Platform web console
  3. 查看 Operator 信息并单击 Install
  4. Install Operator 页面中:

    1. Installation ModeAll namespaces on the cluster (default)。此模式将 Operator 安装至默认 openshift-serverless 命名空间,以便供集群中的所有命名空间监视和使用。
    2. 安装的命名空间openshift-serverless
    3. 选择 4.6 频道作为 更新频道4.6 频道将启用 OpenShift Serverless Operator 最新稳定版本的安装。
    4. 选择 AutomaticManual 批准策略。
  5. 点击 Install 使 Operator 可供 OpenShift Container Platform 集群上的所选命名空间使用。
  6. CatalogOperator Management 页面中,您可以监控 OpenShift Serverless Operator 订阅的安装和升级进度。

    1. 如果选择了 Manual 批准策略,订阅的升级状态将会一直保持在 Upgrading,直到您审阅并批准了它的安装计划。在 Install Plan 页面批准后,订阅的升级状态将变为 Up to date
    2. 如果选择了 Automatic 批准策略,升级状态会在不用人工参与的情况下变为 Up to date

验证

当订阅的升级状态变为Up to date 后,选择 CatalogInstalled Operators 来验证 OpenShift Serverless Operator 最终出现,它的 Status 在相关的命名空间中最终会变为 InstallSucceeded

如果没有:

  1. 切换到 CatalogOperator Management 页,检查 Operator SubscriptionsInstall Plans 页中的 Status 是否有错误。
  2. 检查 WorkloadsPods 页中提供的关于openshift-serverless 项目中的 pod 的日志信息,以便进一步排除故障。

5.1.5. 后续步骤

  • 安装 OpenShift Serverless Operator 后,您可以安装 Knative Serving 组件。请参阅有关安装 Knative Serving 的文档。
  • 安装 OpenShift Serverless Operator 后,您可以安装 Knative Eventing 组件。请参阅有关安装 Knative Eventing 的文档。

5.2. 安装 Knative Serving

安装 OpenShift Serverless Operator 后,您可以安装 Knative Serving。本指南提供有关使用默认设置安装 Knative Serving 的信息。但是,您可以在 KnativeServing 自定义资源定义(CRD)中配置更高级的设置。如需有关 KnativeServing CRD 配置选项的更多信息,请参阅高级安装配置选项

5.2.1. 先决条件

  • 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
  • 已安装 OpenShift Serverless Operator。

5.2.2. 使用 Web 控制台安装 Knative Serving

流程

  1. 在 OpenShift Container Platform web 控制台的 Administrator 视角中,进入 OperatorsInstalled Operators
  2. 检查页面顶部的 Project 下拉菜单是否已设置为 Project: knative-serving
  3. 点击 OpenShift Serverless Operator 的 Provided APIs 列表中的 Knative Serving 来进入 Knative Serving 选项卡。

    Installed Operators 页
  4. 点击 Create Knative Serving 按钮。

    Knative Serving 标签页
  5. Create Knative Serving 页中,您可以使用默认设置安装 Knative Serving。点 Create

    您还可以使用提供的表单或编辑 YAML 来修改 KnativeServing 对象来修改 Knative Serving 安装的设置。

    • 建议您在不需要完全控制 KnativeServing 对象创建的简单配置中使用该表单。
    • 对于更复杂的配置,建议编辑 YAML,这可以完全控制 KnativeServing 对象的创建。您可以通过点击 Create Knative Serving 页右上角的 edit YAML 链接来访问 YAML。

      完成表单后,或者完成对 YAML 的修改后,点 Create

      注意

      如需有关 KnativeServing 自定义资源定义的配置选项的更多信息,请参阅 高级安装配置选项

      在表格视图中创建 Knative Serving
      在 YAML 视图中创建 Knative Serving
  6. 安装 Knative Serving 后,将创建 KnativeServing 对象,并将自动定向到 Knative Serving 选项卡。

    Installed Operators 页

    您可以在资源列表中看到 knative-serving 自定义资源。

验证

  1. Knative Serving 选项卡中点 knative-serving 自定义资源。
  2. 您将被自动定向到 Knative Serving Overview 页面。

    Installed Operators 页
  3. 向下滚动查看条件列表。
  4. 您应该看到一个状况为 True的条件列表,如示例镜像所示。

    条件
    注意

    创建 Knative Serving 资源可能需要几秒钟时间。您可以在 Resources 选项卡中查看其状态。

  5. 如果条件状态为 UnknownFalse,请等待几分钟,然后在确认已创建资源后再重新检查。

5.2.3. 使用 YAML 安装 Knative Serving

流程

  1. 创建名为 serving.yaml 的文件并将以下示例 YAML 复制到其中:

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
        name: knative-serving
        namespace: knative-serving
  2. 应用 service.yaml 文件:

    $ oc apply -f serving.yaml

验证

  1. 使用以下命令校验安装是否完成:

    $ oc get knativeserving.operator.knative.dev/knative-serving -n knative-serving --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'

    输出示例

    DependenciesInstalled=True
    DeploymentsAvailable=True
    InstallSucceeded=True
    Ready=True

    注意

    创建 Knative Serving 资源可能需要几秒钟时间。

  2. 如果条件状态为 UnknownFalse,请等待几分钟,然后在确认已创建资源后再重新检查。
  3. 使用以下命令检查是否已创建了 Knative Serving 资源:

    $ oc get pods -n knative-serving

    输出示例

    NAME                               READY   STATUS    RESTARTS   AGE
    activator-5c596cf8d6-5l86c         1/1     Running   0          9m37s
    activator-5c596cf8d6-gkn5k         1/1     Running   0          9m22s
    autoscaler-5854f586f6-gj597        1/1     Running   0          9m36s
    autoscaler-hpa-78665569b8-qmlmn    1/1     Running   0          9m26s
    autoscaler-hpa-78665569b8-tqwvw    1/1     Running   0          9m26s
    controller-7fd5655f49-9gxz5        1/1     Running   0          9m32s
    controller-7fd5655f49-pncv5        1/1     Running   0          9m14s
    kn-cli-downloads-8c65d4cbf-mt4t7   1/1     Running   0          9m42s
    webhook-5c7d878c7c-n267j           1/1     Running   0          9m35s

5.2.4. 后续步骤

  • 对于 OpenShift Serverless 上的云事件功能,您可以安装 Knative Eventing 组件。请参阅有关安装 Knative Eventing 的文档。
  • 安装 Knative CLI,在 Knative Serving 中使用 kn 命令。例如: kn service 命令。请参阅有关安装 Knative CLI (kn) 的文档。

5.3. 安装 Knative Eventing

安装 OpenShift Serverless Operator 后,您可以按照本指南中介绍的步骤安装 Knative Eventing。

本指南提供有关使用默认设置安装 Knative Eventing 的信息。

5.3.1. 先决条件

  • 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
  • 已安装 OpenShift Serverless Operator。

5.3.2. 使用 web 控制台安装 Knative Eventing

流程

  1. 在 OpenShift Container Platform web 控制台的 Administrator 视角中,进入 OperatorsInstalled Operators
  2. 检查页面顶部的 Project 下拉菜单是否已设置为 Project: knative-eventing
  3. 点击 OpenShift Serverless Operator 的 Provided APIs 列表中的 Knative Eventing 来进入 Knative Eventing 选项卡。

    Installed Operators 页
  4. 点击 Create Knative Eventing 按钮。

    Knative Eventing 选项卡
  5. Create Knative Eventing 页面中,您可以选择使用提供的默认表单或编辑 YAML 来配置 KnativeEventing 对象。

    • 建议您在不需要完全控制 KnativeEventing 对象创建的简单配置中使用该表单。

      可选。如果您要使用表单配置 KnativeEventing 对象,请为您的 Knative Eventing 部署进行任何要实现的更改。

  6. 点击 Create

    使用表单创建 Knative Eventing
    • 对于更复杂的配置,建议编辑 YAML,这可以完全控制 KnativeEventing 对象的创建。您可以通过点击 Create Knative Eventing 页右上角的 edit YAML 链接来访问 YAML。

      可选。如果您要通过编辑 YAML 配置 KnativeEventing 对象,请对您希望用于 Knative Eventing 部署的 YAML 进行更改。

  7. 点击 Create

    使用 YAML 创建 Knative Eventing
  8. 安装 Knative Eventing 后,将创建 KnativeEventing 对象,并将自动定向到 Knative Eventing 选项卡。

    Installed Operators 页

    您可以在资源列表中看到 knative-eventing 自定义资源。

验证

  1. Knative Eventing 选项卡中的 knative-eventing 自定义资源。
  2. 您将被自动定向到 Knative Eventing Overview 页面。

    Knative Eventing 概述页面
  3. 向下滚动查看条件列表。
  4. 您应该看到一个状况为 True的条件列表,如示例镜像所示。

    条件
    注意

    创建 Knative Eventing 资源可能需要几秒钟时间。您可以在 Resources 选项卡中查看其状态。

  5. 如果条件状态为 UnknownFalse,请等待几分钟,然后在确认已创建资源后再重新检查。

5.3.3. 使用 YAML 安装 Knative Eventing

流程

  1. 创建名为 eventing.yaml 的文件。
  2. 将以下示例 YAML 复制到 eventing.yaml中:

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeEventing
    metadata:
        name: knative-eventing
        namespace: knative-eventing
  3. 可选。根据您的 Knative Eventing 部署,对 YAML 进行相应的更改。
  4. 输入以下内容来应用 eventing.yaml 文件:

    $ oc apply -f eventing.yaml

验证

  1. 输入以下命令验证安装是否完成,并观察输出结果:

    $ oc get knativeeventing.operator.knative.dev/knative-eventing \
      -n knative-eventing \
      --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'

    输出示例

    InstallSucceeded=True
    Ready=True

    注意

    创建 Knative Eventing 资源可能需要几秒钟时间。

  2. 如果条件状态为 UnknownFalse,请等待几分钟,然后在确认已创建资源后再重新检查。
  3. 使用以下命令检查是否已创建 Knative Eventing 资源:

    $ oc get pods -n knative-eventing

    输出示例

    NAME                                   READY   STATUS    RESTARTS   AGE
    broker-controller-58765d9d49-g9zp6     1/1     Running   0          7m21s
    eventing-controller-65fdd66b54-jw7bh   1/1     Running   0          7m31s
    eventing-webhook-57fd74b5bd-kvhlz      1/1     Running   0          7m31s
    imc-controller-5b75d458fc-ptvm2        1/1     Running   0          7m19s
    imc-dispatcher-64f6d5fccb-kkc4c        1/1     Running   0          7m18s

5.3.4. 后续步骤

  • 安装 Knative CLI 在 Knative Eventing 中使用 kn 命令。例如: kn source 命令。请参阅安装 Knative CLI

5.4. 高级安装配置选项

本指南向集群管理员提供有关 OpenShift Serverless 组件的高级安装配置选项的信息。

5.4.1. Knative Serving 支持的安装配置选项

重要

不要修改 config 字段中包含的任何 YAML。此字段中的一些配置值被 OpenShift Serverless Operator 注入,修改后,您的部署将不被支持。

在 Web 控制台管理员视角中创建 Knative Serving 表单

5.4.1.1. 控制器自定义证书

如果您的容器镜像仓库使用自签名证书,则必须通过创建配置映射或 secret 来启用标签到摘要(tag-to-digest)的解析。要启用标签到摘要的解析功能,Knative Serving 控制器需要可以访问容器 registry。

以下示例 KnativeServing 自定义资源配置使用 knative-serving 命名空间中名为 certs 的配置映射中的证书。本例会触发 OpenShift Serverless Operator:

  1. 在控制器中创建并挂载包含证书的卷。
  2. 正确设置需要的环境变量。

YAML 示例

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  controller-custom-certs:
    name: config-service-ca
    type: ConfigMap 1

1
支持的类型为 ConfigMapSecret

如果没有指定控制器自定义证书,此设置默认为使用 config-service-ca 配置映射。

启用 tag-to-digest 解析后,OpenShift Serverless Operator 会自动配置 Knative Serving 控制器对容器镜像仓库的访问。

重要

配置映射或 secret 必须位于与 Knative Serving 自定义资源定义(CRD)相同的命名空间中。

5.4.1.2. 高可用性

如果用户在 Knative Serving 安装过程中没有指定副本数,高可用性(可以使用 spec.high-availability 字段配置),则被默认为每个控制器有 2 个副本。

您可以将其设置为 1 来禁用高可用性(HA),或通过设置更高的整数来添加更多副本。

YAML 示例

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  high-availability:
    replicas: 2

5.4.2. 其他资源

5.5. 升级 OpenShift Serverless

如果安装了 OpenShift Serverless 的早期版本,请按照本指南中的说明升级到最新版本。

重要

升级到最新的 Serverless 版本前,您必须删除社区版本的 Knative Eventing Operator。安装 Knative Eventing Operator 后,您将无法安装最新版本的 Knative Eventing。

5.5.1. 升级订阅频道

先决条件

  • 已安装了一个 OpenShift Serverless Operator 的旧版本,并在安装过程中选择了自动更新。

    注意

    如果您选择了“手动更新”,在更新频道后您将需要完成本指南中介绍的附加步骤。订阅的升级状态将保持在Upgrading,直至您审核并批准了该安装计划。有关安装计划(Install Plan)的详情,请参考 OpenShift Container Platform Operator 文档。

  • 已登陆到 OpenShift Container Platform Web 控制台。

流程

  1. 在 OpenShift Container Platform web 控制台中,选择 openshift-operators 命名空间。
  2. 导航到 OperatorsInstalled Operators 页面。
  3. 选择 OpenShift Serverless Operator Operator
  4. SubscriptionChannel
  5. Change Subscription Update Channel 窗口中,选择 4.6 并点 Save
  6. 等待 knative-serving 命名空间中的所有 Pod 都已升级,KnativeServing 自定义资源会报告最新的 Knative Serving 版本。

验证

要验证升级是否成功,您可以检查 knative-serving 命名空间中的 pod 状态,以及 KnativeServing 自定义资源的版本。

  1. 检查 pod 的状态:

    $ oc get knativeserving.operator.knative.dev knative-serving -n knative-serving -o=jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

    这个命令应该返回 True 状态。

  2. 检查 KnativeServing 自定义资源的版本:

    $ oc get knativeserving.operator.knative.dev knative-serving -n knative-serving -o=jsonpath='{.status.version}'

    此命令应返回 Knative Serving 的最新版本。您可在 OpenShift Serverless Operator 发行注记中查看最新版本。

5.6. 删除 OpenShift Serverless

本指南详细介绍了如何删除 OpenShift Serverless Operator 和其它 OpenShift Serverless 组件。

注意

在删除 OpenShift Serverless Operator 之前,您必须删除 Knative Serving 和 Knative Eventing。

5.6.1. 卸载 Knative Serving

要卸载 Knative Serving,必须移除其自定义资源并移除 knative-serving 命名空间。

流程

  1. 删除 knative-serving 自定义资源:

    $ oc delete knativeservings.operator.knative.dev knative-serving -n knative-serving
  2. 在该命令运行完成且已从 knative-serving 命名空间中移除所有 Pod 后,删除命名空间:

    $ oc delete namespace knative-serving

5.6.2. 卸载 Knative Eventing

要卸载 Knative Eventing,必须移除其自定义资源并移除 knative-eventing 命名空间。

流程

  1. 删除 knative-eventing 自定义资源:

    $ oc delete knativeeventings.operator.knative.dev knative-eventing -n knative-eventing
  2. 在该命令运行完成且已从 knative-eventing 命名空间中移除所有 Pod 后,删除命名空间:

    $ oc delete namespace knative-eventing

5.6.3. 删除 OpenShift Serverless Operator

您可以根据从集群中删除 Operators 中的介绍从主机集群中删除 OpenShift Serverless Operator。

5.6.4. 删除 OpenShift Serverless 自定义资源定义

卸载 OpenShift Serverless 后,Operator 和 API 自定义资源定义(CRD)会保留在集群中。您可以使用以下步骤删除剩余的 CRD。

重要

移除 Operator 和 API CRD 也会移除所有使用它们定义的资源,包括 Knative 服务。

5.6.5. 先决条件

  • 您已卸载了 Knative Serving 并移除了 OpenShift Serverless Operator。

流程

  • 运行以下命令删除 OpenShift Serverless CRD:

    $ oc get crd -oname | grep 'knative.dev' | xargs oc delete

5.7. 以集群管理员身份创建 Eventing 组件

如果您在 OpenShift Container Platform 集群上具有集群管理员权限,则可以在 web 控制台的 Administrator 视角中使用 OpenShift Serverless 创建 Knative Eventing 组件,或使用 knoc CLI 创建 Knative Eventing 组件。

5.7.1. 使用 Administrator 视角创建事件源

如果您有集群管理员权限,可以使用 web 控制台中的 Administrator 视角创建事件源。

先决条件

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
  • 具有集群管理员 OpenShift Container Platform 的权限。

流程

  1. 在 OpenShift Container Platform Web 控制台的 Administrator 视角中,导航到 ServerlessEventing
  2. Create 列表中,选择 Event Source。您将被定向到 Event Sources 页面。
  3. 选择您要创建的事件源类型。

如需有关支持哪些事件源的更多信息,请参阅使用事件源入门,以了解 OpenShift Serverless 可创建哪些事件源类型。

5.7.2. 使用 Administrator 视角创建代理

如果您有集群管理员权限,则可以使用 web 控制台中的 Administrator 视角创建代理。

先决条件

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
  • 具有集群管理员 OpenShift Container Platform 的权限。

流程

  1. 在 OpenShift Container Platform Web 控制台的 Administrator 视角中,导航到 ServerlessEventing
  2. Create 列表中,选择 Broker。您将进入 Create Broker 页面。
  3. 可选:修改代理的 YAML 配置。
  4. 点击 Create

5.7.3. 通过标记命名空间来创建代理

如果您有集群管理员权限,可以通过标记命名空间来自动创建 default 代理。

注意

如果删除该标签,不会删除使用这个方法创建的代理。您必须手动删除它们。

先决条件

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
  • 具有集群管理员 OpenShift Container Platform 的权限。

流程

  • 使用 eventing.knative.dev/injection=enabled 标识一个命名空间:

    $ oc label namespace <namespace> eventing.knative.dev/injection=enabled

验证

您可以使用 oc CLI,或使用 web 控制台中的 Topology 视图来验证代理是否已成功创建。

  1. 使用 oc 命令获取代理:

    $ oc -n <namespace> get broker <broker_name>

    示例命令

    $ oc -n default get broker default

    输出示例

    NAME      READY     REASON    URL                                                                     AGE
    default   True                http://broker-ingress.knative-eventing.svc.cluster.local/test/default   3m56s

  2. 进入 web 控制台中的 Topology 视图以查看存在的代理:

    在 web 控制台 Topology 视图中查看代理

5.7.4. 删除通过注入创建的代理

如果开发人员删除了标签或注解,则由注入创建的代理(使用命名空间标签或触发器注解)不会永久删除。这些代理需要具有集群管理员权限的用户手动删除。

流程

  1. 从命名空间中删除 eventing.knative.dev/injection=enabled 标识:

    $ oc label namespace <namespace> eventing.knative.dev/injection-

    移除注解可防止 Knative 在删除代理后重新创建代理。

  2. 从所选命名空间中删除代理:

    $ oc -n <namespace> delete broker <broker_name>

验证

  • 使用 oc 命令获取代理:

    $ oc -n <namespace> get broker <broker_name>

    示例命令

    $ oc -n default get broker default

    输出示例

    No resources found.
    Error from server (NotFound): brokers.eventing.knative.dev "default" not found

5.7.5. 使用 Administrator 视角创建触发器

如果您有集群管理员权限并创建了代理,您可以使用 web 控制台中的 Administrator 视角创建一个触发器将代理连接到订阅者。

先决条件

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
  • 具有集群管理员 OpenShift Container Platform 的权限。
  • 您已创建了代理。
  • 您已创建了 Knative 服务以用作订阅者。

流程

  1. 在 OpenShift Container Platform Web 控制台的 Administrator 视角中,导航到 ServerlessEventing
  2. Broker 选项卡中,为您要在其中添加触发器的代理选择 Options 菜单 kebab
  3. 点列表中的 Add Trigger
  4. Add Trigger 对话框中,为触发器选择 Subscriber。订阅者是可以从代理接收事件的 Knative 服务。
  5. Add

5.7.6. 使用 Administrator 视角创建频道

如果您有集群管理员权限,可以使用 web 控制台中的 Administrator 视角创建频道。

先决条件

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
  • 具有集群管理员 OpenShift Container Platform 的权限。

流程

  1. 在 OpenShift Container Platform Web 控制台的 Administrator 视角中,导航到 ServerlessEventing
  2. Create 列表中,选择 Channel。您将被定向到 Channel 页。
  3. Type 下拉菜单中选择您要创建的 Channel 对象类型。

    注意

    目前默认只支持 InMemoryChannel 频道对象。如果您在 OpenShift Serverless 上安装了 Apache Kafka,则 Kafka 频道会作为技术预览提供。

  4. 点击 Create

5.7.7. 使用 Administrator 视角创建订阅

如果您有集群管理员权限并创建了频道,可以使用 web 控制台中的 Administrator 视角创建一个订阅将代理连接到订阅者。

先决条件

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
  • 具有集群管理员 OpenShift Container Platform 的权限。
  • 您已创建了频道。
  • 您已创建了 Knative 服务以用作订阅者。

流程

  1. 在 OpenShift Container Platform Web 控制台的 Administrator 视角中,导航到 ServerlessEventing
  2. Channel 选项卡中,选择您要在其中添加订阅的频道的 Options 菜单 kebab
  3. 点击列表中的 Add Subscription
  4. Add Subscription 对话框中,为订阅选择 Subscriber。订阅者是可以从频道接收事件的 Knative 服务。
  5. Add

5.7.8. 其他资源

5.8. 以集群管理员身份创建 Serving 组件

如果您在 OpenShift Container Platform 集群上具有集群管理员权限,则可以在 web 控制台的 Administrator 视角中使用 OpenShift Serverless 创建 Knative Serving 组件,或使用 knoc CLI 创建 Knative Eventing 组件。

5.8.1. 使用管理员视角创建无服务器应用程序

先决条件

要使用 管理员 视角创建无服务器应用程序,请确定您已完成了以下步骤。

  • 安装了 OpenShift Serverless Operator 和 Knative Serving。
  • 您已登录到 Web 控制台,且处于 Administrator 视角。

流程

  1. 进入 ServerlessServing 页面。
  2. Create 列表中,选择 Service
  3. 手动输入 YAML 或 JSON 定义,或者将文件拖放到编辑器中。
  4. 点击 Create

5.9. 使用 OpenShift Serverless 的 metering

作为集群管理员,您可使用 Metering 来分析 OpenShift Serverless 集群中的情况。

如需有关 OpenShift Container Platform 的 metering 的更多信息,请参阅 关于 metering

5.9.1. 安装 metering

有关在 OpenShift Container Platform 上安装 metering 的详情请参考 Installing Metering

5.9.2. Knative making metering 的数据源

以下 ReportDataSources 是 OpenShift Container Platform metering 如何使用 Knative instructioning 的示例。

5.9.2.1. Knativelatesting 中 CPU 用量的数据源

这个数据源提供在报告的时间段内每个 Knative 服务使用的总 CPU 秒数。

yaml 文件

apiVersion: metering.openshift.io/v1
kind: ReportDataSource
metadata:
  name: knative-service-cpu-usage
spec:
  prometheusMetricsImporter:
    query: >
      sum
          by(namespace,
             label_serving_knative_dev_service,
             label_serving_knative_dev_revision)
          (
            label_replace(rate(container_cpu_usage_seconds_total{container!="POD",container!="",pod!=""}[1m]), "pod", "$1", "pod", "(.*)")
            *
            on(pod, namespace)
            group_left(label_serving_knative_dev_service, label_serving_knative_dev_revision)
            kube_pod_labels{label_serving_knative_dev_service!=""}
          )

5.9.2.2. 用于 Knative making 中的内存使用的数据源

这个数据源为每个 Knative 服务在报告期间提供平均内存消耗。

yaml 文件

apiVersion: metering.openshift.io/v1
kind: ReportDataSource
metadata:
  name: knative-service-memory-usage
spec:
  prometheusMetricsImporter:
    query: >
      sum
          by(namespace,
             label_serving_knative_dev_service,
             label_serving_knative_dev_revision)
          (
            label_replace(container_memory_usage_bytes{container!="POD", container!="",pod!=""}, "pod", "$1", "pod", "(.*)")
            *
            on(pod, namespace)
            group_left(label_serving_knative_dev_service, label_serving_knative_dev_revision)
            kube_pod_labels{label_serving_knative_dev_service!=""}
          )

5.9.2.3. 为 KnativeUping metering 应用数据源

您可以使用以下命令应用 ReportDataSources

$ oc apply -f <datasource_name>.yaml

示例

$ oc apply -f knative-service-memory-usage.yaml

5.9.3. 对 Knative Serving metering 的查询

以下 ReportQuery 资源引用提供的 DataSources 示例。

5.9.3.1. 在 Knativelatesting 中查询 CPU 用量

yaml 文件

apiVersion: metering.openshift.io/v1
kind: ReportQuery
metadata:
  name: knative-service-cpu-usage
spec:
  inputs:
  - name: ReportingStart
    type: time
  - name: ReportingEnd
    type: time
  - default: knative-service-cpu-usage
    name: KnativeServiceCpuUsageDataSource
    type: ReportDataSource
  columns:
  - name: period_start
    type: timestamp
    unit: date
  - name: period_end
    type: timestamp
    unit: date
  - name: namespace
    type: varchar
    unit: kubernetes_namespace
  - name: service
    type: varchar
  - name: data_start
    type: timestamp
    unit: date
  - name: data_end
    type: timestamp
    unit: date
  - name: service_cpu_seconds
    type: double
    unit: cpu_core_seconds
  query: |
    SELECT
      timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart| prestoTimestamp |}' AS period_start,
      timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}' AS period_end,
      labels['namespace'] as project,
      labels['label_serving_knative_dev_service'] as service,
      min("timestamp") as data_start,
      max("timestamp") as data_end,
      sum(amount * "timeprecision") AS service_cpu_seconds
    FROM {| dataSourceTableName .Report.Inputs.KnativeServiceCpuUsageDataSource |}
    WHERE "timestamp" >= timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart | prestoTimestamp |}'
    AND "timestamp" < timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}'
    GROUP BY labels['namespace'],labels['label_serving_knative_dev_service']

5.9.3.2. 在 Knative Serving 中查询内存用量

yaml 文件

apiVersion: metering.openshift.io/v1
kind: ReportQuery
metadata:
  name: knative-service-memory-usage
spec:
  inputs:
  - name: ReportingStart
    type: time
  - name: ReportingEnd
    type: time
  - default: knative-service-memory-usage
    name: KnativeServiceMemoryUsageDataSource
    type: ReportDataSource
  columns:
  - name: period_start
    type: timestamp
    unit: date
  - name: period_end
    type: timestamp
    unit: date
  - name: namespace
    type: varchar
    unit: kubernetes_namespace
  - name: service
    type: varchar
  - name: data_start
    type: timestamp
    unit: date
  - name: data_end
    type: timestamp
    unit: date
  - name: service_usage_memory_byte_seconds
    type: double
    unit: byte_seconds
  query: |
    SELECT
      timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart| prestoTimestamp |}' AS period_start,
      timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}' AS period_end,
      labels['namespace'] as project,
      labels['label_serving_knative_dev_service'] as service,
      min("timestamp") as data_start,
      max("timestamp") as data_end,
      sum(amount * "timeprecision") AS service_usage_memory_byte_seconds
    FROM {| dataSourceTableName .Report.Inputs.KnativeServiceMemoryUsageDataSource |}
    WHERE "timestamp" >= timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart | prestoTimestamp |}'
    AND "timestamp" < timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}'
    GROUP BY labels['namespace'],labels['label_serving_knative_dev_service']

5.9.3.3. 为 Knative Serving metering 应用查询

  1. 输入以下命令应用 ReportQuery:

    $ oc apply -f <query-name>.yaml
    $ oc apply -f knative-service-memory-usage.yaml

5.9.4. Knative Serving 的 metering 报告

您可以通过创建 Report 资源来针对 Knative Serving 运行 metering 报告。在您运行报告前,您必须修改 Report 资源中的输入参数,以指定报告周期的开始和结束日期。

yaml 文件

apiVersion: metering.openshift.io/v1
kind: Report
metadata:
  name: knative-service-cpu-usage
spec:
  reportingStart: '2019-06-01T00:00:00Z' 1
  reportingEnd: '2019-06-30T23:59:59Z' 2
  query: knative-service-cpu-usage 3
runImmediately: true

1
报告的开始日期,格式为 ISO 8601 。
2
报告的结束日期,格式为 ISO 8601。
3
用于 CPU 用量报告的 knative-service-cpu-usage,或用于内存用量报告的 knative-service-memory-usage

5.9.4.1. 运行 metering 报告

  1. 输入以下命令运行报告:

    $ oc apply -f <report-name>.yml
  2. 然后您可以输入以下命令来检查报告:

    $ oc get report
    NAME                        QUERY                       SCHEDULE   RUNNING    FAILED   LAST REPORT TIME       AGE
    knative-service-cpu-usage   knative-service-cpu-usage              Finished            2019-06-30T23:59:59Z   10h

第 6 章 架构

6.1. Knative Serving 架构

OpenShift Container Platform 上的 Knative Serving 可让开发人员使用 无服务器架构 编写 云原生应用程序。Serverless 是一个云计算模式,应用程序开发人员不需要为其应用程序置备服务器或管理扩展。这些常规任务由平台自身进行管理,因此,和传统模型相比,开发人员可以更快地将代码推送到生产环境。

Knative Serving 通过提供一组用于定义和控制 OpenShift Container Platform 集群上的无服务器工作负载行为的 Kubernetes 自定义资源定义(CRD)支持部署和管理云原生应用程序。如需有关 CRD 的更多信息,请参阅 使用自定义资源定义扩展 Kubernetes API

开发人员使用这些 CRD 创建自定义资源(CR)实例,这些实例可作为构建块用于处理复杂用例。例如:

  • 快速部署无服务器容器。
  • 自动缩放 pod

如需有关 CR 的更多信息, 请参阅从自定义资源定义中管理资源

6.1.1. Knative Serving 自定义资源定义

Service
service.serving.knative.dev CRD 会自动管理工作负载的生命周期,以确保应用程序通过网络部署并可访问。每次用户创建的服务或自定义资源发生变化时,它都会创建一个路由、配置和新修订版本。Knative 中进行的大多数开发人员交互都是通过修改服务进行的。
修订
revision.serving.knative.dev CRD 是每次对工作负载进行修改所涉及代码和配置的时间点快照。所有修订版本均为不可变对象,可以根据需要保留。
Route
route.serving.knative.dev CRD 可将网络端点映射到一个或多个修订版本。您可通过多种方式管理流量,包括部分流量和指定路由。
Configuration
configuration.serving.knative.dev CRD 可保持部署所需状态。它可在使编程过程和配置配置过程相互分离。修改配置则会创建一个新修订版本。

6.2. Knative Eventing 架构

OpenShift Container Platform 上的 Knative Eventing 可让开发人员使用 事件驱动的架构 和无服务器应用程序。事件驱动的构架所基于的概念是,创建事件、事件 sink 的人员和使用它们的用户之间是分离的。

Knative Eventing 使用标准 HTTP POST 请求来发送和接收事件创建者和用户之间的事件。这些事件符合 CloudEvents 规范,它允许在任何编程语言中创建、解析、发送和接收事件。

您可以使用以下方法将 事件从事件源 传播到多个事件 sink:

如果目标 sink 不可用,则会缓冲事件。Knative Eventing 支持以下场景:

在不创建消费者的情况下发布事件
您可以将事件作为 HTTP POST 发送到代理,并使用 SinkBinding 分离生成事件的应用程序的目标配置。
在不创建发布程序的情况下消耗事件
您可以使用 Trigger 来根据事件属性消耗来自代理的事件。您的应用程序将以 HTTP POST 的形式接收事件。

6.2.1. 事件 sink

要启用多种 sink 类型的交付,Knative Eventing 会定义以下通用接口,这些接口可由多个 Kubernetes 资源实现:

可寻址的对象
能够接收和确认通过 HTTP 发送的事件到 Event 的 status.address.url 字段中定义的地址。Kubernetes Service 对象也满足可寻址的接口。
可调用的对象
能够通过 HTTP 接收事件并转换它,并在 HTTP 响应有效负载中返回 0 或 1 新事件。这些返回的事件可能会象处理外部事件源中的 Events 一样进一步处理。

第 7 章 创建并管理无服务器应用程序

7.1. 使用 Knative 服务的无服务器应用程序

要使用 OpenShift Serverless 部署无服务器应用程序,必须创建 Knative 服务。Knative 服务是 Kubernetes 服务,由包括在一个 YAML 文件中的一个路由和一个配置定义。

Knative 服务 YAML 示例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello 1
  namespace: default 2
spec:
  template:
    spec:
      containers:
        - image: docker.io/openshift/hello-openshift 3
          env:
            - name: RESPONSE 4
              value: "Hello Serverless!"

1
应用程序的名称。
2
应用程序要使用的命名空间。
3
应用程序的镜像。
4
示例应用程序输出的环境变量。

使用以下任一方法创建一个无服务器应用程序:

  • 从 OpenShift Container Platform web 控制台创建 Knative 服务。
  • 使用 kn CLI 创建 Knative 服务。
  • 创建和应用 YAML 文件。

7.2. 使用 Developer 视角创建应用程序

有关在 OpenShift Container Platform 中使用 Developer 视角创建应用程序的更多信息,请参阅 使用 Developer 视角创建应用程序

7.3. 使用 CLI 创建无服务器应用程序

以下流程描述了如何使用 kn CLI 创建基本无服务器应用程序。

先决条件

  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
  • 安装了 kn CLI。

流程

  • 创建 Knative 服务:

    $ kn service create <service-name> --image <image> --env <key=value>

    示例命令

    $ kn service create event-display \
        --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

    输出示例

    Creating service 'event-display' in namespace 'default':
    
      0.271s The Route is still working to reflect the latest desired specification.
      0.580s Configuration "event-display" is waiting for a Revision to become ready.
      3.857s ...
      3.861s Ingress has not yet been reconciled.
      4.270s Ready to serve.
    
    Service 'event-display' created with latest revision 'event-display-bxshg-1' and URL:
    http://event-display-default.apps-crc.testing

7.4. 使用 YAML 创建无服务器应用程序

要使用 YAML 创建无服务器应用程序,您必须创建一个 YAML 文件来定义一个 Service 对象,然后使用 oc apply 来应用它。

流程

  1. 创建包含以下示例代码的 YAML 文件:

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: event-delivery
      namespace: default
    spec:
      template:
        spec:
          containers:
            - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
              env:
                - name: RESPONSE
                  value: "Hello Serverless!"
  2. 导航到包含 YAML 文件的目录,并通过应用 YAML 文件来部署应用程序:

    $ oc apply -f <filename>

创建服务并部署应用程序后,Knative 会为应用程序的这个版本创建一个不可变的修订版本。Knative 还将执行网络操作,为您的应用程序创建路由、入口、服务和负载平衡器,并将根据流量(包括不活跃 pod)自动扩展或缩减 pod。

7.5. 验证无服务器应用程序的部署

要验证您的无服务器应用程序是否已成功部署,您必须获取 Knative 创建的应用程序的 URL,然后向该 URL 发送请求并检查其输出。

注意

OpenShift Serverless 支持 HTTP 和 HTTPS URL,但 oc get ksvc 的输出始终会使用 http:// 格式显示 URL。

流程

  1. 查找应用程序 URL:

    $ oc get ksvc <service_name>

    输出示例

    NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
    event-delivery   http://event-delivery-default.example.com   event-delivery-4wsd2   event-delivery-4wsd2   True

  2. 向集群发出请求并观察其输出。

    HTTP 请求示例

    $ curl http://event-delivery-default.example.com

    HTTPS 请求示例

    $ curl https://event-delivery-default.example.com

    输出示例

    Hello Serverless!

  3. 可选。如果您在证书链中收到与自签名证书相关的错误,可以在 curl 命令中添加 --insecure 标志来忽略以下错误:

    $ curl https://event-delivery-default.example.com --insecure

    输出示例

    Hello Serverless!

    重要

    在生产部署中不能使用自签名证书。这个方法仅用于测试目的。

  4. 可选。如果 OpenShift Container Platform 集群配置有证书颁发机构 (CA) 签名但尚未为您的系统配置全局证书,您可以使用 curl 命令指定此证书。证书的路径可使用 --cacert 标志传递给 curl 命令:

    $ curl https://event-delivery-default.example.com --cacert <file>

    输出示例

    Hello Serverless!

7.6. 使用 HTTP2 和 gRPC 与无服务器应用程序交互

OpenShift Serverless 只支持不安全或边缘终端路由。

不安全或边缘终端路由不支持 OpenShift Container Platform 中的 HTTP2。这些路由也不支持 gRPC,因为 gRPC 由 HTTP2 传输。

如果您在应用程序中使用这些协议,则必须使用入口(ingress)网关直接调用应用程序。要做到这一点,您必须找到 ingress 网关的公共地址以及应用程序的特定主机。

流程

  1. 找到应用程序主机。请参阅验证无服务器应用程序部署中的相关内容。
  2. 查找 ingress 网关的公共地址:

    $ oc -n knative-serving-ingress get svc kourier
    NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                             PORT(S)                                                                                                                                      AGE
    kourier   LoadBalancer   172.30.51.103   a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com   80:31380/TCP,443:31390/TCP   67m

    公共地址位于 EXTERNAL-IP 字段,在本例中是 a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com

  3. 手动在 HTTP 请求的主机标头中设置应用程序的主机,但将请求定向到 ingress 网关的公共地址。

    $ curl -H "Host: hello-default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com

    输出示例

    Hello Serverless!

    您还可以通过将授权设置为应用程序的主机来发出 gRPC 请求,同时将请求直接定向到 ingress 网关:

    grpc.Dial(
        "a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com:80",
        grpc.WithAuthority("hello-default.example.com:80"),
        grpc.WithInsecure(),
    )
    注意

    如上例所示,请确保将对应的端口(默认为 80)附加到两个主机中。

第 8 章 OpenShift Serverless 中的高可用性

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

OpenShift Serverless 中的 HA 可通过领导选举机制获得,该机制会在安装 Knative Serving control plane 后默认启用。

在使用领导选举 HA 模式时,控制器实例在需要前应该已在集群内调度并运行。这些控制器实例争用共享资源,即领导选举锁定。在任意给定时间可以访问领导选举机制锁定资源的控制器实例被称为领导(leader)。

8.1. 在 OpenShift Serverless 中配置高可用性副本

在默认情况下, OpenShift Serverless 的 autoscaler-hpacontrolleractivatorkourier-controlkourier-gateway 组件都会启用高可用性(HA)功能。这些组件默认配置有两个副本。

您可以通过更改 KnativeServing 自定义资源定义中的 KnativeServing.spec.highAvailability 的配置来改变为每个控制器创建的副本数。

先决条件

  • 一个具有集群管理员权限的 OpenShift Container Platform 账户。
  • 安装了 OpenShift Serverless Operator 和 Knative Serving。

流程

  1. 在 OpenShift Container Platform web 控制台的 Administrator 视角中,进入 OperatorHubInstalled Operators

    Installed Operators 页
  2. 选择 knative-serving 命名空间。
  3. 点击 OpenShift Serverless Operator 的 Provided APIs 列表中的 Knative Serving 来进入 Knative Serving 选项卡。

    Knative Serving 标签页
  4. knative-serving,然后使用 knative-serving 页面中的 YAML 选项卡。

    Knative Serving YAML
  5. 编辑自定义资源定义 YAML:

    YAML 示例

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      high-availability:
        replicas: 3

    重要

    不要修改 config 字段中包含的任何 YAML。此字段中的一些配置值被 OpenShift Serverless Operator 注入,修改后,您的部署将不被支持。

    • 默认的 replicas 值为 2
    • 将该值改为 1 禁用 HA,或根据需要增加副本数。示例配置为所有 HA 控制器指定副本数 3

第 9 章 使用 Jaeger 追踪请求

和 OpenShift Serverless 一起使用 Jaeger,您可以在 OpenShift Container Platform 上为无服务器应用程序启用 分布式追踪

分布式追踪记录了一个请求在组成一个应用程序的多个微服务间的路径。

它被用来将不同工作单元的信息串联在一起,理解分布式事务中整个事件链。工作单元可能会在不同进程或主机中执行。

开发人员可以使用分布式追踪,在大型架构中视觉化调用流。这对理解序列化、平行和延迟来源非常有用。

如需有关 Jaeger 的更多信息,请参阅 Jaeger 架构安装 Jaeger

9.1. 配置 Jaeger 用于 OpenShift Serverless

先决条件

要配置 Jaeger 以用于 OpenShift Serverless,您需要:

  • OpenShift Container Platform 集群的集群管理员权限。
  • OpenShift Serverless Operator 和 Knative Serving 的当前安装。
  • Jaeger Operator 的当前安装。

流程

  1. 创建并应用包含以下 YAML 示例的 Jaeger 自定义资源 YAML 文件:

    apiVersion: jaegertracing.io/v1
    kind: Jaeger
    metadata:
      name: jaeger
      namespace: default
  2. 通过编辑 KnativeServing 资源并添加用于追踪的 YAML 配置来启用 Knative Serving 的追踪。

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      config:
        tracing:
          sample-rate: "0.1" 1
          backend: zipkin 2
          zipkin-endpoint: http://jaeger-collector.default.svc.cluster.local:9411/api/v2/spans 3
          debug: "false" 4
    1
    sample-rate 定义抽样概率。sample-rate: "0.1" 表示在 10 个 trace 中有 1 个被抽样。
    2
    后端 必须设为 zipkin
    3
    zipkin-endpoint 必须指向您的 jaeger-collector 服务端点。要获取此端点,请替换应用 Jaeger 自定义资源的命名空间。
    4
    调试(debugging)应设为 false。通过设置 debug: "true" 启用调试模式,可绕过抽样将所有 span 发送到服务器。

验证

访问 Jaeger web 控制台查看追踪数据。您可以使用 jaeger 路由来访问 Jaeger web 控制台。

  1. 输入以下命令来获取 jaeger 路由的主机名:

    $ oc get route jaeger
    NAME     HOST/PORT                         PATH   SERVICES       PORT    TERMINATION   WILDCARD
    jaeger   jaeger-default.apps.example.com          jaeger-query   <all>   reencrypt     None
  2. 在浏览器中使用端点地址来查看控制台。

第 10 章 Knative Serving

10.1. 配置 Knative Serving 自动扩展

OpenShift Serverless 提供 Pod 自动扩展的功能,包括将不活跃 pod 扩展为零。要针对 Knative Serving 启用自动扩展,您必须在修订模板中配置并发和扩展范围。

注意

修订模板中设置的任何限值或目标均是针对应用程序的单个实例测得。例如:将 target 注解设置为 50 将对扩展应用程序的自动扩展器进行配置,使每个修订每次将可处理 50 个请求。

10.1.1. 使用 Knative kn CLI 自动扩展工作流

您可以使用 kn 编辑集群的自动扩展功能,以便在不直接编辑 YAML 文件的情况下修改 Knative 服务。

您可以使用 kn service createkn service update 命令附带适当的标记,如下所述,以配置自动扩展行为。

标记描述

--concurrency-limit int

设定单个修订要处理的并发请求的硬性限制。

--concurrency-target int

根据传入请求的并发数量,提供何时扩展修订的建议。默认为 --concurrency-limit

--max-scale int

修订版本的最大数量。

--min-scale int

最小修订版本数。

10.1.2. 为 Knative Serving 自动扩展配置并发请求

您可以通过在修订模板中添加 target 注解或 containerConcurrency 字段来指定修订容器或应用程序的每个实例应当处理的并发请求数。

使用目标注解的修订模板 YAML 示例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: myapp
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: 50
    spec:
      containers:
      - image: myimage

使用 containerConcurrency 注解的修订模板 YAML 示例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: myapp
spec:
  template:
    metadata:
      annotations:
    spec:
      containerConcurrency: 100
      containers:
      - image: myimage

targetcontainerConcurrency 添加值将以并发请求的 target 数为目标,但对请求的 containerConcurrency 数施加一个硬性限制。

例如,如果将 target 值设定为 50,将 containerConcurrency 值设定为 100,则目标请求数将为 50,硬性限制数为 100。

如果 containerConcurrency 值小于 target 值,则 target 值将会降级,因为不需要将目标设定为超过实际处理量的请求数。

注意

只有在明确需要限制给定时间到达应用程序的请求数时才应使用 containerConcurrency。只有在应用程序需要强制限制并发时才建议使用 containerConcurrency

10.1.2.1. 使用目标注解配置并发请求

并发请求数的默认目标值为 100,但您可通过在修订模板中添加或修改 autoscaling.knative.dev/target 注解值来覆盖该值。

下面是如何在修订模板中使用该注解将目标设置为 50 的示例。

autoscaling.knative.dev/target: 50

10.1.2.2. 使用 containerConcurrency 字段配置并发请求

containerConcurrency 字段可对处理的并发请求数设置硬性限制。

containerConcurrency: 0 | 1 | 2-N
0
并发请求数不限。
1
保证修订容器的给定实例一次只处理一个请求。
2 或以上
将并发请求数限制为该值。
注意

如果无 target 注解,则自动扩展会被配置为 target 值与 containerConcurrency 值相等。

10.1.3. 配置扩展范围 Knative Serving 自动扩展

minScalemaxScale 注解可用于配置可服务于应用程序的最小和最大 pod 数。这些注解可用于防止冷启动或辅助控制计算成本。

minScale
如果未设置 minScale 注解,pod 会缩减至 0(如果对 ConfigMap 启用缩减至 0 失败,则为 1)。
maxScale
如果未设置 maxScale 注解,则创建的 pod 数将无上限。

minScalemaxScale 可在修订模板中配置如下:

spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "2"
        autoscaling.knative.dev/maxScale: "10"

在修订模板中使用这些注解会将此配置传播至 PodAutoscaler 对象。

注意

这些注解适用于修订版本的整个生命周期。即使修订版本未被任何路由引用,仍将提供由 minScale 指定的最小 Pod 计数。请记住,不可路由的修订版本可能会收集到回收箱,以便 Knative 回收资源。

10.2. 使用 OpenShift Logging

10.2.1. 关于部署 OpenShift Logging

OpenShift Container Platform 集群管理员可以使用 OpenShift Container Platform Web 控制台或 CLI 部署 OpenShift Logging 来安装 Elasticsearch Operator 和 Cluster Logging Operator。安装 Operator 后,可创建 ClusterLogging 自定义资源(CR)以调度 OpenShift Logging pod 和支持 OpenShift Logging 所需的其他资源。Operator 负责部署、升级和维护 OpenShift Logging。

ClusterLogging CR 定义包括日志记录堆栈的所有组件在内的完整 OpenShift Logging 环境,以收集、存储和视觉化日志。Cluster Logging Operator 会监视 OpenShift Logging CR,并相应地调整日志记录部署。

管理员和应用程序开发人员可以查看他们具有查看访问权限的项目的日志。

10.2.2. 关于部署和配置 OpenShift Logging

OpenShift Logging 旨在与默认配置一起使用,该配置针对中小型 OpenShift Container Platform 集群进行了调优。

以下安装说明包括一个示例 ClusterLogging 自定义资源(CR),您可以用它来创建 OpenShift Logging 实例并配置 OpenShift Logging 环境。

如果要使用默认的 OpenShift Logging 安装,可以直接使用示例 CR。

如果要自定义部署,请根据需要对示例 CR 进行更改。下面介绍了在安装 OpenShift Logging 实例或安装后修改时可以进行的配置。请参阅“配置”部分来了解有关使用各个组件的更多信息,包括可以在 ClusterLogging 自定义资源之外进行的修改。

10.2.2.1. 配置和调优 OpenShift Logging

您可以通过修改 openshift-logging 项目中部署的 ClusterLogging 自定义资源来配置 OpenShift Logging 环境。

您可以在安装时或安装后修改以下任何组件:

内存和 CPU
您可以使用有效的内存和 CPU 值修改 resources 块,以此调整各个组件的 CPU 和内存限值:
spec:
  logStore:
    elasticsearch:
      resources:
        limits:
          cpu:
          memory: 16Gi
        requests:
          cpu: 500m
          memory: 16Gi
      type: "elasticsearch"
  collection:
    logs:
      fluentd:
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        type: "fluentd"
  visualization:
    kibana:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu:
          memory:
     type: kibana
  curation:
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      type: "curator"
Elasticsearch 存储
您可以使用 storageClass namesize 参数,为 Elasticsearch 集群配置持久性存储类和大小。Cluster Logging Operator 基于这些参数,为 Elasticsearch 集群中的每个数据节点创建一个持久性卷声明(PVC)。
  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "gp2"
          size: "200G"

本例中指定,集群中的每个数据节点将绑定到请求 200G 的 gp2 存储的 PVC。每个主分片将由单个副本支持。

注意

省略 storage 块会导致部署中仅包含临时存储。

  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}
Elasticsearch 复制策略

您可以通过设置策略来定义如何在集群中的数据节点之间复制 Elasticsearch 分片:

  • FullRedundancy。各个索引的分片完整复制到每个数据节点上。
  • MultipleRedundancy。各个索引的分片分布到一半数据节点上。
  • SingleRedundancy。各个分片具有单个副本。只要存在至少两个数据节点,日志就能始终可用且可恢复。
  • ZeroRedundancy。所有分片均无副本。如果节点关闭或发生故障, 则可能无法获得日志数据。
Curator 调度
cron 格式指定 Curator 的调度。
  spec:
    curation:
    type: "curator"
    resources:
    curator:
      schedule: "30 3 * * *"

10.2.2.2. 修改后的 ClusterLogging 自定义资源示例

以下是使用前面描述的选项修改的 ClusterLogging 自定义资源的示例。

修改后的 ClusterLogging 自定义资源示例

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    retentionPolicy:
      application:
        maxAge: 1d
      infra:
        maxAge: 7d
      audit:
        maxAge: 7d
    elasticsearch:
      nodeCount: 3
      resources:
        limits:
          memory: 32Gi
        requests:
          cpu: 3
          memory: 32Gi
        storage:
          storageClassName: "gp2"
          size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      replicas: 1
  curation:
    type: "curator"
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      schedule: "*/5 * * * *"
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi

10.2.3. 使用 OpenShift Logging 查找 Knative Serving 组件的日志

流程

  1. 获取 Kibana 路由:

    $ oc -n openshift-logging get route kibana
  2. 使用路由的 URL 导航到 Kibana 仪表板并登录。
  3. 检查是否将索引设置为 .all。如果索引未设置为 .all,则只会列出 OpenShift 系统日志。
  4. 使用 knative-serving 命名空间过滤日志。在搜索框中输入 kubernetes.namespace_name:knative-serving 以过滤结果。
注意

Knative Serving 默认使用结构化日志记录。您可以通过自定义 OpenShift Logging Fluentd 设置来启用这些日志的解析。这可使日志更易搜索,并且能够在日志级别进行过滤以快速识别问题。

10.2.4. 使用 OpenShift Logging 查找通过 Knative Serving 部署的服务的日志

使用 OpenShift Logging,应用程序写入控制台的日志将在 Elasticsearch 中收集。以下流程概述了如何使用 Knative Serving 将这些功能应用到所部署的应用程序中。

流程

  1. 获取 Kibana 路由:

    $ oc -n openshift-logging get route kibana
  2. 使用路由的 URL 导航到 Kibana 仪表板并登录。
  3. 检查是否将索引设置为 .all。如果索引未设置为 .all,则只会列出 OpenShift 系统日志。
  4. 使用 knative-serving 命名空间过滤日志。在搜索框中输入服务的过滤器来过滤结果。

    过滤器示例

    kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{service_name}

    除此之外还可使用 /configuration/revision 来过滤。

  5. 您可使用 kubernetes.container_name:<user-container> 来缩小搜索范围,只显示由您的应用程序生成的日志。否则,会显示来自 queue-proxy 的日志。
注意

在应用程序中使用基于 JSON 的结构化日志记录,以便在生产环境中快速过滤这些日志。

10.3. 为服务的不同修订版本映射和分割流量

每次更新服务配置时,都会为该服务创建一个新修订版本。服务路由默认将所有流量指向最新可用的修订版本。您可通过定义哪个修订版本可获得部分流量来更改此行为。

Knative 服务允许流量映射,这意味着服务的修订版本可以被映射到流量的分配部分。流量映射还提供了为特定修订版本创建唯一 URL 的选项。

10.3.1. 使用 Developer 视角在修订版本间分割流量

创建无服务器应用程序后,无服务器应用程序会显示在 Developer 视角的 Topology 视图中。应用程序修订由节点代表,无服务器资源服务由节点外的四边形代表。

代码或服务配置中的任何新更改都会触发修订版本,即特定时间点的代码快照。对于服务,您可以根据需要通过分割服务修订版本并将其路由到不同的修订版本来管理服务间的流量。

流程

要在 Topology 视图中的多个应用程序修订版本间分割流量:

  1. 点击由四边形表示的无服务器资源服务,在侧面面板中查看其概述信息。
  2. Resources 选项卡,查看服务的 RevisionsRoutes 列表。

    图 10.1. 无服务器应用程序

    odc serverless app
  3. 点侧边面板顶部的由 S 图标代表的服务,查看服务详情概述。
  4. YAML 选项卡,在 YAML 编辑器中修改服务配置,然后点 Save。例如,将 timeoutseconds 从 300 改为 301。这个配置更改会触发新修订版本。在 Topology 视图中会显示最新的修订,服务 Resources 选项卡现在会显示两个修订版本。
  5. Resources 选项卡中,点 Set Traffic distribution 按钮查看流量分布对话框:

    1. Splits 字段中为两个修订版本添加流量百分比。
    2. 添加标签以便为这两个修订版本创建自定义 URL。
    3. Save 查看两个节点,分别代表 Topology 视图中的两个修订版本。

      图 10.2. 无服务器应用程序修订

      odc 无服务器修订

10.3.2. 使用 kn进行流量映射和分割

KN 提供命令帮助您控制流量映射以及如何在修订版本间分割流量。

您可以使用带有 --traffic 标志的 kn service update 命令来更新流量。这个标志使用以下语法:

--traffic RevisionName=Percent

其中 * --traffic 标志需要用等号 (=) 分隔的两个值。* RevisionName 字符串表示修订版本的名称。* Percent 整数表示分配给修订版本的流量部分。

重要

--traffic 标志可以在一个命令中多次指定,且仅在所有标志中的 Percent 值总和达到 100 时才有效。

流程

  • 更新要路由到修订版本的流量百分比:

    $ kn service update --traffic <@revision_name>=<percent_integer>
    注意

    您可以将标识符 @latest 用于修订名称,以引用服务的最新的可用修订版本。每个命令中只能使用这个标识符,并附带 --traffic 标志。

10.3.2.1. 分配标签修订

服务流量块中的标签会创建自定义 URL,指向引用的修订版本。用户可为服务的可用修订版本定义唯一标签,该标签通过使用 http(s)://TAG-SERVICE.DOMAIN 格式创建自定义 URL。

给定标签对于该服务的流量块来说必须是唯一的。kn 作为 kn service update 命令的一部分,支持为服务修订版本分配和取消分配自定义标签。

注意

如果您为特定修订版本分配了标签,用户便可通过 --traffic 标志中作为 --traffic Tag=Percent 的标签来引用修订版本。

流程

  • 使用以下命令:

    $ kn service update svc --tag @latest=candidate --tag svc-vwxyz=current
注意

--tag RevisionName=Tag 使用以下语法:

  • --tag 标志需要两个以 = 分隔的值。
  • RevisionName 字符串表示 Revision 的名称。
  • Tag 字符串表示要为此修订版本提供的自定义标签。
  • 将标识符 @latest 用于 RevisionName,以表示服务的最新的可用修订版本。此标识符仅可与 --tag 标志一起使用一次。
  • 如果 service update 命令更新该服务的配置值(以及标签标志),则 @latest 引用将在应用更新后指向所创建修订版本。
  • --tag 标志可多次指定。
  • --tag 标志可为同一修订版本分配不同标签。

10.3.2.2. 取消分配标签修订版本

已分配至流量块中修订版本的标签可取消分配。取消分配标签将会移除自定义 URL。

注意

如果修订版本未标记,也没有为其分配流量,则会从流量块中完全移除该修订版本。

流程

  • 用户可以使用 kn service update 命令为修订版本取消分配标签。

    $ kn service update svc --untag candidate
注意

--untag Tag 使用以下语法:

  • --untag 标志需要一个值。
  • tag 字符串表示服务流量块中的唯一标签需要取消分配。这也会移除对应的自定义 URL。
  • --untag 标志可多次指定。

10.3.2.3. 流量标志操作优先级

所有流量相关标志均可使用单一 kn service update 命令指定。kn 定义这些标志的优先级。不考虑使用命令时指定的标志顺序。

通过 kn 评估标志时,标志的优先级如下:

  1. --untag:带有此标志的所有引用修订版本均将从流量块中移除。
  2. --tag:修订版本将按照流量块中的指定进行标记。
  3. --traffic:为引用的修订版本分配一部分流量分割。

10.3.2.4. 流量分割标志

kn 作为 kn service update 命令的一部分,支持在服务的流量块上进行流量操作。

下表显示流量分割标志、值格式和标志执行的操作汇总。Repetition 列表示在 kn service update 命令中是否允许重复标志的特定值。

标记操作重复

--traffic

RevisionName=Percent

RevisionName 提供 Percent 的流量

--traffic

Tag=Percent

为带有 Tag的修订版本提供 Percent 的流量

--traffic

@latest=Percent

为最新可用的修订版本提供 Percent 的流量

--tag

RevisionName=Tag

RevisionName 提供 Tag

--tag

@latest=Tag

为最新可用的修订版本提供 Tag

--untag

Tag

从修订中删除 Tag

第 11 章 事件工作流

11.1. 使用代理和触发器事件交付工作流

代理可与触发器结合使用,用于将事件源发送到事件接收器。

代理事件交付概述

事件源可以作为 HTTP POST 请求从事件源发送到代理。

事件进入代理后,可使用触发器根据 CloudEvent 属性 进行过滤,并作为 HTTP POST 请求发送到事件 sink。

11.1.1. 创建代理

OpenShift Serverless 提供了一个 default Knative 代理,它可以通过 Knative CLI 创建。您还可以通过将 eventing.knative.dev/injection: enabled 注解添加到触发器来创建 default 代理。

重要

虽然开发人员和集群管理员都可以通过注入添加代理,但只有集群管理员可以永久删除使用此方法创建的代理。

11.1.1.1. 使用 Knative CLI 创建代理

先决条件

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
  • 已安装 kn CLI。

流程

  • 创建 default 代理:

    $ kn broker create default

验证

  1. 使用 kn 命令列出所有现有代理:

    $ kn broker list

    输出示例

    NAME      URL                                                                     AGE   CONDITIONS   READY   REASON
    default   http://broker-ingress.knative-eventing.svc.cluster.local/test/default   45s   5 OK / 5     True

  2. 可选:如果使用 OpenShift Container Platform Web 控制台,在 Developer 视角中进入 Topology 视图来查看存在的代理:

    在 web 控制台 Topology 视图中查看代理

11.1.1.2. 通过注解触发器来创建代理

您可以通过将 eventing.knative.dev/injection: enabled 注解添加到 Trigger 对象来创建代理。

重要

如果您使用 eventing.knative.dev/injection: enabled 注解创建代理,则在没有集群管理员权限的情况下无法删除该代理。如果您在集群管理员还没有删除此注解前删除了代理,则代理会在删除后再次被创建。

先决条件

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。

流程

  1. 创建一个 Trigger 对象作为 .yaml 文件,该文件带有 eventing.knative.dev/injection: enabled 注解:

    apiVersion: eventing.knative.dev/v1
    kind: Trigger
    metadata:
      annotations:
        eventing.knative.dev/injection: enabled
      name: <trigger-name>
    spec:
      broker: default
      subscriber: 1
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: <service-name>
    1
    指定触发器将事件发送到的事件 sink 或 subscriber
  2. 应用 .yaml 文件:

    $ oc apply -f <filename>

验证

您可以使用 oc CLI,或使用 web 控制台中的 Topology 视图来验证代理是否已成功创建。

  1. 使用 oc 命令获取代理:

    $ oc -n <namespace> get broker default

    输出示例

    NAME      READY     REASON    URL                                                                     AGE
    default   True                http://broker-ingress.knative-eventing.svc.cluster.local/test/default   3m56s

  2. 进入 web 控制台中的 Topology 视图以查看存在的代理:

    在 web 控制台 Topology 视图中查看代理

11.1.2. 管理代理

kn CLI 提供了用于列出、描述、更新和删除代理的命令。

11.1.2.1. 使用 Knative CLI 列出现有代理

先决条件

  • OpenShift Serverless Operator、Knative Serving 和 Knative Eventing 已在 OpenShift Container Platform 集群中安装。
  • 已安装 kn CLI。

流程

  • 列出所有存在的代理:

    $ kn broker list

    输出示例

    NAME      URL                                                                     AGE   CONDITIONS   READY   REASON
    default   http://broker-ingress.knative-eventing.svc.cluster.local/test/default   45s   5 OK / 5     True

11.1.2.2. 使用 Knative CLI 描述现有代理

先决条件

  • OpenShift Serverless Operator、Knative Serving 和 Knative Eventing 已在 OpenShift Container Platform 集群中安装。
  • 已安装 kn CLI。

流程

  • 描述现有代理:

    $ kn broker describe <broker_name>

    使用 default broker 的命令示例

    $ kn broker describe default

    输出示例

    Name:         default
    Namespace:    default
    Annotations:  eventing.knative.dev/broker.class=MTChannelBasedBroker, eventing.knative.dev/creato ...
    Age:          22s
    
    Address:
      URL:    http://broker-ingress.knative-eventing.svc.cluster.local/default/default
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                  22s
      ++ Addressable            22s
      ++ FilterReady            22s
      ++ IngressReady           22s
      ++ TriggerChannelReady    22s

11.1.3. 使用触发器过滤事件

使用触发器可让您过滤代理的事件发送到事件 sink。

先决条件

在使用触发器前,您需要:

  • 安装了 Knative Eventing 和 kn
  • 有可用的代理,可以是 default 代理,也可以是您创建的代理。

    您可以按照 在 Knative Eventing 中使用代理中的内容,或在创建触发器时使用 --inject-broker 标志来创建 default 代理。本节将描述这个标志的使用。

  • 一个可用的事件消费者,如 Knative 服务。

11.1.3.1. 使用 Developer 视角创建触发器

创建代理后,可以在 web 控制台的 Developer 视角中创建触发器。

先决条件

  • OpenShift Serverless Operator、Knative Serving 和 Knative Eventing 已在 OpenShift Container Platform 集群中安装。
  • 已登陆到 web 控制台。
  • 处于 Developer 视角。
  • 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
  • 您已创建了代理和 Knative 服务或其他事件 sink 以连接触发器。

流程

  1. Developer 视角中,进入 Topology 页。
  2. 将鼠标悬停在您要创建触发器的代理上,并拖动箭头。此时会显示 Add Trigger 选项。

    为代理创建触发器
  3. Add Trigger
  4. 从下拉列表中选择您的 sink 作为 Subscriber
  5. Add

验证

  • 在订阅被创建后,它会在 Topology 视图中以一行表示,该行将代理连接到服务:

    Topology 视图中的触发器

11.1.3.2. 使用 Developer 视角删除触发器

您可以通过 web 控制台中的 Developer 视角删除触发器。

先决条件

  • 要使用 Developer 视角删除触发器,请确保已登录到 web 控制台。

流程

  1. Developer 视角中,进入 Topology 页。
  2. 点您要删除的触发器。
  3. Actions 上下文菜单中,选择 Delete Trigger

    删除触发器

11.1.3.3. 使用 kn创建触发器

您可以使用 kn trigger create 命令创建触发器。

流程

  • 创建触发器:

    $ kn trigger create <trigger_name> --broker <broker_name> --filter <key=value> --sink <sink_name>

    或者,您可以创建触发器并使用代理注入同时创建 default 代理:

    $ kn trigger create <trigger_name> --inject-broker --filter <key=value> --sink <sink_name>

    默认情况下,触发器会将发送到代理的所有事件转发到订阅到该代理的 sink。通过对触发器使用 --filter 属性,您可以从代理过滤事件,这样订阅者才会根据您定义的标准接收一小部分事件。

11.1.3.4. 使用 kn列出触发器

Kn trigger list 命令输出可用触发器列表。

流程

  1. 显示可用触发器列表:

    $ kn trigger list

    输出示例

    NAME    BROKER    SINK           AGE   CONDITIONS   READY   REASON
    email   default   ksvc:edisplay   4s    5 OK / 5     True
    ping    default   ksvc:edisplay   32s   5 OK / 5     True

  2. 可选:以 JSON 格式输出触发器列表:

    $ kn trigger list -o json

11.1.3.5. 使用 kn 输出触发器信息

您可以使用 kn trigger describe 命令输出有关触发器的信息。

流程

  • 输入命令:

    $ kn trigger describe <trigger_name>

    输出示例

    Name:         ping
    Namespace:    default
    Labels:       eventing.knative.dev/broker=default
    Annotations:  eventing.knative.dev/creator=kube:admin, eventing.knative.dev/lastModifier=kube:admin
    Age:          2m
    Broker:       default
    Filter:
      type:       dev.knative.event
    
    Sink:
      Name:       edisplay
      Namespace:  default
      Resource:   Service (serving.knative.dev/v1)
    
    Conditions:
      OK TYPE                  AGE REASON
      ++ Ready                  2m
      ++ BrokerReady            2m
      ++ DependencyReady        2m
      ++ Subscribed             2m
      ++ SubscriberResolved     2m

11.1.3.6. 使用触发器过滤事件

在以下触发器示例中,只有具有属性 type: dev.knative.samples.helloworld 的事件才会到达事件 sink。

$ kn trigger create <trigger_name> --broker <broker_name> --filter type=dev.knative.samples.helloworld --sink ksvc:<service_name>

您还可以使用多个属性过滤事件。以下示例演示了如何使用类型、源和扩展属性过滤事件。

$ kn trigger create <trigger_name> --broker <broker_name> --sink ksvc:<service_name> \
--filter type=dev.knative.samples.helloworld \
--filter source=dev.knative.samples/helloworldsource \
--filter myextension=my-extension-value

11.1.3.7. 使用 kn更新触发器

您可以使用带有特定标志的 kn trigger update 命令来更新触发器的属性。

流程

  • 更新触发器:

    $ kn trigger update <trigger_name> --filter <key=value> --sink <sink_name> [flags]
    • 您可以更新触发器来过滤与传入事件匹配的事件属性。例如,使用 type 属性:

      $ kn trigger update <trigger_name> --filter type=knative.dev.event
    • 您可以从触发器中删除过滤器属性。例如,您可以使用键 type 来删除过滤器属性:

      $ kn trigger update <trigger_name> --filter type-
    • 您可以使用 --sink 参数来更改触发器的事件 sink:

      $ kn trigger update <trigger_name> --sink ksvc:my-event-sink

11.1.3.8. 使用 kn删除触发器

流程

  • 删除触发器:

    $ kn trigger delete <trigger_name>

验证

  1. 列出现有触发器:

    $ kn trigger list
  2. 验证触发器不再存在:

    输出示例

    No triggers found.

11.2. 使用频道的事件交付工作流

频道是定义单一事件转发和持久层的自定义资源。

频道工作流概述

事件源或生成程序将事件发送到频道后,可使用订阅将这些事件发送到多个 Knative 服务或其他 sink。

InMemoryChannelKafkaChannel 频道实现可用于 OpenShift Serverless 进行开发。

以下是 InMemoryChannel 类型频道的限制:

  • 没有可用的事件持久性。如果 Pod 停机,则 Pod 上的事件将会丢失。
  • InMemoryChannel 频道没有实现事件排序,因此同时接收到的两个事件可能会以任何顺序传送给订阅者。
  • 如果订阅者拒绝某个事件,则不会默认重新发送尝试。您可以通过修改 Subscription 对象中的 delivery 规格来配置重新发送尝试。
重要

OpenShift Serverless 上的 Apache Kafka 只是一个技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持,且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的详情,请参阅 https://access.redhat.com/support/offerings/techpreview/

11.2.1. 配置默认频道实施

default-ch-webhook 配置映射可以用来指定集群的默认频道实施,也可以用于一个或多个命名空间。

您可以使用 OpenShift Serverless Operator 传播更改,以更改 knative-eventing 命名空间配置映射,包括 default-ch-webhook 配置映射。要做到这一点,您必须修改 KnativeEventing 自定义资源。

先决条件

  • 在 OpenShift Container Platform 上具有集群管理员权限。
  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Eventing。

流程

  • 修改 KnativeEventing 自定义资源,以添加 default-ch-webhook 配置映射的配置详情:

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      config: 1
        default-ch-webhook: 2
          default-ch-config: |
            clusterDefault: 3
              apiVersion: messaging.knative.dev/v1
              kind: InMemoryChannel
              spec:
                delivery:
                  backoffDelay: PT0.5S
                  backoffPolicy: exponential
                  retry: 5
            namespaceDefaults: 4
              my-namespace:
                apiVersion: messaging.knative.dev/v1beta1
                kind: KafkaChannel
                spec:
                  numPartitions: 1
                  replicationFactor: 1
    1
    spec.config 中,您可以指定您要为修改的配置添加的配置映射。
    2
    default-ch-webhook 配置映射可以用来指定集群的默认频道实施,也可以用于一个或多个命名空间。
    3
    集群范围的默认频道类型配置。在本例中,集群的默认频道实现是 InMemoryChannel
    4
    命名空间范围的默认频道类型配置。在本例中, my-namespace 命名空间的默认频道实现是 KafkaChannel
    重要

    配置特定于命名空间的默认设置会覆盖任何集群范围的设置。

11.2.2. 创建频道

开发人员可以通过对受支持的 Channel 对象进行实例化来创建频道。

创建 Channel 对象后,,根据默认频道实现,一个经过更改的准入 Webhook 会为 Channel 对象添加一组 spec.channelTemplate 属性。例如,对于 InMemoryChannel 默认实现,Channel 对象如下所示:

apiVersion: messaging.knative.dev/v1
kind: Channel
metadata:
  name: example-channel
  namespace: default
spec:
  channelTemplate:
    apiVersion: messaging.knative.dev/v1
    kind: InMemoryChannel
注意

创建后,spec.channelTemplate 属性将无法更改,因为它们由默认频道机制设置,而不是由用户设置。

然后,频道控制器将根据这个 spec.channelTemplate 配置创建后备频道实例。

当此机制与上例搭配使用时,会创建两个对象:一个通用的后备频道和一个 InMemoryChannel 频道。如果您使用不同的默认频道实现,例如:Apache Kafka,会生成一个通用后备频道和 KafkaChannel 频道。

后备频道充当将订阅复制到用户创建的频道对象的代理,并设置用户创建的频道对象状态来反映后备频道的状态。

11.2.2.1. 使用 Developer 视角创建频道

您可以使用 OpenShift Container Platform Web 控制台使用集群默认配置创建频道。

先决条件

要使用 Developer 视角创建频道,请确定:

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
  • 已登陆到 web 控制台。
  • 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。

流程

  1. Developer 视角中,导航到 +AddChannel
  2. Type 下拉菜单中选择您要创建的 Channel 对象类型。

    注意

    目前只支持 InMemoryChannel 类型的 Channel 对象。

  3. 点击 Create

验证

  • 通过导航到 Topology 页面确认频道现在存在。

    在 Topology 视图中查看频道

11.2.2.2. 使用 Knative CLI 创建频道

您可以使用 kn CLI 使用集群默认配置创建频道。

先决条件

要使用 kn CLI 创建频道,请确保:

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
  • 已安装 kn CLI。
  • 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。

流程

  • 创建频道:

    $ kn channel create <channel_name> --type <channel_type>

    频道类型是可选的,但如果指定,则必须使用 Group:Version:Kind 格式。例如,您可以创建一个 InMemoryChannel 对象:

    $ kn channel create mychannel --type messaging.knative.dev:v1:InMemoryChannel

    输出示例

    Channel 'mychannel' created in namespace 'default'.

验证

  • 要确认该频道现在存在,请列出现有频道并检查输出:

    $ kn channel list

    输出示例

    kn channel list
    NAME        TYPE              URL                                                     AGE   READY   REASON
    mychannel   InMemoryChannel   http://mychannel-kn-channel.default.svc.cluster.local   93s   True

11.2.2.3. 使用 YAML 创建默认实现频道

您可以使用集群默认配置的 YAML 创建频道。

先决条件

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
  • 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。

流程

创建 Channel 对象:

  1. 创建 YAML 文件并将以下示例代码复制到其中:

    apiVersion: messaging.knative.dev/v1
    kind: Channel
    metadata:
      name: example-channel
      namespace: default
  2. 应用 YAML 文件:

    $ oc apply -f <filename>

11.2.2.4. 使用 YAML 创建 Kafka 频道

您可以使用 YAML 创建 KafkaChannel 对象来创建 Kafka 频道。

先决条件

  • OpenShift Serverless Operator、Knative Eventing 和 KnativeKafka 自定义资源已安装在 OpenShift Container Platform 集群中。
  • 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。

流程

  1. 创建 YAML 文件并将以下示例代码复制到其中:

    apiVersion: messaging.knative.dev/v1beta1
    kind: KafkaChannel
    metadata:
      name: example-channel
      namespace: default
    spec:
      numPartitions: 3
      replicationFactor: 1
  2. 应用 YAML 文件:

    $ oc apply -f <filename>

11.2.3. 将频道连接到事件源

将频道连接到事件源允许频道从该源接收事件。这些事件然后可使用订阅转发到事件 sink。

11.2.3.1. 使用 Developer 视角将事件源连接到频道

您可以在 OpenShift Container Platform 中创建多个可以连接到频道的事件源类型。

先决条件

要使用 Developer 视角将事件源连接到频道,请确保:

  • OpenShift Serverless Operator、Knative Serving 和 Knative Eventing 已在 OpenShift Container Platform 集群中安装。
  • 已登陆到 web 控制台。
  • 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
  • 您已根据使用 OpenShift Container Platform Web 控制台创建频道的文档创建了频道。

流程

  1. 根据 Getting started with event source 的文档创建任何类型的事件源。
  2. Developer 视角中,进入 Event Sources
  3. Event Sources 表单视图的 Sink 部分,选择 Resource。然后使用下拉菜单选择您的频道。

    使用您的频道作为资源
  4. 点击 Create

验证

您可以通过查看 Topology 页面来验证事件源是否已创建并连接到 sink。

  1. Developer 视角中,导航到 Topology
  2. 查看事件源并点击连接的频道来查看侧面面板中的频道详情。

    查看源和连接的频道

11.2.4. 创建订阅

开发人员可以创建订阅来允许事件 sink 订阅频道并直接接收事件。

11.2.4.1. 从 Developer 视角创建订阅

先决条件

要使用 Developer 视角 创建订阅,请确保:

  • OpenShift Serverless Operator、Knative Serving 和 Knative Eventing 已在 OpenShift Container Platform 集群中安装。
  • 已登陆到 web 控制台。
  • 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。
  • 您已创建了事件 sink,如 Knative 服务以及频道。

流程

  1. Developer 视角中,进入 Topology 页。
  2. 使用以下方法之一创建订阅:

    1. 将鼠标悬停在您要为其创建订阅的频道上,并拖动箭头。此时会显示 Add Subscription 选项。

      为频道创建订阅
      1. 从下拉列表中选择您的 sink 作为订阅者。
      2. Add
    2. 如果服务在与频道相同的命名空间或项目下的 Topology 视图中可用,点击您要为该频道创建订阅的频道,并将箭头直接拖到服务以立即从频道创建订阅到该服务。

验证

  • 创建订阅后,您可以在 Topology 视图中将频道连接到该服务的行显示为:

    Topology 视图中的订阅

    您可以通过点击该服务来查看 sink 的事件源、频道和订阅。

11.2.4.2. 使用 Knative CLI 创建订阅

您可以使用 kn CLI 创建订阅以将频道连接到接收器(sink)。

先决条件

要使用 kn CLI 创建订阅,请确保:

  • OpenShift Serverless Operator 和 Knative Eventing 已安装在 OpenShift Container Platform 集群中。
  • 已安装 kn CLI。
  • 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。

流程

  • 创建订阅以将接收器(sink)连接到频道。

    $ kn subscription create <subscription_name> \
      --channel <Group:Version:Kind>:<channel_name> \
      --sink <sink_prefix>:<sink_name> \
      --sink-reply <sink_prefix>:<sink_name> \
      --sink-dead-letter <sink_prefix>:<sink_name>

    示例命令

    $ kn subscription create mysubscription --channel mychannel --sink ksvc:event-display

    输出示例

    Subscription 'mysubscription' created in namespace 'default'.

验证

  • 要确认频道已连接到事件接收器或 subscriber,使用一个订阅列出现有订阅并检查输出:

    $ kn subscription list

    输出示例

    NAME            CHANNEL             SUBSCRIBER           REPLY   DEAD LETTER SINK   READY   REASON
    mysubscription   Channel:mychannel   ksvc:event-display                              True

11.2.4.3. 使用 YAML 创建订阅

您可以使用 YAML 创建订阅以将频道连接到 sink。

流程

  • 创建 Subscription 对象。

    • 创建 YAML 文件并将以下示例代码复制到其中:

      apiVersion: messaging.knative.dev/v1beta1
      kind: Subscription
      metadata:
        name: my-subscription 1
        namespace: default
      spec:
        channel: 2
          apiVersion: messaging.knative.dev/v1beta1
          kind: Channel
          name: example-channel
        delivery: 3
          deadLetterSink:
            ref:
              apiVersion: serving.knative.dev/v1
              kind: Service
              name: error-handler
        subscriber: 4
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display
      1
      订阅的名称。
      2
      订阅连接的频道的配置设置。
      3
      事件交付的配置设置。这会告诉订阅无法发送给订阅者的事件。配置后,消耗的事件会发送到 deadLetterSink。事件将被丢弃,不会尝试重新发送该事件,并在系统中记录错误。deadLetterSink 的值需要是一个 Destination
      4
      订阅用户的配置设置。这是事件从频道发送的事件 sink。
    • 应用 YAML 文件:

      $ oc apply -f <filename>

11.2.5. 使用 Knative CLI 删除频道

您可以使用 kn CLI 删除使用集群默认配置的频道。

流程

  • 删除频道:

    $ kn channel delete <channel_name>

第 12 章 事件源

12.1. 事件源入门

event source 是指将事件的创作者与事件 sink 或消费者链接到一起的对象。sink 是可以从事件源接收事件的 Knative Service、Channel 或 Broker。

目前,OpenShift Serverless 支持以下事件源类型:

API 服务器源
把一个 sink 连接到 Kubernetes API 服务器。
Ping 源
定期使用带有恒定有效负载的 ping 事件。它可以作为一个计时器使用。
接收器(sink)绑定
允许您将核心 Kubernetes 资源对象(如 DeploymentJobStatefulSet 对象)与一个接收器连接。
Apache Kafka 源
将 Kafka 集群连接到接收器作为事件源。
重要

OpenShift Serverless 上的 Apache Kafka 只是一个技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持,且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的详情,请参阅 https://access.redhat.com/support/offerings/techpreview/

您可以使用 OpenShift Container Platform Web 控制台、kn CLI 或应用 YAML 文件的 Developer 视角 创建和管理 Knative 事件源。

12.1.1. 其他资源

12.2. 列出事件源和事件源类型

您可以使用 OpenShift Container Platform Web 控制台中的 kn CLI 或 Developer 视角来列出和管理可用事件源或事件源类型。

目前,OpenShift Serverless 支持以下事件源类型:

API 服务器源
把一个 sink 连接到 Kubernetes API 服务器。
Ping 源
定期使用带有恒定有效负载的 ping 事件。它可以作为一个计时器使用。
接收器(sink)绑定
允许您将核心 Kubernetes 资源对象(如 DeploymentJobStatefulSet 对象)与一个接收器连接。
Apache Kafka 源
将 Kafka 集群连接到接收器作为事件源。
重要

OpenShift Serverless 上的 Apache Kafka 只是一个技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持,且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的详情,请参阅 https://access.redhat.com/support/offerings/techpreview/

12.2.1. 使用 Knative CLI 列出可用事件源类型

流程

  1. 列出终端中的可用事件源类型:

    $ kn source list-types

    输出示例

    TYPE              NAME                                            DESCRIPTION
    ApiServerSource   apiserversources.sources.knative.dev            Watch and send Kubernetes API events to a sink
    PingSource        pingsources.sources.knative.dev                 Periodically send ping events to a sink
    SinkBinding       sinkbindings.sources.knative.dev                Binding for connecting a PodSpecable to a sink

  2. 可选:您也可以以 YAML 格式列出可用事件源类型:

    $ kn source list-types -o yaml

12.2.2. 在 Developer 视角中查看可用事件源类型

您可以使用 Web 控制台查看可用事件源类型。

注意

集群管理员可以通过在 OpenShift Container Platform 上安装 Operator 来添加额外的事件源类型。

流程

  1. 访问 Developer 视角。
  2. +Add
  3. Event source

12.2.3. 使用 Knative CLI 列出可用事件源

  • 列出可用事件源:

    $ kn source list

    输出示例

    NAME   TYPE              RESOURCE                               SINK         READY
    a1     ApiServerSource   apiserversources.sources.knative.dev   ksvc:eshow2   True
    b1     SinkBinding       sinkbindings.sources.knative.dev       ksvc:eshow3   False
    p1     PingSource        pingsources.sources.knative.dev        ksvc:eshow1   True

12.2.3.1. 仅列出特定类型的事件源

您可以使用 --type 标志来只列出特定类型的事件源。

  • 列出可用的 ping 源:

    $ kn source list --type PingSource

    输出示例

    NAME   TYPE              RESOURCE                               SINK         READY
    p1     PingSource        pingsources.sources.knative.dev        ksvc:eshow1   True

12.3. 使用 API 服务器源

API 服务器源是一个事件源,可用于将事件接收器(sink),如 Knative 服务,连接到 Kubernetes API 服务器。API 服务器源监视 Kubernetes 事件并将其转发到 Knative Eventing 代理。

12.3.1. 先决条件

  • 您必须在 OpenShift Container Platform 集群中安装 OpenShift Serverless,包括 Knative Serving 和 Eventing。这可由集群管理员安装。
  • 事件源需要服务作为事件 sink。sink 是事件源发送到的服务或应用程序。
  • 您必须为事件源创建或更新服务帐户、角色和角色绑定。
注意

以下一些流程要求您创建 YAML 文件。

如果更改了示例中使用的 YAML 文件的名称,则需要更新对应的 CLI 命令。

12.3.2. 为事件源创建服务帐户、角色和绑定

流程

  1. 通过创建名为 authentication.yaml 的文件并将以下示例代码复制到其中,为事件源创建服务帐户、角色和角色绑定:

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: events-sa
      namespace: default 1
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: event-watcher
      namespace: default 2
    rules:
      - apiGroups:
          - ""
        resources:
          - events
        verbs:
          - get
          - list
          - watch
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: k8s-ra-event-watcher
      namespace: default 3
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: event-watcher
    subjects:
      - kind: ServiceAccount
        name: events-sa
        namespace: default 4
    1 2 3 4
    将这个命名空间更改为已选择安装事件源的命名空间。
    注意

    如果要重新使用具有适当权限的现有服务帐户,您必须修改该服务帐户的 authentication.yaml

  2. 运行以下命令,创建服务帐户、角色绑定和集群绑定:

    $ oc apply --filename authentication.yaml

12.3.3. 使用 Developer 视角创建 API 服务器源

流程

  1. Developer 视角中,导航到 +AddEvent Source。此时会显示 Event Sources 页面。
  2. 可选:如果您的事件源有多个供应商,请从 Providers 列表中选择所需的供应商,以过滤供应商的可用事件源。
  3. 选择 ApiServerSource,然后点 Create Event Source。此时会显示 Create Event Source 页面。
  4. 使用 Form viewYAML view 配置 ApiServerSource 设置:

    注意

    您可以在 Form viewYAML view 间进行切换。在不同视图间切换时数据会被保留。

    1. 输入 v1 作为 APIVERSIONEvent 作为 KIND
    2. 为您创建的服务帐户选择 Service Account Name
    3. 为事件源选择 SinkSink 可以是一个 资源,如频道、代理或服务,也可以是一个 URI
  5. 点击 Create

验证

  • 创建 API 服务器源后,您会在 Topology 视图中看到它连接到接收器的服务。

    ApiServerSource Topology view
注意

如果使用 URI sink,请右键点击 URI sinkEdit URI 来修改 URI。

12.3.4. 使用 Developer 视角删除 API 服务器源

流程

  1. 导航到 Topology 视图。
  2. 右键点击 API 服务器源并选择 Delete ApiServerSource

    删除 ApiServerSource

12.3.5. 通过 Knative CLI 使用 API 服务器源

本节论述了使用 kn 命令创建 API 服务器源所需的步骤。

先决条件

  • 您必须安装了 OpenShift Serverless、Knative Serving 和 Eventing 组件以及 kn CLI。

流程

  1. 创建使用代理作为事件接收器的 API 服务器源:

    $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
  2. 要检查 API 服务器源是否已正确设置,请创建一个 Knative 服务,在日志中转储传入的信息:

    $ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  3. 创建触发器将事件从 default 代理过滤到服务:

    $ kn trigger create <trigger_name> --sink ksvc:<service_name>
  4. 通过在 default 命名空间中启动 Pod 来创建事件:

    $ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  5. 通过检查以下命令生成的输出来检查是否正确映射了控制器:

    $ kn source apiserver describe <source_name>

    输出示例

    Name:                mysource
    Namespace:           default
    Annotations:         sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
    Age:                 3m
    ServiceAccountName:  events-sa
    Mode:                Resource
    Sink:
      Name:       default
      Namespace:  default
      Kind:       Broker (eventing.knative.dev/v1)
    Resources:
      Kind:        event (v1)
      Controller:  false
    Conditions:
      OK TYPE                     AGE REASON
      ++ Ready                     3m
      ++ Deployed                  3m
      ++ SinkProvided              3m
      ++ SufficientPermissions     3m
      ++ EventTypesProvided        3m

验证

您可以通过查看消息转储程序功能日志来验证 Kubernetes 事件是否已发送到 Knative。

  1. 获取 pod:

    $ oc get pods
  2. 查看 pod 的消息转储程序功能日志:

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    输出示例

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.apiserver.resource.update
      datacontenttype: application/json
      ...
    Data,
      {
        "apiVersion": "v1",
        "involvedObject": {
          "apiVersion": "v1",
          "fieldPath": "spec.containers{hello-node}",
          "kind": "Pod",
          "name": "hello-node",
          "namespace": "default",
           .....
        },
        "kind": "Event",
        "message": "Started container",
        "metadata": {
          "name": "hello-node.159d7608e3a3572c",
          "namespace": "default",
          ....
        },
        "reason": "Started",
        ...
      }

12.3.6. 使用 Knative CLI 删除 API 服务器源

本节介绍了使用 knoc 命令删除 API 服务器源、触发器、服务帐户、集群角色和集群角色绑定的步骤。

先决条件

  • 已安装了 kn CLI。

流程

  1. 删除触发器:

    $ kn trigger delete <trigger_name>
  2. 删除事件源:

    $ kn source apiserver delete <source_name>
  3. 删除服务帐户、集群角色和集群绑定:

    $ oc delete -f authentication.yaml

12.3.7. 使用 YAML 方法的 API 服务器源

本指南描述了使用 YAML 文件创建 API 服务器源所需的步骤。

先决条件

  • 您需要安装 Knative Serving 和 Eventing。
  • 您需要在与 API 服务器源 YAML 文件中定义的相同的命名空间中创建 default 代理。

流程

  1. 要为 API 服务器源创建服务帐户、角色和角色绑定,请创建一个名为 authentication.yaml 的文件,并将以下示例代码复制到其中:

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: events-sa
      namespace: default 1
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: event-watcher
      namespace: default 2
    rules:
      - apiGroups:
          - ""
        resources:
          - events
        verbs:
          - get
          - list
          - watch
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: k8s-ra-event-watcher
      namespace: default 3
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: event-watcher
    subjects:
      - kind: ServiceAccount
        name: events-sa
        namespace: default 4
    1 2 3 4
    将这个命名空间更改为已选择安装 API 服务器源的命名空间。
    注意

    如果要重新使用具有适当权限的现有服务帐户,您必须修改该服务帐户的 authentication.yaml

    创建 authentication.yaml 文件后,应用该文件:

    $ oc apply -f authentication.yaml
  2. 要创建 API 服务器源,创建一个名为 k8s-events.yaml 的文件,并将以下示例代码复制到其中:

    apiVersion: sources.knative.dev/v1alpha1
    kind: ApiServerSource
    metadata:
      name: testevents
    spec:
      serviceAccountName: events-sa
      mode: Resource
      resources:
        - apiVersion: v1
          kind: Event
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1
          kind: Broker
          name: default

    创建 k8s-events.yaml 文件后,应用它:

    $ oc apply -f k8s-events.yaml
  3. 要检查 API 服务器源是否已正确设置,请创建一个 Knative 服务,在日志中转储传入的信息。

    将以下示例 YAML 复制到一个名为 service.yaml 的文件中:

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: event-display
      namespace: default
    spec:
      template:
        spec:
          containers:
            - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest

    创建 service.yaml 文件后应用它:

    $ oc apply -f service.yaml
  4. 要从 default 代理创建触发器,将事件过滤到上一步中创建的服务,请创建一个名为 trigger.yaml 的文件,并将以下示例代码复制到其中:

    apiVersion: eventing.knative.dev/v1
    kind: Trigger
    metadata:
      name: event-display-trigger
      namespace: default
    spec:
      broker: default
      subscriber:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display

    创建 trigger.yaml 文件后,应用该文件:

    $ oc apply -f trigger.yaml
  5. 要创建事件,请在 default 命名空间中启动 Pod:

    $ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display
  6. 要检查控制器是否已正确映射,请输入以下命令并检查输出:

    $ oc get apiserversource.sources.knative.dev testevents -o yaml

    输出示例

    apiVersion: sources.knative.dev/v1alpha1
    kind: ApiServerSource
    metadata:
      annotations:
      creationTimestamp: "2020-04-07T17:24:54Z"
      generation: 1
      name: testevents
      namespace: default
      resourceVersion: "62868"
      selfLink: /apis/sources.knative.dev/v1alpha1/namespaces/default/apiserversources/testevents2
      uid: 1603d863-bb06-4d1c-b371-f580b4db99fa
    spec:
      mode: Resource
      resources:
      - apiVersion: v1
        controller: false
        controllerSelector:
          apiVersion: ""
          kind: ""
          name: ""
          uid: ""
        kind: Event
        labelSelector: {}
      serviceAccountName: events-sa
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1
          kind: Broker
          name: default

验证

要验证 Kubernetes 事件是否已发送到 Knative,您可以查看消息转储程序功能日志。

  1. 获取 pod:

    $ oc get pods
  2. 查看 pod 的消息转储程序功能日志:

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    输出示例

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.apiserver.resource.update
      datacontenttype: application/json
      ...
    Data,
      {
        "apiVersion": "v1",
        "involvedObject": {
          "apiVersion": "v1",
          "fieldPath": "spec.containers{hello-node}",
          "kind": "Pod",
          "name": "hello-node",
          "namespace": "default",
           .....
        },
        "kind": "Event",
        "message": "Started container",
        "metadata": {
          "name": "hello-node.159d7608e3a3572c",
          "namespace": "default",
          ....
        },
        "reason": "Started",
        ...
      }

12.3.8. 删除 API 服务器源

本节论述了如何通过删除 YAML 文件删除 API 服务器源、触发器、服务帐户、集群角色和集群角色绑定。

流程

  1. 删除触发器:

    $ oc delete -f trigger.yaml
  2. 删除事件源:

    $ oc delete -f k8s-events.yaml
  3. 删除服务帐户、集群角色和集群绑定:

    $ oc delete -f authentication.yaml

12.4. 使用 ping 源

ping 源用于定期向事件消费者发送带有恒定有效负载的 ping 事件。

ping 源可以用来调度发送事件,类似于计时器。

ping 源 YAML 示例

apiVersion: sources.knative.dev/v1alpha2
kind: PingSource
metadata:
  name: test-ping-source
spec:
  schedule: "*/2 * * * *" 1
  jsonData: '{"message": "Hello world!"}' 2
  sink: 3
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: event-display

1
事件指定的调度使用 CRON 格式
2
事件消息正文以 JSON 编码的数据字符串表示。
3
这些是事件消费者的详情。在这个示例中,我们使用名为 event-display 的 Knative 服务。

12.4.1. 使用 Developer 视角创建 ping 源

您可从 OpenShift Container Platform web 控制台创建和验证基本 ping 源。

先决条件

要使用 Developer 视角创建 ping 源,请确保:

  • OpenShift Serverless Operator、Knative Serving 和 Knative Eventing 已在 OpenShift Container Platform 集群中安装。
  • 已登陆到 web 控制台。
  • 处于 Developer 视角。
  • 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。

流程

  1. 要验证 ping 源是否可以工作,请创建一个简单的 Knative 服务,在服务日志中转储传入的信息。

    1. Developer 视角中,导航到 +AddYAML
    2. 复制 YAML 示例:

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
    3. 点击 Create
  2. 在与上一步中创建的服务相同的命名空间中创建一个 ping 源,或您要将事件发送到的任何其他接收器。

    1. Developer 视角中,导航到 +AddEvent Source。此时会显示 Event Sources 页面。
    2. 可选:如果您的事件源有多个供应商,请从 Providers 列表中选择所需的供应商,以过滤供应商的可用事件源。
    3. 选择 Ping Source,然后点击 Create Event Source。此时会显示 Create Event Source 页面。

      注意

      您可以使用 Form viewYAML view 配置 PingSource 设置,并可以在两者间切换。在不同视图间切换时数据会被保留。

    4. Schedule 输入一个值。在本例中,值为 */2 * * *,它会创建一个 PingSource,每两分钟发送一条消息。
    5. 可选:您可以为 Data 输入一个值,它是消息的有效负载。
    6. 选择一个 Sink。这可以是 Resource 或一个 URI。在这个示例中,上一步中创建的 event-display 服务被用作 Resource sink。
    7. 点击 Create

验证

您可以通过查看 Topology 页面来验证 ping 源是否已创建并连接到接收器。

  1. Developer 视角中,导航到 Topology
  2. 查看 PingSource 和 sink。

    在 Topology 视图中查看 PingSource 和服务

12.4.2. 通过 Knative CLI 使用 ping 源

以下流程描述了如何使用 kn CLI 创建基本 ping 源。

先决条件

  • 已安装 Knative Serving 和 Eventing。
  • 已安装 kn CLI。

流程

  1. 要验证 ping 源是否可以工作,请创建一个简单的 Knative 服务,在服务日志中转储传入的信息:

    $ kn service create event-display \
        --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  2. 对于您要请求的每一组 ping 事件,请在与事件消费者相同的命名空间中创建一个 ping 源:

    $ kn source ping create test-ping-source \
        --schedule "*/2 * * * *" \
        --data '{"message": "Hello world!"}' \
        --sink ksvc:event-display
  3. 输入以下命令并检查输出,检查是否正确映射了控制器:

    $ kn source ping describe test-ping-source

    输出示例

    Name:         test-ping-source
    Namespace:    default
    Annotations:  sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
    Age:          15s
    Schedule:     */2 * * * *
    Data:         {"message": "Hello world!"}
    
    Sink:
      Name:       event-display
      Namespace:  default
      Resource:   Service (serving.knative.dev/v1)
    
    Conditions:
      OK TYPE                 AGE REASON
      ++ Ready                 8s
      ++ Deployed              8s
      ++ SinkProvided         15s
      ++ ValidSchedule        15s
      ++ EventTypeProvided    15s
      ++ ResourcesCorrect     15s

验证

您可以通过查看 sink pod 的日志来验证 Kubernetes 事件是否已发送到 Knative 事件。

默认情况下,如果在 60 秒内都没有流量,Knative 服务会终止其 Pod。本指南中演示的示例创建了一个 ping 源,每 2 分钟发送一条消息,因此每个消息都应该在新创建的 pod 中观察到。

  1. 查看新创建的 pod:

    $ watch oc get pods
  2. 使用 Ctrl+C 取消查看 pod,然后查看所创建 pod 的日志:

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    输出示例

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.sources.ping
      source: /apis/v1/namespaces/default/pingsources/test-ping-source
      id: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9
      time: 2020-04-07T16:16:00.000601161Z
      datacontenttype: application/json
    Data,
      {
        "message": "Hello world!"
      }

12.4.3. 使用 Knative CLI 删除 ping 源

以下流程描述了如何使用 kn CLI 删除 ping 源。

  • 删除 ping 源:

    $ kn delete pingsources.sources.knative.dev <ping_source_name>

12.4.4. 使用 YAML 的 ping 源

以下小节描述了如何使用 YAML 文件创建基本 ping 源。

先决条件

  • 已安装 Knative Serving 和 Eventing。
注意

以下操作过程要求您创建 YAML 文件。

如果更改了示例中使用的 YAML 文件的名称,则需要更新对应的 CLI 命令。

流程

  1. 要验证 ping 源是否可以工作,请创建一个简单的 Knative 服务,在服务日志中转储传入的信息。

    1. 将 YAML 示例复制到名为 service.yaml的文件中:

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
    2. 创建服务:

      $ oc apply --filename service.yaml
  2. 对于您要请求的每一组 ping 事件,请在与事件消费者相同的命名空间中创建一个 ping 源。

    1. 将 YAML 示例复制到名为 ping-source.yaml 的文件中:

      apiVersion: sources.knative.dev/v1alpha2
      kind: PingSource
      metadata:
        name: test-ping-source
      spec:
        schedule: "*/2 * * * *"
        jsonData: '{"message": "Hello world!"}'
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display
    2. 创建 ping 源:

      $ oc apply --filename ping-source.yaml
  3. 输入以下命令检查是否正确映射了控制器:

    $ oc get pingsource.sources.knative.dev test-ping-source -oyaml

    输出示例

    apiVersion: sources.knative.dev/v1alpha2
    kind: PingSource
    metadata:
      annotations:
        sources.knative.dev/creator: developer
        sources.knative.dev/lastModifier: developer
      creationTimestamp: "2020-04-07T16:11:14Z"
      generation: 1
      name: test-ping-source
      namespace: default
      resourceVersion: "55257"
      selfLink: /apis/sources.knative.dev/v1alpha2/namespaces/default/pingsources/test-ping-source
      uid: 3d80d50b-f8c7-4c1b-99f7-3ec00e0a8164
    spec:
      jsonData: '{ value: "hello" }'
      schedule: '*/2 * * * *'
      sink:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display
          namespace: default

验证

您可以通过查看 sink pod 的日志来验证 Kubernetes 事件是否已发送到 Knative 事件。

默认情况下,如果在 60 秒内都没有流量,Knative 服务会终止其 Pod。本指南中演示的示例创建了一个 PingSource,每 2 分钟发送一条消息,因此每个消息都应该在新创建的 pod 中观察到。

  1. 查看新创建的 pod:

    $ watch oc get pods
  2. 使用 Ctrl+C 取消查看 pod,然后查看所创建 pod 的日志:

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    输出示例

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.sources.ping
      source: /apis/v1/namespaces/default/pingsources/test-ping-source
      id: 042ff529-240e-45ee-b40c-3a908129853e
      time: 2020-04-07T16:22:00.000791674Z
      datacontenttype: application/json
    Data,
      {
        "message": "Hello world!"
      }

12.4.5. 使用 YAML 删除创建的 ping 源

以下流程描述了如何删除使用 YAML 创建的 ping 源。

流程

  • 删除 ping 源:

    $ oc delete -f <ping_source_yaml_filename>

    示例命令

    $ oc delete -f ping-source.yaml

12.5. 使用接收器绑定

接收器绑定(Sink Binding) 用于将事件和 事件源连接至事件消费者或 事件接收器(如一个 Knative 服务或应用程序)。

重要

在开发人员可以使用接收器绑定之前,集群管理员必须将为接收器绑定配置的命名空间标记为 bindings.knative.dev/include:"true"

$ oc label namespace <namespace> bindings.knative.dev/include=true

12.5.1. 通过 Knative CLI 使用接收器绑定

本指南描述了使用 kn 命令创建接收器绑定实例所需的步骤。

先决条件

  • 已安装 Knative Serving 和 Eventing。
  • 已安装 kn CLI。
注意

以下操作过程要求您创建 YAML 文件。

如果更改了示例中使用的 YAML 文件的名称,则需要更新对应的 CLI 命令。

重要

在开发人员可以使用接收器绑定之前,集群管理员必须将为接收器绑定配置的命名空间标记为 bindings.knative.dev/include:"true"

$ oc label namespace <namespace> bindings.knative.dev/include=true

流程

  1. 要检查接收器绑定是否已正确设置,请创建一个 Knative 事件显示服务或事件 sink,在日志中转储传入的信息:

    $ kn service create event-display --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  2. 创建将事件定向到该服务的接收器绑定实例:

    $ kn source binding create bind-heartbeat --subject Job:batch/v1:app=heartbeat-cron --sink ksvc:event-display
  3. 创建 CronJob 资源。

    1. 创建名为 heartbeats-cronjob.yaml 的文件,并将以下示例代码复制到其中:

      apiVersion: batch/v1beta1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
      spec:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/knative-eventing-sources-heartbeats:latest
                    args:
                      - --period=1
                    env:
                      - name: ONE_SHOT
                        value: "true"
                      - name: POD_NAME
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.name
                      - name: POD_NAMESPACE
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.namespace
      重要

      要使用接收器绑定,您必须手动在 Knative 资源中添加 bindings.knative.dev/include=true 标签。

      例如,要将此标签添加到 CronJob 资源,请将以下行添加到 Job 资源 YAML 定义中:

        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
    2. 在创建了 heartbeats-cronjob.yaml 文件后,请输入:

      $ oc apply -f heartbeats-cronjob.yaml
  4. 输入以下命令并检查输出,检查是否正确映射了控制器:

    $ kn source binding describe bind-heartbeat

    输出示例

    Name:         bind-heartbeat
    Namespace:    demo-2
    Annotations:  sources.knative.dev/creator=minikube-user, sources.knative.dev/lastModifier=minikub ...
    Age:          2m
    Subject:
      Resource:   job (batch/v1)
      Selector:
        app:      heartbeat-cron
    Sink:
      Name:       event-display
      Resource:   Service (serving.knative.dev/v1)
    
    Conditions:
      OK TYPE     AGE REASON
      ++ Ready     2m

验证

您可以通过查看消息 dumper 功能日志,来验证 Kubernetes 事件是否已发送到 Knative 事件。

  • 您可以输入以下命令来查看消息转储程序功能日志:

    $ oc get pods
    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    输出示例

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.eventing.samples.heartbeat
      source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod
      id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596
      time: 2019-10-18T15:23:20.809775386Z
      contenttype: application/json
    Extensions,
      beats: true
      heart: yes
      the: 42
    Data,
      {
        "id": 1,
        "label": ""
      }

12.5.2. 使用 YAML 方法的接收器绑定

本指南描述了使用 YAML 文件创建接收器绑定实例所需的步骤。

先决条件

  • 已安装 Knative Serving 和 Eventing。
注意

以下操作过程要求您创建 YAML 文件。

如果更改了示例中使用的 YAML 文件的名称,则需要更新对应的 CLI 命令。

重要

在开发人员可以使用 SinkBinding 之前,集群管理员必须将 SinkBinding 中配置的命名空间标记为 bindings.knative.dev/include:"true":

$ oc label namespace <namespace> bindings.knative.dev/include=true

流程

  1. 要检查接收器绑定是否已正确设置,请创建一个 Knative 事件显示服务或事件接收器,在日志中转储传入的信息:

    1. 将以下示例 YAML 复制到一个名为 service.yaml 的文件中:

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
    2. 创建 service.yaml 文件后,输入以下内容应用它:

      $ oc apply -f service.yaml
  2. 创建将事件定向到该服务的接收器绑定实例。

    1. 创建名为 sinkbinding.yaml 的文件,并将以下示例代码复制到其中:

      apiVersion: sources.knative.dev/v1alpha1
      kind: SinkBinding
      metadata:
        name: bind-heartbeat
      spec:
        subject:
          apiVersion: batch/v1
          kind: Job 1
          selector:
            matchLabels:
              app: heartbeat-cron
      
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display
      1
      在本例中,任何具有标签 app: heartbeat-cron 的作业都将被绑定到事件 sink。
    2. 创建 sinkbinding.yaml 文件后,输入以下内容应用它:

      $ oc apply -f sinkbinding.yaml
  3. 创建 CronJob 资源。

    1. 创建名为 heartbeats-cronjob.yaml 的文件,并将以下示例代码复制到其中:

      apiVersion: batch/v1beta1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
      spec:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/knative-eventing-sources-heartbeats:latest
                    args:
                      - --period=1
                    env:
                      - name: ONE_SHOT
                        value: "true"
                      - name: POD_NAME
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.name
                      - name: POD_NAMESPACE
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.namespace
      重要

      要使用接收器绑定,您必须手动在 Knative 资源中添加 bindings.knative.dev/include=true 标签。

      例如,要将此标签添加到 CronJob 资源,请将以下行添加到 Job 资源 YAML 定义中:

        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
    2. 在创建了 heartbeats-cronjob.yaml 文件后,请输入:

      $ oc apply -f heartbeats-cronjob.yaml
  4. 输入以下命令并检查输出,检查是否正确映射了控制器:

    $ oc get sinkbindings.sources.knative.dev bind-heartbeat -oyaml

    输出示例

    spec:
      sink:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display
          namespace: default
      subject:
        apiVersion: batch/v1
        kind: Job
        namespace: default
        selector:
          matchLabels:
            app: heartbeat-cron

验证

您可以通过查看消息 dumper 功能日志,来验证 Kubernetes 事件是否已发送到 Knative 事件。

  1. 输入命令:

    $ oc get pods
  2. 输入命令:

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    输出示例

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.eventing.samples.heartbeat
      source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod
      id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596
      time: 2019-10-18T15:23:20.809775386Z
      contenttype: application/json
    Extensions,
      beats: true
      heart: yes
      the: 42
    Data,
      {
        "id": 1,
        "label": ""
      }

12.6. 使用 Kafka 源

重要

OpenShift Serverless 上的 Apache Kafka 只是一个技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持,且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的详情,请参阅 https://access.redhat.com/support/offerings/techpreview/

Apache Kafka 事件源将信息引入 Knative。它从 Apache Kafka 集群读取事件,并将这些事件传递给事件接收器,以便消耗这些事件。您可以在 OpenShift Serverless 中使用 KafkaSource 事件源。

12.6.1. 使用 Web 控制台创建 Kafka 事件源

您可从 OpenShift Container Platform Web 控制台创建并验证 Kafka 事件源。

先决条件

  • OpenShift Serverless Operator、Knative Eventing 和 KnativeKafka 自定义资源已安装在集群中。
  • 已登陆到 web 控制台。
  • 处于 Developer 视角。
  • 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。

流程

  1. 导航到 Add 页面并选择 Event Source
  2. Event Sources 页面中,在 Type 部分选择 Kafka Source
  3. 配置 Kafka Source 设置:

    1. 添加用逗号分开的 Bootstrap 服务器列表。
    2. 添加以逗号分隔的标题列表。
    3. 添加一个 消费者组
    4. 为您创建的服务帐户选择 Service Account Name
    5. 为事件源选择 SinkSink 可以是一个 资源,如频道、代理或服务,也可以是一个 URI
    6. 输入 Kafka 事件源的 名称
  4. 点击 Create

验证

您可以通过查看 Topology 页面来验证 Kafka 事件源是否已创建并连接到接收器。

  1. Developer 视角中,导航到 Topology
  2. 查看 Kafka 事件源和接收器。

    在 Topology 视图中查看 Kafka 源和服务

12.6.2. 使用 YAML 创建 Kafka 事件源

您可以使用 YAML 创建 Kafka 事件源。

先决条件

  • OpenShift Serverless Operator、Knative Eventing 和 KnativeKafka 自定义资源已安装在集群中。
  • 您已创建了一个项目,或者具有适当的角色和权限访问项目,以便在 OpenShift Container Platform 中创建应用程序和其他工作负载。

流程

  1. 创建一个包含以下内容的 YAML 文件:

    apiVersion: sources.knative.dev/v1beta1
    kind: KafkaSource
    metadata:
      name: <source-name>
    spec:
      consumerGroup: <group-name> 1
      bootstrapServers:
      - <list-of-bootstrap-servers>
      topics:
      - <list-of-topics> 2
      sink:
    1
    用户组是一组使用相同组群 ID 的用户,并消耗一个标题中的数据。
    2
    主题提供数据存储的目的地。每个主题都被分成一个或多个分区。

    KafkaSource 对象示例

    apiVersion: sources.knative.dev/v1beta1
    kind: KafkaSource
    metadata:
      name: kafka-source
    spec:
      consumerGroup: knative-group
      bootstrapServers:
      - my-cluster-kafka-bootstrap.kafka:9092
      topics:
      - knative-demo-topic
      sink:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display

  2. 应用 YAML 文件:

    $ oc apply -f <filename>

12.6.3. 其他资源

第 13 章 在 OpenShift Serverless 中使用 Apache Kafka

重要

OpenShift Serverless 上的 Apache Kafka 只是一个技术预览功能。技术预览功能不被红帽产品服务等级协议 (SLA) 支持,且可能在功能方面有缺陷。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的详情,请参阅 https://access.redhat.com/support/offerings/techpreview/

您可以在 OpenShift Serverless 中使用 KafkaChannel 频道类型和 KafkaSource 事件源。要做到这一点,您必须安装 Knative Kafka 组件,并配置 OpenShift Serverless 和受支持的 Red Hat AMQ Streams 集群之间的集成。

OpenShift Serverless Operator 提供了 Knative Kafka API,可用于创建 KnativeKafka 自定义资源:

KnativeKafka 自定义资源示例

apiVersion: operator.serverless.openshift.io/v1alpha1
kind: KnativeKafka
metadata:
    name: knative-kafka
    namespace: knative-eventing
spec:
    channel:
        enabled: true 1
        bootstrapServers: <bootstrap_server> 2
    source:
        enabled: true 3

1
让开发人员在集群中使用 KafkaChannel 频道类型。
2
以逗号分隔的 AMQ Streams 集群中的 bootstrap 服务器列表。
3
让开发人员在集群中使用 KafkaSource 事件源类型。

13.1. 使用 Web 控制台安装 Apache Kafka 组件

集群管理员可以通过实例化由 Knative Kafka OpenShift Serverless Operator API 提供的 KnativeKafka 自定义资源定义,在 OpenShift Serverless 部署中启用 Apache Kafka 功能。

先决条件

  • 已在 OpenShift Container Platform 集群中安装了 OpenShift Serverless(包括 Knative Eventing)。
  • 您可以访问 Red Hat AMQ Streams 集群。
  • 在 OpenShift Container Platform 上具有集群管理员权限。
  • 已登陆到 web 控制台。

流程

  1. Administrator 视角中,进入 OperatorsInstalled Operators
  2. 检查页面顶部的 Project 下拉菜单是否已设置为 Project: knative-eventing
  3. 点 OpenShift Serverless Operator 的 Provided APIs 列表中的 Knative Kafka 进入 Knative Kafka 标签页。
  4. Create Knative Kafka
  5. 可选: 在 Create Knative Kafka 页面中配置 KnativeKafka 对象。要做到这一点,使用提供的默认表单或编辑 YAML。

    1. 建议您在不需要完全控制 KnativeKafka 对象创建的简单配置中使用该表单。
    2. 对于更复杂的配置,建议编辑 YAML,这可以完全控制 KnativeKafka 对象的创建。您可以通过点 Create Knative Kafka 页面右上角的 Edit YAML 链接来访问 YAML。
  6. 完成 Kafka 的任何可选配置后,点 Create。您会自动定向到 Knative Kafka 标签页,其中 knative-kafka 在资源列表中。

验证

  1. Knative Kafka 选项卡中的 knative-kafka 资源。您会自动定向到 Knative Kafka Overview 页面。
  2. 查看资源的 Conditions 列表,并确认其状态为 True

    Kafka Knative Overview 页面显示 Conditions

    如果条件的状态为 UnknownFalse,请等待几分钟刷新页面。

  3. 检查是否已创建 Knative Kafka 资源:

    $ oc get pods -n knative-eventing

    输出示例

    NAME                                                       READY   STATUS      RESTARTS   AGE
    kafka-ch-controller-5d85f5f779-kqvs4                       1/1     Running     0          126m
    kafka-webhook-66bd8688d6-2grvf                             1/1     Running     0          126m

13.2. 后续步骤

第 14 章 网络

14.1. 将自定义域名映射到 Knative 服务

Knative 服务会自动根据集群配置分配默认域名。例如,<service_name(5).<namespace\".example.com。您可以通过为该服务创建 DomainMapping 自定义资源(CR)来映射您自己的自定义域名。您还可以创建多个 CR 将多个域和子域映射到单个服务。

14.1.1. 为服务创建自定义域映射

要将自定义域名映射到服务,您必须创建一个 DomainMapping 自定义资源(CR)。

先决条件

  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
  • 您已创建了 Knative 服务,并控制要映射到该服务的自定义域。

    注意

    您的自定义域必须指向 OpenShift Container Platform 集群的 DNS。

流程

  1. 在与您要映射的 Knative 服务相同的命名空间中创建一个包含 DomainMapping CR 的 YAML 文件:

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
     name: <domain_name> 1
     namespace: <namespace> 2
    spec:
     ref:
       name: <service_name> 3
       kind: Service
       apiVersion: serving.knative.dev/v1
    1
    要映射到该服务的自定义域名。
    2
    DomainMapping CR 和 Knative 服务的命名空间。
    3
    要映射到自定义域的服务名称。
  2. DomainMapping CR 应用为 YAML 文件:

    $ oc apply -f <filename>

14.2. 为 Knative 服务配置路由

Knative 利用 OpenShift Container Platform TLS 终止来为 Knative 服务提供路由。创建 Knative 服务时,会自动为该服务创建一个 OpenShift Container Platform 路由。此路由由 OpenShift Serverless Operator 管理。OpenShift Container Platform 路由通过与 OpenShift Container Platform 集群相同的域公开 Knative 服务。

您可以禁用 OpenShift Container Platform 路由的 Operator 控制,以便您可以配置 Knative 路由来直接使用 TLS 证书。

Knative 路由也可以与 OpenShift Container Platform 路由一起使用,以提供额外的精细路由功能,如流量分割。

14.2.1. 为 Knative 服务配置 OpenShift Container Platform 路由

如果要将 Knative 服务配置为在 OpenShift Container Platform 上使用 TLS 证书,则必须禁用 OpenShift Serverless Operator 为服务自动创建路由,而是为服务手动创建 Route 资源。

先决条件

  • OpenShift Serverless Operator 和 Knative Serving 组件必须安装在 OpenShift Container Platform 集群中。

流程

  1. 创建包含 service.knative.openshift.io/disableRoute=true 注解的 Knative 服务:

    YAML 示例

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: <service_name>
      annotations:
        serving.knative.openshift.io/disableRoute: true
    spec:
      template:
        spec:
          containers:
          - image: <image>

    kn 命令示例

    $ kn service create hello-example \
      --image=gcr.io/knative-samples/helloworld-go \
      --annotation serving.knative.openshift.io/disableRoute=true

  2. 验证没有为服务创建 OpenShift Container Platform 路由:

    示例命令

    $ oc get routes.route.openshift.io -l serving.knative.openshift.io/ingressName=$KSERVICE_NAME -l serving.knative.openshift.io/ingressNamespace=$KSERVICE_NAMESPACE -n knative-serving-ingress

    您应该看到以下输出:

    No resources found in knative-serving-ingress namespace.
  3. 通过复制以下示例 YAML 并修改可替换值,在 knative-serving-ingress 命名空间中创建 Route 对象:

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      annotations:
        haproxy.router.openshift.io/timeout: 600s 1
      name: <route_name> 2
      namespace: knative-serving-ingress 3
    spec:
      host: <service_host> 4
      port:
        targetPort: http2
      to:
        kind: Service
        name: kourier
        weight: 100
      tls:
        insecureEdgeTerminationPolicy: Allow
        termination: edge 5
        key: |-
          -----BEGIN PRIVATE KEY-----
          [...]
          -----END PRIVATE KEY-----
        certificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
        caCertificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE----
      wildcardPolicy: None
    1
    OpenShift Container Platform 路由的超时值。您必须设置与 max-revision-timeout-seconds 设置相同的值(默认为 600s )。
    2
    OpenShift Container Platform 路由的名称。
    3
    OpenShift Container Platform 路由的命名空间。这必须是 knative-serving-ingress
    4
    用于外部访问的主机名。您可以将其设置为 <service_name>-<service_namespace>.<domain>
    5
    您要使用的证书。目前,只支持 边缘(edge) 终止。

14.3. 在 OpenShift Serverless 中使用 Service Mesh

与 OpenShift Serverless 一起使用 Service Mesh 可让开发人员配置在使用 OpenShift Serverless 的默认 Kourier 时不支持的额外联网和路由选项。这些选项包括使用 TLS 证书设置自定义域以及使用 JSON Web Token 身份验证。

14.3.1. 先决条件

14.3.2. 在 OpenShift Serverless 中使用 Service Mesh

流程

  1. 将您要与 Service Mesh 集成的命名空间作为成员添加到 ServiceMeshMemberRoll 对象中:

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      members:
        - <namespace> 1
    1
    要与 Service Mesh 集成的命名空间列表。
    重要

    不支持在系统命名空间中向 Pod 添加 sidecar 注入,如 knative-servingknative-serving-ingress

  2. 创建允许 Knative 系统 Pod 到 Knative 服务流量的网络策略:

    1. service.knative.openshift.io/system-namespace=true 标签添加到 knative-serving 命名空间:

      $ oc label namespace knative-serving serving.knative.openshift.io/system-namespace=true
    2. service.knative.openshift.io/system-namespace=true 标签添加到 knative-serving-ingress 命名空间:

      $ oc label namespace knative-serving-ingress serving.knative.openshift.io/system-namespace=true
    3. 对于您要与 Service Mesh 集成的每个命名空间,将以下 NetworkPolicy 资源复制到 YAML 文件中:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-serving-system-namespace
        namespace: <namespace>
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                serving.knative.openshift.io/system-namespace: "true"
        podSelector: {}
        policyTypes:
        - Ingress
    4. 应用 NetworkPolicy 资源:

      $ oc apply -f <filename>

14.3.3. 为 Knative 服务启用 sidecar 注入

您可以向 Service 资源 YAML 文件添加注解,以便为 Knative 服务启用 sidecar 注入。

流程

  1. 为服务资源添加 sidecar.istio.io/inject="true" 注解:

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: hello-example-1
    spec:
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "true" 1
        spec:
          containers:
          - image: docker.io/openshift/hello-openshift
            name: container
    1
    添加 sidecar.istio.io/inject="true" 注解。
  2. 应用服务资源 YAML 文件:

    $ oc apply -f <filename>

14.4. 在 Service Mesh 和 OpenShift Serverless 中使用 JSON Web 令牌身份验证

您可以为 Knative 服务启用 JSON Web Token(JWT)身份验证。

14.4.1. 先决条件

重要

不支持在系统命名空间中向 pod 添加 sidecar 注入,如 knative-servingknative-serving-ingress

14.4.2. 在 Service Mesh 2.x 和 OpenShift Serverless 中使用 JSON Web 令牌身份验证

流程

  1. 通过将以下代码复制到 YAML 文件中,在作为 ServiceMeshMemberRoll 对象的成员的每个无服务器应用程序命名空间中创建 RequestAuthentication 资源:

    apiVersion: security.istio.io/v1beta1
    kind: RequestAuthentication
    metadata:
      name: jwt-example
      namespace: <namespace>
    spec:
      jwtRules:
      - issuer: testing@secure.istio.io
        jwksUri: https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/jwks.json
  2. 应用 RequestAuthentication 资源:

    $ oc apply -f <filename>
  3. 通过将以下 AuthorizationPolicy 资源复制到一个 YAML 文件,允许从 ServiceMeshMemberRoll 对象中的每个无服务器应用程序命名空间的系统 pod 访问 RequestAuthenticaton 资源:

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: allowlist-by-paths
      namespace: <namespace>
    spec:
      action: ALLOW
      rules:
      - to:
        - operation:
            paths:
            - /metrics 1
            - /healthz 2
    1
    由系统 pod 收集指标的应用程序上的路径。
    2
    系统 pod 探测到应用程序的路径。
  4. 应用 AuthorizationPolicy 资源 YAML 文件:

    $ oc apply -f <filename>
  5. 对于作为 ServiceMeshMemberRoll 对象中成员的每个无服务器应用程序命名空间,请将以下 AuthorizationPolicy 资源复制到 YAML 文件中:

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: require-jwt
      namespace: <namespace>
    spec:
      action: ALLOW
      rules:
      - from:
        - source:
           requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"]
  6. 应用 AuthorizationPolicy 资源 YAML 文件:

    $ oc apply -f <filename>

验证

  1. 如果您尝试使用 curl 请求来获取 Knative 服务 URL,则会被拒绝。

    $ curl http://hello-example-1-default.apps.mycluster.example.com/

    输出示例

    RBAC: access denied

  2. 使用有效 JWT 验证请求。

    1. 输入以下命令来获取有效的 JWT 令牌:

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -
    2. 使用 curl 请求标头中的有效令牌访问该服务:

      $ curl -H "Authorization: Bearer $TOKEN"  http://hello-example-1-default.apps.example.com

      现在,这个请求被允许。

      输出示例

      Hello OpenShift!

14.4.3. 在 Service Mesh 1.x 和 OpenShift Serverless 中使用 JSON Web 令牌身份验证

流程

  1. 在作为 ServiceMeshMemberRoll 对象的成员的无服务器应用程序命名空间中创建策略,该策略只允许具有有效 JSON Web Tokens(JWT)的请求:

    1. 将以下 Policy 资源复制到 YAML 文件中:

      重要

      路径 /metrics/healthz 必须包含在 excludePaths 中,因为它们是从 knative-serving 命名空间中的系统 Pod 访问的。

      apiVersion: authentication.istio.io/v1alpha1
      kind: Policy
      metadata:
        name: default
        namespace: <namespace>
      spec:
        origins:
        - jwt:
            issuer: testing@secure.istio.io
            jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/jwks.json"
            triggerRules:
            - excludedPaths:
              - prefix: /metrics 1
              - prefix: /healthz 2
        principalBinding: USE_ORIGIN
      1
      由系统 pod 收集指标的应用程序上的路径。
      2
      系统 pod 探测到应用程序的路径。
    2. 应用 Policy 资源:

      $ oc apply -f <filename>

验证

  1. 如果您尝试使用 curl 请求来获取 Knative 服务 URL,则会被拒绝。

    $ curl http://hello-example-default.apps.mycluster.example.com/

    输出示例

    Origin authentication failed.

  2. 使用有效 JWT 验证请求。

    1. 输入以下命令来获取有效的 JWT 令牌:

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -
    2. 使用 curl 请求标头中的有效令牌访问该服务:

      $ curl http://hello-example-default.apps.mycluster.example.com/ -H "Authorization: Bearer $TOKEN"

      现在,这个请求被允许。

      输出示例

      Hello OpenShift!

14.5. 在 Service Mesh 中使用自定义域进行 Knative 服务

默认情况下,Knative 服务具有固定的域格式:

 <application_name>-<namespace>.<openshift_cluster_domain>

您可以通过将服务配置为私有服务并创建所需的 Service Mesh 资源来自定义 Knative 服务域。

先决条件

14.5.1. 将集群可用性设置为 cluster-local

默认情况下,Knative 服务会发布到一个公共 IP 地址。被发布到一个公共 IP 地址意味着 Knative 服务是公共应用程序,并有一个公开访问的 URL。

可以从集群以外访问公开的 URL。但是,开发人员可能需要构建后端服务,这些服务只能从集群内部访问(称为 私有服务 )。开发人员可以使用 service.knative.dev/visibility=cluster-local 标签标记集群中的各个服务,使其具有私有性。

流程

  • 通过添加 service.knative.dev/visibility=cluster-local 标签来设置服务的可见性:

    $ oc label ksvc <service_name> serving.knative.dev/visibility=cluster-local

验证

  • 输入以下命令并查看输出结果,检查您的服务的 URL 是否现在格式为 http://<service_name>.<namespace>.svc.cluster.local

    $ oc get ksvc

    输出示例

    NAME            URL                                                                         LATESTCREATED     LATESTREADY       READY   REASON
    hello           http://hello.default.svc.cluster.local                                      hello-tx2g7       hello-tx2g7       True

14.5.2. 创建必要的 Service Mesh 资源

流程

  1. 创建 Istio 网关以接受流量。

    1. 创建 YAML 文件,并将以下 YAML 复制到其中:

      apiVersion: networking.istio.io/v1alpha3
      kind: Gateway
      metadata:
        name: default-gateway
      spec:
        selector:
          istio: ingressgateway
        servers:
        - port:
            number: 80
            name: http
            protocol: HTTP
          hosts:
          - "*"
    2. 应用 YAML 文件:

      $ oc apply -f <filename>
  2. 创建一个 Istio VirtualService 对象来重写主机标头。

    1. 创建 YAML 文件,并将以下 YAML 复制到其中:

      apiVersion: networking.istio.io/v1alpha3
      kind: VirtualService
      metadata:
        name: hello
      spec:
        hosts:
        - custom-ksvc-domain.example.com
        gateways:
        - default-gateway
        http:
        - rewrite:
            authority: hello.default.svc 1
          route:
          - destination:
              host: hello.default.svc 2
              port:
                number: 80
      1 2
      Knative 服务格式为 <service_name>.<namespace>.svc
    2. 应用 YAML 文件:

      $ oc apply -f <filename>
  3. 创建 Istio ServiceEntry 对象。OpenShift Serverless 需要此项,因为 Kourier 不在服务网格之外。

    1. 创建 YAML 文件,并将以下 YAML 复制到其中:

      apiVersion: networking.istio.io/v1alpha3
      kind: ServiceEntry
      metadata:
        name: hello.default.svc
      spec:
        hosts:
        - hello.default.svc 1
        location: MESH_EXTERNAL
        endpoints:
        - address: kourier-internal.knative-serving-ingress.svc
        ports:
        - number: 80
          name: http
          protocol: HTTP
        resolution: DNS
      1
      Knative 服务格式为 <service_name>.<namespace>.svc
    2. 应用 YAML 文件:

      $ oc apply -f <filename>
  4. 创建一个指向 VirtualService 对象的 OpenShift Container Platform 路由。

    1. 创建 YAML 文件,并将以下 YAML 复制到其中:

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        name: hello
        namespace: istio-system 1
      spec:
        host: custom-ksvc-domain.example.com
        port:
          targetPort: 8080
        to:
          kind: Service
          name: istio-ingressgateway
1
OpenShift Container Platform 路由必须与 ServiceMeshControlPlane 在同一个命名空间中创建。在本例中,ServiceMeshControlPlane 部署到 istio-system 命名空间中。
  1. 应用 YAML 文件:

    $ oc apply -f <filename>

14.5.3. 使用自定义域访问服务

流程

  1. 使用 curl 请求中的 Host 标头访问自定义域。例如:

    $ curl -H "Host: custom-ksvc-domain.example.com" http://<ip_address>

    这里的 <ip_address> 是 OpenShift Container Platform 入口路由器公开的 IP 地址。

    输出示例

    Hello OpenShift!

14.5.4. 其他资源

14.6. 使用 Red Hat OpenShift Service Mesh 为自定义域配置传输层安全性

您可以使用 Red Hat OpenShift Service Mesh 为自定义域和子域创建传输层安全(TLS)密钥和证书。

注意

OpenShift Serverless 只适用于 Red Hat OpenShift Service Mesh 1.x 或 2.x 的完整实现。OpenShift Serverless 不支持在同一部署中自定义使用一些 1.x 资源,以及一些 2.x 资源。例如,在仍然使用 control plane maistra.io/v1 spec 时,还不支持升级到 2.x。

14.6.1. 先决条件

重要

这个示例使用 example.com 域。这个域的示例证书被用作为子域证书签名的证书颁发机构(CA)。

要在部署中完成并验证此步骤,您需要具有被广泛信任的公共 CA 签名的证书,或者您的机构提供的 CA。

可根据您的域、子域和 CA 对命令进行调整。

14.6.2. 使用 Red Hat OpenShift Service Mesh 2.x 为自定义域配置传输层安全性

您可以使用 Red Hat OpenShift Service Mesh 为自定义域和子域创建传输层安全(TLS)密钥和证书。

流程

  1. 创建一个 root 证书和私钥来为您的服务签名证书:

    $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
        -subj '/O=Example Inc./CN=example.com' \
        -keyout example.com.key \
        -out example.com.crt
  2. 为您的域创建证书签名请求:

    $ openssl req -out custom.example.com.csr -newkey rsa:2048 -nodes \
        -keyout custom.example.com.key \
        -subj "/CN=custom-ksvc-domain.example.com/O=Example Inc."
  3. 使用您的 CA 签署请求:

    $ openssl x509 -req -days 365 -set_serial 0 \
        -CA example.com.crt \
        -CAkey example.com.key \
        -in custom.example.com.csr \
        -out custom.example.com.crt
  4. 检查证书是否出现在您的目录中:

    $ ls -1

    输出示例

    custom.example.com.crt
    custom.example.com.csr
    custom.example.com.key
    example.com.crt
    example.com.key

  5. 创建 secret:

    $ oc create -n istio-system secret tls custom.example.com \
        --key=custom.example.com.key \
        --cert=custom.example.com.crt
  6. 通过编辑 ServiceMeshControlPlane 资源,将 secret 附加到 Istio ingress 网关。

    1. 编辑 ServiceMeshControlPlane 资源:

      $ oc edit -n istio-system ServiceMeshControlPlane <control-plane-name>
    2. 检查资源中是否有以下行,如果没有,请添加它们:

      spec:
        gateways:
          ingress:
            volumes:
            - volume:
                secret:
                  secretName: custom.example.com
              volumeMount:
                name: custom-example-com
                mountPath: /custom.example.com
  7. 更新 Istio ingress 网关以使用您的 secret。

    1. 编辑 default-gateway 资源:

      $ oc edit gateway default-gateway
    2. 检查资源中是否有以下行,如果没有,请添加它们:

      - hosts:
        - custom-ksvc-domain.example.com
        port:
          name: https
          number: 443
          protocol: HTTPS
        tls:
          mode: SIMPLE
          privateKey: /custom.example.com/tls.key
          serverCertificate: /custom.example.com/tls.crt
  8. 更新路由以使用 pass-through TLS 和 8443 作为 spec.port.targetPort

    1. 编辑路由:

      $ oc edit route -n istio-system hello
    2. 在路由中添加以下配置:

      spec:
        host: custom-ksvc-domain.example.com
        port:
          targetPort: 8443
        tls:
          insecureEdgeTerminationPolicy: None
          termination: passthrough
        to:
          kind: Service
          name: istio-ingressgateway
          weight: 100
        wildcardPolicy: None

验证

  • 通过 CA 信任的安全连接访问无服务器应用程序:

    $ curl --cacert example.com.crt \
        --header "Host: custom-ksvc-domain.example.com" \
        --resolve "custom-ksvc-domain.example.com:443:<ingress_router_IP>" \
         https://custom-ksvc-domain.example.com:443
    注意

    您必须将您自己的值替换为 <ingress_router_IP>。查找此 IP 或主机名值的步骤会因 OpenShift Container Platform 供应商平台的不同而有所不同。

    此命令对 GCP 和 Azure 供应商平台有效:

    $ oc get svc -n openshift-ingress router-default \
        -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

    输出示例

    Hello OpenShift!

14.6.3. 使用 Red Hat OpenShift Service Mesh 1.x 为自定义域配置传输层安全性

您可以使用 Red Hat OpenShift Service Mesh 为自定义域和子域创建传输层安全(TLS)密钥和证书。

流程

  1. 创建一个 root 证书和私钥来为您的服务签名证书:

    $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
        -subj '/O=Example Inc./CN=example.com' \
        -keyout example.com.key \
        -out example.com.crt
  2. 为您的域创建证书签名请求:

    $ openssl req -out custom.example.com.csr -newkey rsa:2048 -nodes \
        -keyout custom.example.com.key \
        -subj "/CN=custom-ksvc-domain.example.com/O=Example Inc."
  3. 使用您的 CA 签署请求:

    $ openssl x509 -req -days 365 -set_serial 0 \
        -CA example.com.crt \
        -CAkey example.com.key \
        -in custom.example.com.csr \
        -out custom.example.com.crt
  4. 检查证书是否出现在您的目录中:

    $ ls -1

    输出示例

    custom.example.com.crt
    custom.example.com.csr
    custom.example.com.key
    example.com.crt
    example.com.key

  5. 创建 secret:

    $ oc create -n istio-system secret tls custom.example.com \
        --key=custom.example.com.key \
        --cert=custom.example.com.crt
  6. 通过编辑 ServiceMeshControlPlane 资源,将 secret 附加到 Istio ingress 网关。

    1. 编辑 ServiceMeshControlPlane 资源:

      $ oc edit -n istio-system ServiceMeshControlPlane <control_plane_name>
    2. 检查资源中是否有以下行,如果没有,请添加它们:

      spec:
        istio:
          gateways:
            istio-ingressgateway:
              secretVolumes:
              - mountPath: /custom.example.com
                name: custom-example-com
                secretName: custom.example.com
  7. 更新 Istio ingress 网关以使用您的 secret。

    1. 编辑 default-gateway 资源:

      $ oc edit gateway default-gateway
    2. 检查资源中是否有以下行,如果没有,请添加它们:

      - hosts:
        - custom-ksvc-domain.example.com
        port:
          name: https
          number: 443
          protocol: HTTPS
        tls:
          mode: SIMPLE
          privateKey: /custom.example.com/tls.key
          serverCertificate: /custom.example.com/tls.crt
  8. 更新路由以使用 pass-through TLS 和 8443 作为 spec.port.targetPort

    1. 编辑路由:

      $ oc edit route -n istio-system hello
    2. 在路由中添加以下配置:

      spec:
        host: custom-ksvc-domain.example.com
        port:
          targetPort: 8443
        tls:
          insecureEdgeTerminationPolicy: None
          termination: passthrough
        to:
          kind: Service
          name: istio-ingressgateway
          weight: 100
        wildcardPolicy: None

验证

  • 通过 CA 信任的安全连接访问无服务器应用程序:

    $ curl --cacert example.com.crt \
        --header "Host: custom-ksvc-domain.example.com" \
        --resolve "custom-ksvc-domain.example.com:443:<ingress_router_IP>" \
         https://custom-ksvc-domain.example.com:443
    注意

    您必须将您自己的值替换为 <ingress_router_IP>。查找此 IP 或主机名值的步骤会因 OpenShift Container Platform 供应商平台的不同而有所不同。

    此命令对 GCP 和 Azure 供应商平台有效:

    $ oc get svc -n openshift-ingress router-default \
        -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

    输出示例

    Hello OpenShift!

第 15 章 监控

15.1. 监控无服务器组件

您可以使用 OpenShift Container Platform 监控仪表板查看 OpenShift Serverless 组件的健康检查和指标。

15.1.1. 监控无服务器组件整体健康状况

您可以使用 OpenShift Container Platform 监控仪表板查看 Knative Serving 和 Eventing 的整体健康状况。

先决条件

  • 已安装 OpenShift Serverless。
  • OpenShift Container Platform 监控堆栈被启用。
  • 有集群管理员权限,并在 OpenShift Container Platform Web 控制台中访问 Administrator 视角。

流程

  1. Administrator 视角中,导航到 MonitoringDashboards
  2. 选择 Knative Health Status dashboard 查看 Knative Serving 和 Eventing 的整体健康状况。

    Knative Health Status dashboard

15.1.2. 监控 Knative Serving 修订 CPU 和内存使用情况

您可以使用 OpenShift Container Platform 监控仪表板查看 Knative Serving 组件的修订 CPU 和内存用量指标。

先决条件

  • 已安装 OpenShift Serverless。
  • OpenShift Container Platform 监控堆栈被启用。
  • 有集群管理员权限,并在 OpenShift Container Platform Web 控制台中访问 Administrator 视角。

流程

  1. Administrator 视角中,导航到 MonitoringDashboards
  2. 选择 Knative Serving - Revision CPU and Memory Usage 仪表板,以查看 Knative 服务修订版本的指标。
  3. 可选: 您可以使用下拉菜单根据 NamespaceConfigurationRevision 来过滤此仪表板。

    Knative Serving 修订 CPU 和内存用量仪表板

第 16 章 集成

16.1. 使用无服务器应用程序的 NVIDIA GPU 资源

NVIDIA 支持在 OpenShift Container Platform 上试验性地使用 GPU 资源。如需在OpenShift Container Platform 上设置 GPU 资源的更多信息,请参阅 NVIDIA GPU 加速集群上的 OpenShift Container Platform

为 OpenShift Container Platform 集群启用 GPU 资源后,可以使用 kn CLI 为 Knative 服务指定 GPU 要求。

流程

在使用 kn 创建 Knative 服务时,可以指定 GPU 资源要求。

  1. 创建服务。
  2. 使用 nvidia.com/gpu=1 将 GPU 资源要求限制设置为 1:

    $ kn service create hello --image docker.io/knativesamples/hellocuda-go --limit nvidia.com/gpu=1

    GPU 资源要求限制为 1 表示该服务有 1 个专用的 GPU 资源。服务不共享 GPU 资源。所有需要 GPU 资源的其他服务都必须等待 GPU 资源不再被使用为止。

    限值为 1 个 GPU 意味着超过使用 1 个 GPU 资源的应用程序会受到限制。如果服务请求超过 1 个 GPU 资源,它将部署到可以满足 GPU 资源要求的节点。

使用 kn更新 Knative 服务的 GPU 要求

  • 更新该服务。使用 nvidia.com/gpu=3 将 GPU 资源要求限制改为 3
$ kn service update hello --limit nvidia.com/gpu=3

16.1.1. 其他资源

法律通告

Copyright © 2021 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.