Serverless

OpenShift Container Platform 4.5

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

Red Hat OpenShift Documentation Team

摘要

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

第 1 章 OpenShift Serverless 发行注记

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

重要

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

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

1.1. Red Hat OpenShift Serverless 1.10.1 发行注记

此 OpenShift Serverless 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

1.1.1. 修复的问题

  • 通用基础镜像(UBI)已由 1.10.0 中的 ubi8-minimal-container-8.2-349 更新至此版本中的 ubi8-minimal-container-8.3-230

1.2. Red Hat OpenShift Serverless 1.10.0 发行注记

1.2.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.2.2. 修复的问题

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

1.3. Red Hat OpenShift Serverless 1.9.0 发行注记

1.3.1. 新功能

  • OpenShift Serverless 现在使用 Knative Operator 0.15.2。Knative Serving 和 Knative Eventing Operator 现已合并到一个普通的 Operator 中。
  • OpenShift Serverless 现在使用 Knative Serving 0.15.2。
  • OpenShift Serverless 现在使用 Knative kn CLI 0.15.2。
  • OpenShift Serverless 使用 Knative Eventing 0.15.2。
  • OpenShift Serverless 现在使用 Kourier 0.15.0。
  • OpenShift Serverless 现在支持一些集成的 Red Hat OpenShift Service Mesh 功能,包括启用 sidecar 和 JSON Web Token(JWT)验证。网络 指南中记录了支持的功能。

1.3.2. 已知问题

  • 删除 KnativeEventing 自定义资源(CR)后, v0.15.0-upgrade-xr55xstorage-version-migration-eventing-99c7q pod 会保留在集群中,并显示 Completed 状态。您可以删除安装 KnativeEventing CR 的命名空间来完全删除这些 pod。

1.4. Red Hat OpenShift Serverless 1.8.0 发行注记

1.4.1. 新功能

  • OpenShift Serverless 现在使用 Knative Serving 0.14.1。
  • OpenShift Serverless 现在使用 Knative Serving Operator 0.14.0。
  • OpenShift Serverless 现在使用 Knative kn CLI 0.14.0。
  • OpenShift Serverless 现在使用 Knative Eventing 0.14.2。
  • OpenShift Serverless 现在使用 Knative Serving Operator 0.14.0。
  • OpenShift Serverless 现在使用 Kourier 0.14.1。

1.4.2. 已知问题

  • 对于 queue-proxy 设置,Knative Serving 有一个固定的、最小 CPU 请求 25m。如果您的集群设置了与这个值冲突的值,例如,如果您为 defaultRequest 设定了大于 25m 的最小 CPU 请求,Knative 服务将无法部署。作为临时解决方案,您可以单独为 Knative 服务配置 resourcePercentage 注解。

    resourcePercentage 配置示例

    spec:
      template:
        metadata:
          annotations:
            queue.sidecar.serving.knative.dev/resourcePercentage: "10" 1

    1
    queue.sidecar.serving.knative.dev/resourcePercentage 是用于 queue-proxy 的用户容器资源的百分比。可在 0.1 到 100 之间。
  • 在 OpenShift Container Platform 4.5 及更新的版本中,部署带有流量分布的 Knative Service 在 web 控制台的 Developer 视角中显示通用服务地址的无效 URL。

    YAML 资源和 CLI 命令输出中会显示正确的 URL。

  • 如果您在 OpenShift Serverless 中使用 ping 源,在卸载和删除所有其他 Knative Eventing 组件后,pingsource-jobrunner Deployment 资源不会被删除。
  • 如果在删除接收器绑定前,删除了它连接到的接收器,SinkBinding 对象删除可能会挂起。

    作为临时解决方案,您可以编辑 SinkBinding 对象并删除导致挂起的终结器:

      finalizers:
       - sinkbindings.sources.knative.dev
  • OpenShift Serverless 1.8.0 中更改了接收器绑定行为,这会破坏向后兼容性。

    要使用接收器绑定,集群管理员现在必须将 SinkBinding 对象中配置的命名空间标记为 bindings.knative.dev/include:"true"

    SinkBinding 对象中配置的资源还必须标记为 bindings.knative.dev/include:"true",但此任务可由任何 OpenShift Serverless 用户完成。

    1. 作为集群管理员,您可以输入以下命令标记命名空间:

      $ oc label namespace <namespace> bindings.knative.dev/include=true
    2. 用户必须手动在资源中添加 bindings.knative.dev/include=true 标签。

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

        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"

1.5. Red Hat OpenShift Serverless 1.7.2 发行注记

此 OpenShift Serverless 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

1.5.1. 修复的问题

  • 在以前的 OpenShift Serverless 版本中,KnativeServing 自定义资源显示 Ready 的状态,即使 Kourier 没有部署。这个问题已在 OpenShift Serverless 1.7.2 中解决。

1.6. Red Hat OpenShift Serverless 1.7.1 发行注记

