无服务器应用程序

OpenShift Container Platform 4.4

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.7.2 发行注记

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

1.1.1. 修复的问题

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

1.2. Red Hat OpenShift Serverless 1.7.1 发行注记

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

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

1.3. Red Hat OpenShift Serverless 1.7.0 发行注记

1.3.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 的 spec 的 HA 配置。

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

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

1.3.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.3.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.4. Red Hat OpenShift Serverless 技术预览 1.6.0 发行注记

1.4.1. 新功能

  • OpenShift Serverless 1.6.0 包括在 OpenShift Container Platform 4.3 及更新的版本中。
  • OpenShift Serverless 现在使用 Knative Serving 0.13.1。
  • OpenShift Serverless 现在使用 Knative kn CLI 0.13.1。
  • OpenShift Serverless 现在使用 Knative Serving Operator 0.13.1。
  • Service.knative.dev API 组现已完全弃用,由 operator.knative.dev API 组替代。

    您必须完成 OpenShift Serverless 1.4.0 发行注记中描述的步骤,将 service.knative.dev API 组替换为 operator.knative.dev API 组,然后才能升级到 OpenShift Serverless 的最新版本。

    重要

    这个更改会导致命令没有完全限定的 API 组和 kind,如 oc get KnativeServing,变得不可靠,且并不总是可以正常工作。

    升级到 OpenShift Serverless 1.6.0 后,您必须删除旧的 CRD 来修复这个问题。您可以使用以下命令删除旧的 CRD:

    $ oc delete crd knativeservings.serving.knative.dev
  • web 控制台中新版本的 OpenShift Serverless 订阅更新频道已从 techpreview 更新为 preview-4.3

    重要

    您必须按照升级文档更新您的频道,以使用最新的 OpenShift Serverless 版本。

  • OpenShift Serverless 现在支持使用 HTTP_PROXY
  • OpenShift Serverless 现在支持 HTTPS_PROXY 集群代理设置。

    注意

    这个 HTTP_PROXY 支持不包括使用自定义证书。

  • KnativeServing CRD 现在默认从 Developer Catalog 中隐藏,因此只有具有集群管理员权限的用户才能查看它。
  • KnativeServing control plane 和 data plane 的部分已默认部署为高可用性 (HA) 。
  • Kourier 现在可以主动监视并自动协调更改。
  • OpenShift Serverless 现在支持在 OpenShift Container Platform 上进行每夜构建。

1.4.2. 修复的问题

  • 在以前的版本中,oc explain 命令无法正常工作。OpenShift Serverless 1.6.0 中更新了 KnativeServing CRD 的结构性 schema,oc explain 命令现在可以正常工作。
  • 在以前的版本中,可以创建多个 KnativeServing 自定义资源(CR)。现在,在 OpenShift Serverless 1.6.0 中不会同时有多个 KnativeServing CR。尝试创建多个 KnativeServing CR 现在会导致错误。
  • 在以前的版本中,OpenShift Serverless 与 GCP 上的 OpenShift Container Platform 部署不兼容。这个问题已在 OpenShift Serverless 1.6.0 中解决。
  • 在以前的版本中,如果集群有超过 170 个命名空间,Knative Serving Webhook 会因内存错误而崩溃。这个问题已在 OpenShift Serverless 1.6.0 中解决。
  • 在以前的版本中,OpenShift Serverless 不会自动修复在另一组件更改路由时创建的 OpenShift Container Platform 路由。这个问题已在 OpenShift Serverless 1.6.0 中解决。
  • 在以前的版本中,删除 KnativeServing CR 偶尔会导致系统挂起。这个问题已在 OpenShift Serverless 1.6.0 中解决。
  • 由于 OpenShift Serverless 1.5.0 中出现从 Service Mesh 迁移到 Kourier 的入站迁移,因此系统有时会出现孤立的 VirtualService。在 OpenShift Serverless 1.6.0 中,孤立的 VirtualService 会自动被删除。

1.4.3. 已知问题

  • 在 OpenShift Serverless 1.6.0 中,如果集群管理员按照文档中提供的卸载步骤卸载 OpenShift Serverless,则 Serverless 下拉列表仍可在 OpenShift Container Platform Web 控制台的 Administrator 视角中看到,OpenShift Container Platform Web 控制台的 Developer 视角中仍可看到 Knative Service 资源。虽然您可以使用这个选项创建 Knative 服务,但这些 Knative 服务无法工作。

    为了防止 OpenShift Serverless 在 OpenShift Container Platform web 控制台中可见,集群管理员必须在删除 Knative Serving CR 后从部署中删除额外的 CRD。

    集群管理员可通过以下命令删除这些 CRD:

    $ oc get crd -oname | grep -E '(serving|internal).knative.dev' | xargs oc delete

1.5. Red Hat OpenShift Serverless 技术预览 1.5.0 发行注记

1.5.1. 新功能

  • OpenShift Serverless 1.5.0 包括在 OpenShift Container Platform 4.3 及更新的版本中。
  • OpenShift Serverless 已更新为使用 Knative Serving 0.12.1。
  • OpenShift Serverless 已更新为使用 Knative kn CLI 0.12.0。
  • OpenShift Serverless 已更新为使用 Knative Serving 0.12.1。
  • OpenShift Serverless ingress 实现已更新为使用 Kourier 来代替 Service Mesh。不需要用户干预,因为当 OpenShift Serverless Operator 升级到 1.5.0 时这会自动进行。

1.5.2. 修复的问题

  • 在以前的版本中,OpenShift Container Platform 从零延迟扩展,会在创建 pod 时有大约 10 秒的延迟。这个问题已在 OpenShift Container Platform 4.3.5 程序错误更新中解决。

1.5.3. 已知问题

  • knative-serving 命名空间中删除 KnativeServing.operator.knative.dev 自定义资源定义(CRD)可能会导致删除过程挂起。这是因为在删除 CRD 和 knative-openshift-ingress ingress 删除终结器间有一个竞争条件。

1.6. 其他资源

OpenShift Serverless 基于开源的 Knative 项目。

第 2 章 OpenShift Serverless 支持

2.1. 获取支持

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

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

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

2.2. 为支持收集诊断信息

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

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

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

2.2.1. 关于 must-gather 工具

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

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

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

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

2.2.2. 关于收集 OpenShift Serverless 数据

您可使用 oc adm must-gather CLI 命令来收集有关集群的信息,包括与 OpenShift Serverless 相关的功能和对象:

要使用 must-gather 工具来收集 OpenShift Serverless 数据,您必须指定 OpenShift Serverless 镜像。

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

第 3 章 架构

3.1. Knative Serving 架构

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

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

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

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

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

3.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 可保持部署所需状态。它可在使编程过程和配置配置过程相互分离。修改配置则会创建一个新修订版本。

3.2. Knative Eventing 架构

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

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

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

频道和代理实现通过使用订阅和触发器管理事件到事件接收器(sink)。如果目标 sink 不可用,则会缓冲事件。

Knative Eventing 支持以下场景:

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

3.2.1. 事件 sink

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

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

第 4 章 OpenShift Serverless 入门

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

4.1. OpenShift Serverless 的工作原理

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

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

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

4.2. 支持的配置

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

重要

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

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

4.3. 后续步骤

第 5 章 安装 OpenShift Serverless

5.1. 安装 OpenShift Serverless

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

注意

OpenShift Serverless 支持在受限网络环境中安装。详情请参阅在受限网络中使用 Operator Lifecycle Manager

重要

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

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

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

注意

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

注意

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

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

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

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

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

5.1.3. 使用机器集扩展集群

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

5.1.4. 安装 OpenShift Serverless Operator

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

流程

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

    OpenShift Serverless Operator in the OpenShift Container Platform web console
  3. 查看 Operator 信息并单击 Install

    OpenShift Serverless Operator information
  4. Create Operator Subscription 页面:

    Create Operator Subscription 页
    1. Installation ModeAll namespaces on the cluster (default)。选择该项会将 Operator 安装至默认openshift-operators 命名空间,以便供集群中的所有命名空间监视和使用。
    2. Installed Namespacesopenshift-operators
    3. 选择 4.4 频道作为 更新频道4.4 频道将启用 OpenShift Serverless Operator 最新稳定版本的安装。
    4. 选择 AutomaticManual 批准策略。
  5. 单击 Subscribe,以便该 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 的内容。

5.1.5. 后续步骤

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

5.2. 安装 Knative Serving

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

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

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