1.6.1. 新功能

  • OpenShift Serverless 现在使用 Knative Serving 0.13.3。
  • OpenShift Serverless 现在使用 Knative Serving Operator 0.13.3。
  • OpenShift Serverless 现在使用 Knative kn CLI 0.13.2。
  • OpenShift Serverless 现在使用 Knative Eventing 0.13.0。
  • OpenShift Serverless 现在使用 Knative Serving Operator 0.13.3。

1.6.2. 修复的问题

  • 在 OpenShift Serverless 1.7.0 中,当不需要时会持续协调路由。这个问题已在 OpenShift Serverless 1.7.1 中解决。

1.7. Red Hat OpenShift Serverless 1.7.0 发行注记

1.7.1. 新功能

  • OpenShift Serverless 1.7.0 包括在 OpenShift Container Platform 4.3 及更新的版本中。在以前的版本中,OpenShift Serverless 是一个技术预览。
  • OpenShift Serverless 现在使用 Knative Serving 0.13.2。
  • OpenShift Serverless 现在使用 Knative Serving Operator 0.13.2。
  • OpenShift Serverless 现在使用 Knative kn CLI 0.13.2。
  • Knative kn CLI 下载现在支持断开连接或受限的网络安装。
  • 现在,Knative kn CLI 库由红帽签名。
  • Knative Eventing 现在作为技术预览用于 OpenShift Serverless。OpenShift Serverless 现在使用 Knative Eventing 0.13.2。
重要

升级到最新的 Serverless 版本前,您必须删除社区版本的 Knative Eventing Operator。安装 Knative Eventing Operator 后,您将无法安装 OpenShift Serverless 1.7.0 中包含的最新 Knative Eventing 技术预览版本。

  • 现在在默认情况下,autoscaler-hpacontrolleractivatorkourier-controlkourier-gateway 组件都启用了高可用性功能(HA)。

    如果您已经安装了 OpenShift Serverless 的早期版本,在更新 KnativeServing 自定义资源(CR)后,部署将默认为使用 KnativeServing.spec.high-availability.replicas = 2 的 HA 配置。

    您可以参照配置高可用性组件文档中的步骤来在这些组件中禁用 HA。

  • OpenShift Serverless 现在支持 OpenShift Container Platform 的集群范围代理中的 trustedCA 设置,并且与 OpenShift Container Platform 的代理设置完全兼容。
  • OpenShift Serverless 现在支持使用为 OpenShift Container Platform 路由注册的通配符证书的 HTTPS。如需有关 Knative Serving 上的 HTTP 和 HTTPS 的更多信息,请参阅有关验证无服务器应用程序部署的文档。

1.7.2. 修复的问题

  • 在以前的版本中,在没有指定 API 组的情况下请求 KnativeServing CR,例如,使用 oc get knativeserving -n knative-serving 命令有时会导致错误。这个问题已在 OpenShift Serverless 1.7.0 中解决。
  • 在以前的版本中,当因为服务 CA 证书轮转而生成新的服务 CA 证书时,Knative Serving 控制器不会被通知。服务 CA 证书轮转后创建的新修订版本会失败并带有以下错误:

    Revision "foo-1" failed with message: Unable to fetch image "image-registry.openshift-image-registry.svc:5000/eap/eap-app": failed to resolve image to digest: failed to fetch image information: Get https://image-registry.openshift-image-registry.svc:5000/v2/: x509: certificate signed by unknown authority.

    OpenShift Serverless Operator 现在会在生成新服务 CA 证书时重启 Knative Serving 控制器,以确保控制器始终配置为使用当前服务 CA 证书。如需更多信息,请参阅 OpenShift Container Platform 文档中的身份验证部分的使用服务证书来确保服务流量安全的内容。

1.7.3. 已知问题

  • 当从 OpenShift Serverless 1.6.0 升级到 1.7.0 时,对 HTTPS 的支持需要更改路由格式。OpenShift Serverless 1.6.0 所创建的 Knative 服务无法通过旧格式 URL 访问。升级 OpenShift Serverless 后,您必须为每个服务获得新的 URL。如需更多信息,请参阅有关 升级 OpenShift Serverless的文档。
  • 如果您在 Azure 集群上使用 Knative Eventing,imc-dispatcher pod 可能无法启动。这是因为 pod 的默认 resources 设置。作为临时解决方案,您可以删除 resources 设置。
  • 如果您在集群中有 1000 个 Knative 服务,然后执行 Knative Serving 的重新安装或升级,则在 KnativeServing CR 成为 Ready 后创建第一个新服务会有一个延迟。

    在创建新服务前,3scale-kourier-control 控制器会整合所有之前的 Knative 服务,这使新服务在变为 Ready 状态之前,会有大约 800 秒的时间处于 IngressNotConfiguredUnknown 状态。

1.8. 其他资源

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 版本指定 OpenShift Serverless 镜像和镜像标签。

流程

  • 使用 oc adm must-gather 命令收集数据:

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

    示例命令

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

第 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 支持的功能、配置和集成(当前和过去的版本)包括在 支持的配置页面中

重要

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

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

3.3. 后续步骤

第 4 章 安装 OpenShift Serverless

4.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。

4.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

4.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。