5.2.1. 创建 knative-serving 命名空间

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

重要

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

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

先决条件

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

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

流程

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

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

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

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

流程

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

    $ oc create namespace knative-serving

5.2.2. 先决条件

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

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

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

5.2.5. 后续步骤

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

5.3. 安装 Knative Eventing

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

重要

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

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

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

5.3.1. 创建 knative-serving 命名空间

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

重要

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

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

先决条件

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

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

流程

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

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

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

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

流程

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

    $ oc create namespace knative-eventing

5.3.2. 先决条件

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

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

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

5.3.5. 后续步骤

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

5.4. 高级安装配置选项

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

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

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

重要

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

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

5.4.1.1. 控制器自定义证书

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

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

重要

ConfigMap 或 Secret 必须位于与 Knative Serving CustomResourceDefinition(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 的 ConfigMap 中的证书。

支持的类型为 ConfigMapSecret

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

默认 YAML 示例

spec:
  controller-custom-certs:
    name: config-service-ca
    type: ConfigMap

5.4.1.2. 高可用性

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

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

YAML 示例

spec:
  high-availability:
    replicas: 2

5.4.2. 其他资源

5.5. 升级 OpenShift Serverless

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

重要

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

5.5.1. 更新 Knative 服务 URL 格式

当从 OpenShift Serverless 的旧版本升级到 1.7.0 时,对 HTTPS 的支持需要更改路由格式。OpenShift Serverless 1.6.0 或旧版本中创建的 Knative 服务无法通过旧格式 URL 访问。升级 OpenShift Serverless 后,您必须为每个服务获得新的 URL。

有关获得 Knative 服务 URL 的更多信息,请参阅验证无服务器应用程序部署

5.5.2. 升级订阅频道

要升级到 OpenShift Container Platform 4.4 上的 OpenShift Serverless 的最新版本,您必须将频道更新至 4.4

如果要从 OpenShift Serverless 版本 1.5.0 或更早版本升级到 1.7.0,您必须完成以下步骤:

  • 使用 techpreview 频道升级到 OpenShift Serverless version 1.5.0。
  • 升级到 1.5.0 后,使用 preview-4.3 频道升级到 1.6.0。
  • 最后,在升级到 1.6.0 后,选择 4.4 频道升级到最新版本。
重要

更改每个频道后,请等待 knative-serving 命名空间中的 pod 升级完成后,再重新更改频道。

先决条件

  • 已安装了一个 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.4 并点 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 发行注记中查看最新版本。

5.6. 删除 OpenShift Serverless

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

注意

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

5.6.1. 卸载 Knative Serving

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

流程

  1. 要移除 Knative Serving,请使用以下命令:

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

    $ oc delete namespace knative-serving

5.6.2. 卸载 Knative Eventing

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

流程

  1. 要移除 Knative Eventing,请使用以下命令:

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

    $ oc delete namespace knative-eventing

5.6.3. 删除 OpenShift Serverless Operator

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

5.6.4. 删除 OpenShift Serverless CRD

在卸载 OpenShift Serverless 后,Operator 和 API CRD 服务仍保留在集群上。您可以使用以下步骤删除剩余的 CRD。

重要

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

5.6.5. 先决条件

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

流程

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

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

5.7. 安装 Knative CLI(kn

注意

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

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

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

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

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

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

5.7.4. 为 macOS 安装 kn CLI

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

流程

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

    $ echo $PATH

5.7.5. 为 Windows 安装 kn CLI

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

流程

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

    C:\> path

第 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 文件并使用 oc apply 应用它。

流程

  1. 通过复制以下示例来创建 YAML 文件:

    Knative 服务 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!"

    在本例中,YAML 文件名为 hello-service.yaml

  2. 导航到包含 hello-service.yaml 文件的目录,并通过应用 YAML 文件来部署应用程序:

    $ oc apply -f hello-service.yaml

在创建了服务并部署了应用程序后,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 Container Platform 路由不支持 HTTP2,因此不支持需要使用 HTTP2 进行传输的 gRPC。如果您在应用程序中使用这些协议,则必须使用入口(ingress)网关直接调用应用程序。要做到这一点,您必须找到 ingress 网关的公共地址以及应用程序的特定主机。

流程

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

    $ 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 网络。

    以下是在 Golang gRPC 客户端中的一个示例:

    注意

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

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

第 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。
  • 您可以访问 OpenShift Container Platform Web 控制台并已登录。

流程

  1. 在 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. 编辑 CRD 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

先决条件

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

流程

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

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

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

验证步骤

您可以使用 jaeger 路由来访问 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 完成 Knative Serving 任务

Knative kn CLI 会扩展 ockubectl CLI 工具的功能,以集成与 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. 通过列出 hello 服务来验证 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 命令来更新流量。

    例如,在将所有流量放置到新修订版本前,要将 10% 的流量路由到新修订版本:

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

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

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

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 命令的一部分,支持在服务的流量块上进行流量操作。

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

标记操作重复

--traffic

RevisionName=Percent

RevisionName 提供 Percent 的流量

--traffic

Tag=Percent

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

--traffic

@latest=Percent

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

--tag

RevisionName=Tag

RevisionName 提供 Tag

--tag

@latest=Tag

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

--untag

Tag

从修订中删除 Tag

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 字段,可指定应用程序(修订容器)的每个实例应处理的并发请求数。

以下是修订模板中使用的 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 示例:

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 中的 enable-scale-to-zerofalse,则会缩减为 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 负责部署、升级和维护集群日志记录。

您可以通过修改名为 instanceClusterLogging 自定义资源(CR)来配置集群日志记录。CR 定义包括日志记录堆栈的所有组件在内的完整集群日志记录部署,以收集、存储和视觉化日志。Cluster Logging Operator 监控 ClusterLogging 自定义资源并相应地调整日志记录部署。

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

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 集群中的每个数据节点创建 PersistentVolumeClaim
  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "gp2"
          size: "200G"

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

注意

省略 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"
    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 Container Platform 系统日志。
  4. 您可使用 knative-serving 命名空间来过滤日志。在搜索框中输入 kubernetes.namespace_name:knative-serving 以过滤结果。

    注意

    Knative Serving 默认使用结构化日志记录。您可以通过自定义集群日志记录 Fluentd 设置来启用这些日志的解析。这允许在日志级别过滤来快速发现问题。

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

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

流程

  1. 查找 Kibana URL:

    $ oc -n cluster-logging get route kibana
  2. 在浏览器中输入 URL 以打开 Kibana UI。
  3. 确保将索引设置为 .all。如果索引未设置为 .all,则只会列出 OpenShift Container Platform 系统日志。
  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 serverless revisions

第 10 章 Knative Eventing

10.1. 在 Knative Eventing 中使用代理

Knative Eventing 使用 default 代理,除非特别指定。

如果您有集群管理员权限,可以使用命名空间注解自动创建 default 代理。

所有其他用户必须按照本指南中描述的手动过程创建一个代理。

10.1.1. 手动创建代理

要创建代理,您必须为每个命名空间创建一个服务账户,并为该服务帐户指定所需的 RBAC 权限。

先决条件

  • 安装了 Knative Eventing,其中包括 ClusterRole

流程

  1. 创建 ServiceAccount 对象。

    1. 输入以下命令来创建 eventing-broker-ingress 对象:

      $ oc -n <namespace> create serviceaccount eventing-broker-ingress
    2. 输入以下命令来创建 eventing-broker-filter 对象:

      $ oc -n <namespace> create serviceaccount eventing-broker-filter
  2. 授予您创建 RBAC 权限的对象:

    $ oc -n default create rolebinding eventing-broker-ingress \
      --clusterrole=eventing-broker-ingress \
      --serviceaccount=default:eventing-broker-ingress
    $ oc -n default create rolebinding eventing-broker-filter \
      --clusterrole=eventing-broker-filter \
      --serviceaccount=default:eventing-broker-filter
  3. 通过创建并应用包含以下内容的 YAML 文件来创建代理:

    apiVersion: eventing.knative.dev/v1beta1
    kind: Broker
    metadata:
      namespace: default
      name: default 1
    1
    这个示例使用 default名称,但您可以使用其他有效名称替换它。

10.1.2. 使用命名空间注解自动创建代理

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

先决条件

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

流程

  1. 输入以下命令来标注命名空间:

    $ oc label namespace default knative-eventing-injection=enabled 1
    $ oc -n default get broker default
    1
    使用所需命名空间名替换 default

    本例中显示的行将在 default 命名空间内自动创建一个名为 default 的代理。

注意

如果您删除了注解,则不会删除由注解创建的代理。您必须手动删除它们。

10.1.3. 使用命名空间注解删除创建的代理

  1. 从所选命名空间中(在这个示例中,是 default 命名空间)删除注入的代理:

    $ oc -n default delete broker default

10.2. 使用频道

可以 sink 事件从一个事件源到一个 Knative Eventing 频道。频道是定义单一事件转发和持久层的自定义资源 (CR)。事件发送到某个频道后,可使用订阅将这些事件发送到多个 Knative 服务。

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

10.2.1. 支持的频道类型

目前,作为 Knative Eventing 技术预览的一部分,OpenShift Serverless 只支持将 InMemoryChannel 类型频道。

10.2.2. 使用默认 InMemoryChannel 配置

InMemoryChannels 仅适用于开发环境,不应在生产环境中使用。

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

  • 没有可用的事件持久性。如果 Pod 停机,则 Pod 上的事件将会丢失。
  • InMemoryChannel 类型频道没有实现事件排序,因此同时接收到的两个事件可能会以任何顺序传送给订阅者。
  • 如果订阅者拒绝某个事件,就不会再重新发送尝试。如果存在 sink,则被拒绝的事件会被发送到一个 deadLetterSink。如果不存在,则被拒绝的事件将被丢弃。如需有关为频道配置事件交付和 deadLetterSink 设置的更多信息,请参阅,使用订阅从频道向 sink 发送事件

安装 Knative Eventing 时,会自动创建以下自定义资源定义(CRD):

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: knative-eventing
  name: config-br-default-channel
data:
  channelTemplateSpec: |
    apiVersion: messaging.knative.dev/v1
    kind: InMemoryChannel

使用集群默认配置创建频道

  • 创建通用频道自定义对象。

    apiVersion: messaging.knative.dev/v1
    kind: Channel
    metadata:
      name: example-channel
      namespace: default

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

    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.3. 使用订阅将事件从频道发送到 sink

订阅向频道的事件 sink 提供订阅。

10.3.1. 创建订阅

您可以创建订阅将服务或其他事件 sink 连接到频道。

重要

Knative Eventing 是一个技术预览功能。InMemoryChannel 类型仅用于开发环境,不应在生产环境中使用。

先决条件

流程

  1. 通过创建一个包含以下内容的 YAML 文件,创建一个 Subscription 对象来连接频道到服务:

    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>

10.4. 使用触发器(trigger)

所有发送到某个频道或者代理的事件都会被发送到该频道的所有订阅者或者代理。

使用触发器可让您过滤频道或代理的事件,以便订阅者只根据您定义的标准接收到一小部分事件。

Knative CLI 提供了一组 kn trigger 命令,可用于创建和管理触发器。

10.4.1. 先决条件

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

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

    您可以按照 在 Knative Eventing 中使用代理中的内容,或在创建触发器时使用 --inject-broker 标志来创建 default 代理。以下介绍了使用标志的步骤。

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

10.4.2. 使用 kn创建触发器

流程

运行以下命令来创建服务:

$ kn trigger create <TRIGGER-NAME> --broker <BROKER-NAME> --filter <KEY=VALUE> --sink <SINK>

要创建触发器并使用代理注入程序创建 default 代理,请输入以下命令:

$ kn trigger create <TRIGGER-NAME> --inject-broker --filter <KEY=VALUE> --sink <SINK>

触发器 YAML 示例:

apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
  name: trigger-example 1
spec:
 broker: default 2
 subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: my-service 3

1
触发器的名称。
2
事件要在其中过滤的代理名称。如果没有指定代理,则触发器将使用 default 代理。
3
消费者过滤过的事件的服务名称。

10.4.3. 使用 kn列出触发器

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

流程

  • 要输出可用触发器列表,请输入以下命令:

    $ kn trigger list

    输出示例:

    $ kn trigger list
    NAME    BROKER    SINK           AGE   CONDITIONS   READY   REASON
    email   default   svc:edisplay   4s    5 OK / 5     True
    ping    default   svc:edisplay   32s   5 OK / 5     True
  • 要以 JSON 格式输出触发器列表,请输入以下命令:

    $ kn trigger list -o json

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

kn trigger describe 命令会输出有关一个触发器的信息。

流程

要输出关于触发器的信息,请输入以下命令:

$ kn trigger describe <TRIGGER-NAME>

输出示例:

$ kn trigger describe ping
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.4.5. 使用 kn删除触发器

流程

要删除触发器,请输入以下命令:

$ kn trigger delete <TRIGGER-NAME>

10.4.6. 使用 kn更新触发器

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

流程

要更新触发器,请输入以下命令:

$ kn trigger update NAME --filter KEY=VALUE --sink SINK [flags]

您可以更新触发器来过滤与传入事件匹配的事件属性,如 type=knative.dev.event。例如:

$ kn trigger update mytrigger --filter type=knative.dev.event

您也可以从触发器中删除过滤器属性。例如,您可以使用键 type 来删除过滤器属性:

$ kn trigger update mytrigger --filter type-

以下示例演示了如何将触发器的 sink 更新为 svc:new-service:

$ kn trigger update mytrigger --sink svc:new-service

10.4.7. 使用触发器过滤事件

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

$ kn trigger create foo --broker default --filter type=dev.knative.samples.helloworld --sink svc:mysvc

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

$ kn trigger create foo --broker default --sink svc:mysvc \
--filter type=dev.knative.samples.helloworld \
--filter source=dev.knative.samples/helloworldsource \
--filter myextension=my-extension-value

10.5. 使用 SinkBinding

SinkBinding 用于将事件和 事件源连接至事件消费者或 事件 sink(如一个 Knative 服务或应用程序)。

注意

以下两个流程都要求您创建 YAML 文件。

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

10.5.1. 通过 Knative CLI (kn) 使用 SinkBinding

本指南描述了使用 kn 命令创建、管理和删除 SinkBinding 实例所需的步骤。

先决条件

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

流程

  1. 要检查 SinkBinding 是否已正确设置,请创建一个 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 svc: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
          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
    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": ""
      }

10.5.2. 通过 YAML 的方法使用 SinkBinding

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

先决条件

  • 已安装 Knative Serving 和 Eventing。

流程

  1. 要检查 SinkBinding 是否已正确设置,请创建一个 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。
    1. 创建 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
          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
    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": ""
      }