4.1.3. 使用机器集扩展集群

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

4.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

    OpenShift Serverless Operator information
  4. Install Operator 页面中:

    Create Operator Subscription 页
    1. Installation ModeAll namespaces on the cluster (default)。选择该项会将 Operator 安装至默认openshift-operators 命名空间,以便供集群中的所有命名空间监视和使用。
    2. Installed Namespacesopenshift-operators
    3. 选择 4.5 频道作为 更新频道4.5 频道将启用 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

Installed Operators 页

如果没有:

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

其他资源

  • 如需了解更多与安装 Operators 相关的信息,请参阅 OpenShift Container Platform 文档中有关向集群中添加 Operator 的内容。

4.1.5. 后续步骤

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

4.2. 安装 Knative Serving

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

本指南提供有关使用默认设置安装 Knative Serving 的信息。但是,您可以在 KnativeServing 自定义资源定义中配置更高级的设置。

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

4.2.1. 创建 knative-serving 命名空间

要创建 knative-serving 命名空间,您必须创建一个 knative-serving 项目。

重要

在安装 Knative Serving 之前,您必须先完成这个步骤。

如果在 Knative Serving 安装期间创建的 KnativeServing 对象没有在 knative-serving 命名空间中创建,它将会被忽略。

先决条件

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

4.2.1.1. 使用 web 控制台创建 knative-serving 命名空间

流程

  1. 在 OpenShift Container Platform web 控制台中,导航至 AdministrationNamespaces 页面。

    Namespaces 页:
  2. 输入 knative-serving 作为项目的 Name。其他字段都是可选的。

    创建 `knative-eventing` 命名空间
  3. 点击 Create

4.2.1.2. 使用 CLI 创建 knative-serving 命名空间

流程

  1. 使用以下命令创建 knative-serving 命名空间:

    $ oc create namespace knative-serving

4.2.2. 先决条件

  • 一个具有集群管理员权限的 OpenShift Container Platform 账户。
  • 已安装 OpenShift Serverless Operator。
  • 创建 knative-serving 命名空间。

4.2.3. 使用 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,请等待几分钟,然后在确认已创建资源后再重新检查。

4.2.4. 使用 YAML 安装 Knative Serving

流程

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

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
        name: knative-serving
        namespace: knative-serving
  3. 应用 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

4.2.5. 后续步骤

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

4.3. 安装 Knative Eventing

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

重要

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

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

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

4.3.1. 创建 knative-serving 命名空间

在创建 knative-Eventing 命名空间时,还将创建一个 knative-Eventing 项目。

重要

在安装 Knative Eventing 之前,您必须先完成这个步骤。

如果在 Knative Eventing 安装期间创建的 KnativeEventing 对象没有在 knative-eventing 命名空间中创建,它将会被忽略。

先决条件

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

4.3.1.1. 使用 web 控制台创建 knative-eventing 命名空间

流程

  1. 在 OpenShift Container Platform web 控制台中,导航至 AdministrationNamespaces 页面。
  2. Create Namespace

    Namespaces 页:
  3. 输入 knative-eventing 作为项目的 Name。其他字段都是可选的。

    创建 `knative-eventing` 命名空间
  4. 点击 Create

4.3.1.2. 使用 CLI 创建 knative-eventing 命名空间

流程

  1. 使用以下命令创建 knative-eventing 命名空间:

    $ oc create namespace knative-eventing

4.3.2. 先决条件

  • 一个具有集群管理员权限的 OpenShift Container Platform 账户。
  • 已安装 OpenShift Serverless Operator。
  • 创建 knative-eventing 命名空间。

4.3.3. 使用 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,请等待几分钟,然后在确认已创建资源后再重新检查。

4.3.4. 使用 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

4.3.5. 后续步骤

  • 安装 Knative CLI 在 Knative Eventing 中使用 kn 命令。例如: kn source 命令。请参阅有关安装 Knative CLI (kn) 的文档。

4.4. 高级安装配置选项

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

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

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

重要

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

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

4.4.1.1. 控制器自定义证书

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

要启用标签到摘要的解析功能,Knative Serving 控制器需要可以访问容器 registry。

重要

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

以下示例会触发 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: certs
    type: ConfigMap

以下示例在 knative-serving 命名空间中的名为 certs 的配置映射中的证书。

支持的类型为 ConfigMapSecret

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

默认 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

4.4.1.2. 高可用性

如果未指定副本数,则高可用性(HA)默认为每个控制器有 2 个副本。

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

YAML 示例

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

4.4.2. 其他资源

4.5. 升级 OpenShift Serverless

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

重要

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

4.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.5 并点 Save
  6. 等待 knative-serving 命名空间中的所有 Pod 都已被升级,KnativeServing 自定义资源(CR)报告了最新的 Knative Serving 版本。

验证

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

  1. 检查 pod 的状态:

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

    以上命令应该返回 True 状态。

  2. 检查 KnativeServing CR 的版本:

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

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

4.6. 删除 OpenShift Serverless

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

注意

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

4.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

4.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

4.6.3. 删除 OpenShift Serverless Operator

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

4.6.4. 删除 OpenShift Serverless CRD

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

重要

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

先决条件

  • 您已卸载了 Knative Serving 和 Knative Eventing,并删除了 OpenShift Serverless Operator。

流程

  • 删除 OpenShift Serverless CRD:

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

4.7. 安装 Knative CLI(kn

注意

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

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

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

4.7.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.7.2. 使用 RPM 为 Linux 安装 kn CLI

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

流程

  • 使用以下命令来安装 kn
# subscription-manager register
# subscription-manager refresh
# subscription-manager attach --pool=<pool_id> 1
# subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-x86_64-rpms"
# yum install openshift-serverless-clients
1
活跃的 OpenShift Container Platform 订阅的池 ID

4.7.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.7.4. 为 macOS 安装 kn CLI

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

流程

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

    $ echo $PATH

4.7.5. 为 Windows 安装 kn CLI

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

流程

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

    C:\> path

第 5 章 架构

5.1. Knative Serving 架构

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

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

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

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

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

5.1.1. Knative Serving CRDs

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

5.2. Knative Eventing 架构

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

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

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

如果目标 sink 不可用,则会缓冲事件。

Knative Eventing 支持以下场景:

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

5.2.1. 事件 sink

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

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

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

6.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 文件。

6.2. 使用 OpenShift Container Platform web 控制台创建无服务器应用程序

您可以使用 OpenShift Container Platform web 控制台中的 DeveloperAdministrator 视角创建无服务器应用程序。

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

先决条件

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

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

流程

  1. 导航到 ServerlessServices 页面。

    点 Services 页
  2. Create Service
  3. 手动输入 YAML 或 JSON 定义,或者将文件拖放到编辑器中。

    文本编辑器
  4. 点击 Create

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

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

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

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

先决条件

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

流程

  1. 输入以下命令来创建 Knative 服务:

    $ kn service create <service_name> --image <image> --env <key=value>
    $ kn service create hello --image docker.io/openshift/hello-openshift --env RESPONSE="Hello Serverless!"
    Creating service 'hello' in namespace 'default':
    
      0.271s The Route is still working to reflect the latest desired specification.
      0.580s Configuration "hello" is waiting for a Revision to become ready.
      3.857s ...
      3.861s Ingress has not yet been reconciled.
      4.270s Ready to serve.
    
    Service 'hello' created with latest revision 'hello-bxshg-1' and URL:
    http://hello-default.apps-crc.testing

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

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

流程

  1. 创建 YAML 文件,然后将以下示例复制到文件中:

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

    $ oc apply -f <filename>

创建 Service 并部署应用程序后,Knative 会为应用程序的这个版本创建一个不可变的修订版本。

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

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

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

注意

OpenShift Serverless 支持 HTTP 和 HTTPS URL,但 oc get ksvc <service_name> 的输出始终使用 http:// 格式打印 URL。

流程

  1. 使用以下命令找到应用程序的 URL。

    $ oc get ksvc <service_name>

    输出示例

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

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

    HTTP 请求示例

    $ curl http://hello-default.example.com

    HTTPS 请求示例

    $ curl https://hello-default.example.com

    输出示例

    Hello Serverless!

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

    重要

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

    示例命令

    $ curl https://hello-default.example.com --insecure

    输出示例

    Hello Serverless!

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

    示例命令

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

    输出示例

    Hello Serverless!

6.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)附加到两个主机中。

第 7 章 OpenShift Serverless 中的高可用性

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

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

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

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

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

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

先决条件

  • 一个具有集群管理员权限的 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

第 8 章 使用 Jaeger 追踪请求

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

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

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

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

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

8.1. 配置 Jaeger 用于 OpenShift Serverless

先决条件

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

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

流程

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

    Jaeger 自定义资源 YAML

    apiVersion: jaegertracing.io/v1
    kind: Jaeger
    metadata:
      name: jaeger
      namespace: default

  2. 通过编辑 KnativeServing 资源并添加用于追踪的 YAML 配置来启用 Knative Serving 的追踪。

    追踪 YAML 示例

    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. 在浏览器中使用端点地址来查看控制台。

第 9 章 Knative Serving

9.1. 使用 kn 完成 Serving 任务

Knative CLI(kn)会扩展 ockubectl 工具的功能,以启用与 OpenShift Container Platform 上的 Knative 组件交互。kn 允许开发人员在不直接编辑 YAML 文件的情况下部署和管理应用程序。

9.1.1. 使用 kn 的基本工作流

以下基本流程部署了一个简单的 hello 服务,它会读环境变量 RESPONSE 并打印它的输出。

您可以使用本指南作为在服务中执行创建、读取、更新和删除(CRUD)操作的参考。