第 11 章 事件源

11.1. 事件源入门

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

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

ApiServerSource
把一个 sink 连接到 Kubernetes API 服务器。
PingSource
定期使用带有恒定有效负载的 ping 事件。它可以作为一个计时器使用。

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

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

11.1.1. 先决条件

11.1.2. 创建事件源

11.1.3. 其他资源

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

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

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

API 服务器源
通过创建 APIServerSource 对象,将接收器连接到 Kubernetes API 服务器。
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   svc:eshow2   True
b1     SinkBinding       sinkbindings.sources.knative.dev       svc:eshow3   False
p1     PingSource        pingsources.sources.knative.dev        svc:eshow1   True

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

$ kn source list --type PingSource

输出示例

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

11.2.3. 后续步骤

11.3. 使用 API 服务器源

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

注意

以下两个流程都要求您创建 YAML 文件。

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

11.3.1. 通过 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 svc:<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/v1alpha1)
    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.2. 使用 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.3. 使用 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/v1beta1
          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:v0.13.2

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

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

    apiVersion: eventing.knative.dev/v1alpha1
    kind: Trigger
    metadata:
      name: event-display-trigger
      namespace: default
    spec:
      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/v1beta1
          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.4. 删除 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 svc: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

第 12 章 使用 OpenShift Serverless 的 metering

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

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

12.1. 安装 metering

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

12.2. Knative Serving metering 的数据源

以下数据源示例演示了如何配置 Knative Serving 以用于 OpenShift Container Platform metering。

12.2.1. Knative Serving 中 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!=""}
          )

12.2.2. Knative Serving 中内存用量的数据源

这个示例数据源为每个 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!=""}
          )

12.2.3. 为 Knative Serving metering 应用数据源

流程

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

    $ oc apply -f <datasource_name>.yaml

    示例命令

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

12.3. 对 Knative Serving metering 的查询

以下查询示例资源引用示例数据源。

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

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

12.3.3. 对 Knative Serving metering 应用查询

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

    $ oc apply -f <query_name>.yaml

    示例命令

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

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

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

法律通告

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.