流程

  1. 通过一个镜像,在 default 命名空间内创建一个服务:

    $ kn service create hello --image docker.io/openshift/hello-openshift --env RESPONSE="Hello Serverless!"
    Creating service 'hello' in namespace 'default':
    
      0.085s The Route is still working to reflect the latest desired specification.
      0.101s Configuration "hello" is waiting for a Revision to become ready.
     11.590s ...
     11.650s Ingress has not yet been reconciled.
     11.726s Ready to serve.
    
    Service 'hello' created with latest revision 'hello-gsdks-1' and URL:
    http://hello-default.apps-crc.testing
  2. 列出服务:

    $ kn service list
    NAME    URL                                     LATEST          AGE     CONDITIONS   READY   REASON
    hello   http://hello-default.apps-crc.testing   hello-gsdks-1   8m35s   3 OK / 3     True
  3. 使用 curl 服务端点命令检查该服务是否正在工作:

    $ curl http://hello-default.apps-crc.testing
    Hello Serverless!
  4. 更新服务:

    $ kn service update hello --env RESPONSE="Hello OpenShift!"
    Updating Service 'hello' in namespace 'default':
    
     10.136s Traffic is not yet migrated to the latest revision.
     10.175s Ingress has not yet been reconciled.
     10.348s Ready to serve.
    
    Service 'hello' updated with latest revision 'hello-dghll-2' and URL:
    http://hello-default.apps-crc.testing

    该服务的环境变量 RESPONSE 现在设置为 "Hello OpenShift!"。

  5. 描述该服务。

    $ kn service describe hello
    Name:       hello
    Namespace:  default
    Age:        13m
    URL:        http://hello-default.apps-crc.testing
    
    Revisions:
      100%  @latest (hello-dghll-2) [2] (1m)
            Image:  docker.io/openshift/hello-openshift (pinned to 5ea96b)
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                   1m
      ++ ConfigurationsReady     1m
      ++ RoutesReady             1m
  6. 删除服务:

    $ kn service delete hello
    Service 'hello' successfully deleted in namespace 'default'.
  7. 使用 list 命令来验证 hello 服务是否已被删除。

    $ kn service list hello
    No services found.

9.1.2. 使用 kn 自动扩展工作流

您可使用 kn 修改 Knative 服务来访问自动扩展功能,而无需直接编辑 YAML 文件。

使用带有适当标志的 service createservice update 命令来配置自动扩展行为。

标志描述

--concurrency-limit int

单个副本处理的并发请求的硬性限制。

--concurrency-target int

根据传入请求的并发数量建议扩展时间。默认为 --concurrency-limit

--max-scale int

最大副本数。

--min-scale int

最小副本数。

9.1.3. 使用 kn 进行流量分割

kn 可帮助您控制哪些修订版本可获取您的 Knative 服务上的路由流量。

Knative 服务支持流量映射,可将服务的修订版本映射到流量的分配部分。它提供了为特定修订版本创建唯一 URL 的选项,且能够为最新修订版本分配流量。

每次更新服务配置时,都会创建一个新修订版本,服务路由默认会将所有流量指向最新可用的修订版本。

您可通过定义哪个修订版本可获得部分流量来更改此行为。

流程

  • 使用带有 --traffic 标志的 kn service update 命令来更新流量。
注意

--traffic RevisionName=Percent 使用以下语法:

  • --traffic 标志需要用等号 (=) 分隔的两个值。
  • RevisionName 字符串表示修订版本的名称。
  • Percent 整数表示分配给修订版本的流量部分。
  • 将标识符 @latest 用于 RevisionName,以表示服务的最新的可用修订版本。此标识符仅可与 --traffic 标志一起使用一次。
  • 如果 service update 命令更新该服务的配置值和流量标志,则 @latest 引用将指向更新应用到的所创建修订版本。
  • --traffic 标志可多次指定,且仅在所有标志的 Percent 值总和达到 100 时才有效。
注意

例如,要在放置所有流量前将 10% 的流量路由至您的新修订版本,请使用以下命令:

$ kn service update svc --traffic @latest=10 --traffic svc-vwxyz=90

9.1.3.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 标志可为同一修订版本分配不同标签。

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

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

注意

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

流程

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

    $ kn service update svc --untag candidate
注意

--untag Tag 使用以下语法:

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

9.1.3.3. 流量标志操作优先级

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

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

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

9.1.3.4. 流量分割标志

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

下表显示流量分割标志、值格式和标志执行的操作汇总。“重复”列表示在 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

9.2. 配置 Knative Serving 自动扩展

OpenShift Serverless 通过在 OpenShift Container Platform 集群中启用 Knative Serving 自动扩展系统来提供 Pod 自动扩展功能,包括将不活跃 Pod 缩减为零。

要针对 Knative Serving 启用自动扩展,您必须在修订模板中配置并发和扩展范围。

注意

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

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

通过在修订模板中添加 target 注解或 containerConcurrency spec,可指定应用程序(修订容器)的每个实例应处理的并发请求数。

修订模板中使用的 target 注解

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

修订模板中使用的 containerConcurrency spec

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

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

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

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

autoscaling.knative.dev/target: 50

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

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

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

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

9.2.2. 配置扩展范围 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 回收资源。

9.3. 使用 OpenShift Serverless 的集群日志记录

9.3.1. 关于部署集群日志记录

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

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

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

9.3.2. 关于部署和配置集群日志记录

OpenShift Container Platform 集群日志记录已设计为可搭配默认配置使用,该配置针对中小型 OpenShift Container Platform 集群进行了调优。

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

如果要使用默认集群日志记录安装,可直接使用示例 CR。

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

9.3.2.1. 配置和调优集群日志记录

您可以通过修改 openshift-logging 项目中部署的 ClusterLogging 自定义资源来配置集群日志记录环境。

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

内存和 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 * * *"

9.3.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: {}
      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

9.3.3. 使用集群日志来查找 Knative Serving 组件的日志

流程

  1. 要访问 Kibana UI(Elasticsearch 的可视化工具),请使用以下命令获取 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 默认使用结构化日志记录。您可以通过自定义集群日志记录 Fluentd 设置来启用这些日志的解析。这可使日志更易搜索,并且能够在日志级别进行过滤以快速识别问题。

9.3.4. 使用集群日志来查找通过 Knative Serving 部署的服务的日志

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

流程

  1. 使用以下命令查找 Kibana 的 URL:

    $ oc -n cluster-logging get route kibana`
  2. 在浏览器中输入 URL 以打开 Kibana UI。
  3. 确保将索引设置为 .all。如果索引未设置为 .all,则只会列出 OpenShift 系统日志。
  4. 通过使用服务部署到的 Kubernetes 命名空间来过滤日志。添加过滤条件以识别服务本身:kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{SERVICE_NAME}

    注意

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

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

    注意

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

9.4. 在修订版本间分割流量

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

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

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

流程

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

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

    图 9.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 视图中的两个修订版本。

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

      odc 无服务器修订

第 10 章 事件工作流

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

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

代理事件交付概述

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

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

10.1.1. 创建代理

OpenShift Serverless 提供了一个 default Knative 代理,它可以通过 Knative CLI 创建。如果您是集群管理员,还可以通过将 eventing.knative.dev/injection=enabled 标签添加到命名空间来创建 default 代理。如果您是开发人员,则可以通过将 eventing.knative.dev/injection: enabled 注解添加到触发器进行创建。

重要

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

10.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 视图中查看代理

10.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 视图中查看代理

10.1.1.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 视图中查看代理

10.1.2. 管理代理

kn CLI 提供了用于列出、描述、更新和删除代理的命令。集群管理员也可以永久删除使用注入创建的代理。

10.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

10.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

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

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

流程

  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

10.1.3. 使用触发器过滤事件

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

先决条件

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

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

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

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

10.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 视图中的触发器

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

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

先决条件

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

流程

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

    删除触发器

10.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 属性,您可以从代理过滤事件,这样订阅者才会根据您定义的标准接收一小部分事件。

10.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
10.1.3.4.1. 使用 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

10.1.3.4.2. 使用触发器过滤事件

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

$ 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
10.1.3.4.3. 使用 kn 更新触发器

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

流程

  • 更新触发器:

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

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

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

      $ kn trigger update <trigger_name> --sink ksvc:my-event-sink
10.1.3.4.4. 使用 kn 删除触发器

流程

  • 删除触发器:

    $ kn trigger delete <trigger_name>

验证

  1. 列出现有触发器:

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

    输出示例

    No triggers found.

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

事件可以通过使用频道和订阅发送事件从源发送到 sink。

频道工作流概述

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

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

频道实例的默认配置在 default-ch-webhook 配置映射中定义。开发人员可以通过实例化受支持的 Channel 对象直接创建他们自己的频道。

10.2.1. 支持的频道类型

目前,作为 Knative Eventing 技术预览的一部分,OpenShift Serverless 只支持用于开发的 InMemoryChannel kind 频道。

以下是 InMemoryChannel 频道的限制:

  • 没有可用的事件持久性。如果 Pod 停机,则 Pod 上的事件将会丢失。
  • InMemoryChannel 频道没有实现事件排序,因此同时接收到的两个事件可能会以任何顺序传送给订阅者。
  • 如果订阅者拒绝某个事件,就不会再重新发送尝试。如果存在,被拒绝的事件会被发送到一个 deadLetterSink 对象,或被丢弃。

10.2.1.1. 使用默认开发频道配置

安装 Knative Eventing 时,会在 knative-eventing 命名空间中自动创建以下 default-ch-webhook 配置映射:

apiVersion: v1
kind: ConfigMap
metadata:
  name: default-ch-webhook
  namespace: knative-eventing
data:
  default-ch-config: |
    clusterDefault:
      apiVersion: messaging.knative.dev/v1
      kind: InMemoryChannel
    namespaceDefaults:
      some-namespace:
        apiVersion: messaging.knative.dev/v1
        kind: InMemoryChannel

此配置映射可以指定集群范围的默认频道实施,也可以指定特定于命名空间的默认频道实施。配置特定于命名空间的默认设置会覆盖任何集群范围的设置。

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

具有 spec.channelTemplate 属性的 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 频道。

通用频道充当将订阅复制到 InMemoryChannel 频道的代理,并设置它的状态来反映支持的 InMemoryChannel 频道的状态。

因为本示例中的频道是在 default 命名空间中创建的,所以频道会使用集群默认值,即 InMemoryChannel。

10.2.2. 创建开发频道

流程

您可以通过完成以下步骤来使用集群默认配置创建频道。

  1. 创建 Channel 对象。

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

      apiVersion: messaging.knative.dev/v1
      kind: Channel
      metadata:
        name: example-channel
        namespace: default
    2. 输入以下内容应用 YAML 文件:

      $ oc apply -f <filename>

10.2.3. 创建订阅

您可以创建一个 Subscription 对象来连接频道到 sink。在以下流程中,sink 示例是名为 error-handler 的 Knative 服务。

流程

  1. 创建 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。
  2. 应用 YAML 文件:

    $ oc apply -f <FILENAME>

第 11 章 事件源

11.1. 事件源入门

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

11.1.1. 创建事件源

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

API 服务器源
通过创建 APIServerSource 对象,将接收器连接到 Kubernetes API 服务器。
Ping 源
定期使用带有恒定有效负载的 ping 事件。ping 源可以用作计时器,并作为 PingSource 对象创建。

也支持接收器绑定,它允许您将核心 Kubernetes 资源(如 DeploymentJobStatefulSet )与接收器进行连接。

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

11.1.2. 其他资源

11.2. 使用 Knative CLI 列出事件源和事件源类型

您可以使用 kn CLI 列出并管理可以与 Knative Eventing 搭配使用的可用事件源或事件源类型。

目前,kn 支持管理以下事件源类型:

API 服务器源
通过创建 APIServerSource 对象,将接收器连接到 Kubernetes API 服务器。
Ping 源
定期使用带有恒定有效负载的 ping 事件。ping 源可以用作计时器,并作为 PingSource 对象创建。

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

您可以使用以下命令列出终端中的可用事件源类型:

$ 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

也可以以 YAML 格式列出可用事件源类型:

$ kn source list-types -o yaml

11.2.2. 使用 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

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

$ kn source list --type PingSource

输出示例

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

11.2.3. 后续步骤

11.3. 使用 API 服务器源

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

11.3.1. 先决条件

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

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

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

11.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

11.3.3. 使用 Developer 视角创建 ApiServerSource 事件源

流程

  1. 导航到 Add 页面并选择 Event Source
  2. Event Sources 页面中,在 Type 部分选择 ApiServerSource

    创建 ApiServerSource
  3. 配置 ApiServerSource 设置:

    1. 输入 v1 作为 APIVERSIONEvent 作为 KIND
    2. 为您创建的服务帐户选择 Service Account Name

      选择服务帐户名称和 Sink
    3. SinkKnative Service 的下拉菜单中选择目标 Knative 服务。
  4. 点击 Create

验证

  1. 创建 ApiServerSource 后,您会在 Topology 视图中看到它连接到被 sinked 的服务。

    ApiServerSource Topology view

11.3.4. 删除 ApiServerSource

流程

  1. 导航到 Topology 视图。
  2. 右键点击 ApiServerSource 并选择 Delete ApiServerSource

    删除 ApiServerSource

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

本节介绍了使用 kn 命令创建 ApiServerSource 对象所需的步骤。

先决条件

  • 在集群中安装了 Knative Serving 和 Eventing。
  • 您已在安装 API 服务器源的同一命名空间中创建了 default 代理。
  • 已安装 kn CLI。

流程

  1. ApiServerSource 对象创建服务帐户、角色和角色绑定。

    您可以创建名为 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 文件。

    创建服务帐户、角色绑定和集群绑定:

    $ oc apply -f authentication.yaml
  2. 创建使用代理作为事件接收器的 ApiServerSource 对象:

    $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
  3. 创建 Knative 服务,在日志中转储传入的信息:

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

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

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

    $ kn source apiserver describe testevents

    输出示例

    Name:                testevents
    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",
        ...
      }

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

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

先决条件

  • 已安装了 kn CLI。

流程

  1. 删除触发器:

    $ kn trigger delete <trigger_name>
  2. 删除服务:

    $ kn service delete <service_name>
  3. 删除 API 服务器源:

    $ kn source apiserver delete <source_name>
  4. 删除服务帐户、集群角色和集群绑定:
$ oc delete -f authentication.yaml

11.3.7. 使用 YAML 文件创建 API 服务器源

本指南描述了使用 YAML 文件创建 ApiServerSource 对象所需的步骤。

先决条件

  • 在集群中安装了 Knative Serving 和 Eventing。
  • 您已在与 ApiServerSource 对象中定义的相同的命名空间中创建 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. 要创建 ApiServerSource 对象,请创建一个名为 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",
        ...
      }

11.3.8. 删除 API 服务器源

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

流程

  1. 删除触发器:

    $ oc delete -f trigger.yaml
  2. 删除服务:

    $ oc delete -f service.yaml
  3. 删除 API 服务器源:

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

    $ oc delete -f authentication.yaml

11.4. 使用 ping 源

ping 源用于定期向事件消费者发送带有恒定有效负载的 ping 事件。ping 源可以用来调度发送事件,类似于计时器,如下例所示:

ping 源示例

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 服务。

11.4.1. 使用 Knative CLI 创建 ping 源

以下小节介绍了如何使用 kn CLI 创建、验证和移除基本 PingSource 对象。

先决条件

  • 已安装 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 事件,请在与事件消费者相同的命名空间中创建一个 PingSource 对象:

    $ 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。本指南中演示的示例创建了一个 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: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9
      time: 2020-04-07T16:16:00.000601161Z
      datacontenttype: application/json
    Data,
      {
        "message": "Hello world!"
      }

11.4.1.1. 删除 ping 源

  1. 删除 PingSource 对象:

    $ kn delete pingsources.sources.knative.dev test-ping-source
  2. 删除 event-display 服务:

    $ kn delete service.serving.knative.dev event-display

11.4.2. 使用 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. 应用 service.yaml 文件:

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

    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-source.yaml 文件:

      $ 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!"
      }

11.4.2.1. 删除 PingSource

  1. 输入以下命令删除该服务:

    $ oc delete --filename service.yaml
  2. 输入以下命令来删除 PingSource 对象:

    $ oc delete --filename ping-source.yaml

11.5. 使用接收器绑定

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

重要

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

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

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

本指南描述了使用 kn CLI 创建、管理和删除接收器绑定实例所需的步骤。

先决条件

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

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

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

重要

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

$ 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. 创建一个 SinkBinding 对象,将事件定向到服务:

    $ 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 对象中,请将以下行添加到作业资源 YAML 定义中:

        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
    2. 创建 heartbeats-cronjob.yaml 文件后,应用该文件:

      $ oc apply --filename 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": ""
      }

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

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

先决条件

  • 已安装 Knative Serving 和 Eventing。
注意

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

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

重要

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

$ 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. 创建一个 SinkBinding 对象,将事件定向到该服务。

    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 标签。

      例如,要将此标签添加到 cron 作业实例中,请将以下行添加到 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
    $ 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 章 网络

12.1. 在 OpenShift Serverless 中使用 Service Mesh

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

流程

  1. 以成员身份为 ServiceMeshMemberRoll 添加 default 命名空间:

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      members:
        - default
    重要

    不支持在系统命名空间中向 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. 将以下 NetworkPolicy 资源复制到 YAML 文件中:

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

      $ oc apply -f <filename>

12.1.1. 为 Knative 服务启用 sidecar 注入

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

流程

  1. Service 资源添加 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. 应用 Service 资源 YAML 文件:

    $ oc apply -f <filename>

12.1.2. 其他资源

12.2. 在 Service Mesh 和 OpenShift Serverless 中使用 JSON Web 令牌身份验证

您可以通过在无服务器应用程序命名空间中创建策略来为 Knative 服务启用 JSON Web Token(JWT)身份验证,该策略只允许具有有效 JWT 的请求。

先决条件

重要

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

流程

  1. 将以下 Policy 资源复制到 YAML 文件中:

    重要

    路径 /metrics/healthz 必须包含在 excludePaths 中,因为它们是从 knative-serving 命名空间中的系统 pod 访问的。

    apiVersion: authentication.istio.io/v1alpha1
    kind: Policy
    metadata:
      name: default
    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
            - prefix: /healthz
      principalBinding: USE_ORIGIN
  2. 应用 Policy 资源 YAML 文件:

    $ 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!

12.2.1. 其他资源

12.3. 在 Service Mesh 中使用自定义域进行 Knative 服务

默认情况下,Knative 服务具有固定的域格式:

 <application_name>-<namespace>.<openshift_cluster_domain>

您可以通过将服务配置为私有服务并创建所需的 Service Mesh 资源来自定义 Knative 服务域。

先决条件

12.3.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

12.3.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>

12.3.3. 使用自定义域访问服务

流程

  1. 使用 curl 请求中的 Host 标头访问自定义域。例如:

    $ curl -H "Host: custom-ksvc-domain.example.com" http://<ip_address>

    这里的 <ip_address> 是 OpenShift Container Platform 入口路由器公开的 IP 地址。

    输出示例

    Hello OpenShift!

12.3.4. 其他资源

第 13 章 使用 OpenShift Serverless 的 metering

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

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

13.1. 安装 metering

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

13.2. Knative making metering 的数据源

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

13.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!=""}
          )

13.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!=""}
          )

13.2.3. 为 Knative Serving metering 应用数据源

流程

  • ReportDataSources 资源作为 YAML 文件应用:

    $ oc apply -f <datasource_name>.yaml

    示例命令

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

13.3. 对 Knative Serving metering 的查询

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

13.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']

13.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']

13.3.3. 对 Knative Serving metering 应用查询

  • 将查询作为 YAML 文件应用:

    $ oc apply -f <query_name>.yaml

    示例命令

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

13.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

13.4.1. 运行 metering 报告

  1. 通过以 YAML 文件的形式应用报告来运行报告:

    $ oc apply -f <report_name>.yaml
  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

第 14 章 集成

14.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

14.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.