无服务器应用程序
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-hpa
、controller
、activator
、kourier-control
和kourier-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 秒的时间处于IngressNotConfigured
或Unknown
状态。
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 项目。
- 有关最新 Knative Serving 发行版本的详情,请参阅 Knative Serving 发行页。
- 有关最新 Knative Serving Operator 发行版本的详情,请参阅 Knative Serving Operator 发行页。
- 有关最新 Knative CLI 发行版本的详情,请参阅 Knative CLI 发行页。
- 有关最新 Knative Eventing 发行版本的详情,请参阅 Knative Eventing 发行页。
第 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. 后续步骤
- 在 OpenShift Container Platform 集群上安装 OpenShift Serverless Operator。
- 请参阅 OpenShift Serverless 发行注记。
- 按照创建和管理无服务器应用程序文档创建应用程序。
第 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 的方法。
流程
- 在 OpenShift Container Platform web 控制台中导航至 Operators → OperatorHub 页。
滚动页面,或在 Filter by keyword 框中输入关键字 Serverless 以查找 OpenShift Serverless Operator。
查看 Operator 信息并单击 Install。
在 Create Operator Subscription 页面:
-
Installation Mode 是 All namespaces on the cluster (default)。选择该项会将 Operator 安装至默认
openshift-operators
命名空间,以便供集群中的所有命名空间监视和使用。 -
Installed Namespaces 为
openshift-operators
。 - 选择 4.4 频道作为 更新频道。4.4 频道将启用 OpenShift Serverless Operator 最新稳定版本的安装。
- 选择 Automatic 或 Manual 批准策略。
-
Installation Mode 是 All namespaces on the cluster (default)。选择该项会将 Operator 安装至默认
- 单击 Subscribe,以便该 Operator 可供 OpenShift Container Platform 集群上的所选命名空间使用。
在 Catalog → Operator Management 页面中,您可以监控 OpenShift Serverless Operator 订阅的安装和升级进度。
- 如果选择了 Manual 批准策略,订阅的升级状态将会一直保持在 Upgrading,直到您审阅并批准了它的安装计划。在 Install Plan 页面批准后,订阅的升级状态将变为 Up to date。
- 如果选择了 Automatic 批准策略,升级状态会在不用人工参与的情况下变为 Up to date。
验证步骤
当订阅的升级状态变为Up to date 后,选择 Catalog → Installed Operators 来验证 OpenShift Serverless Operator 最终出现,它的 Status 在相关的命名空间中最终会变为 InstallSucceeded。
如果没有:
- 切换到 Catalog → Operator Management 页,检查 Operator Subscriptions 和 Install Plans 页中的 Status 是否有错误。
-
检查 Workloads → Pods 页中的
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
命名空间
流程
在 OpenShift Container Platform web 控制台中,导航至 Administration → Namespaces 页面。
输入
knative-serving
作为项目的 Name。其他字段都是可选的。- 点击 Create。
5.2.1.2. 使用 CLI 创建 knative-serving
命名空间
流程
使用以下命令创建
knative-serving
命名空间:$ oc create namespace knative-serving
5.2.2. 先决条件
- 一个具有集群管理员权限的 OpenShift Container Platform 账户。
- 已安装 OpenShift Serverless Operator。
-
创建
knative-serving
命名空间。
5.2.3. 使用 Web 控制台安装 Knative Serving
流程
- 在 OpenShift Container Platform web 控制台的 Administrator 视角中,进入 Operators → Installed Operators。
- 检查页面顶部的 Project 下拉菜单是否已设置为 Project: knative-serving。
点击 OpenShift Serverless Operator 的 Provided APIs 列表中的 Knative Serving 来进入 Knative Serving 选项卡。
点击 Create Knative Serving 按钮。
在 Create Knative Serving 页中,您可以使用默认设置安装 Knative Serving。点 Create。
您还可以使用提供的表单或编辑 YAML 来修改
KnativeServing
对象来修改 Knative Serving 安装的设置。-
建议您在不需要完全控制
KnativeServing
对象创建的简单配置中使用该表单。 对于更复杂的配置,建议编辑 YAML,这可以完全控制
KnativeServing
对象的创建。您可以通过点击 Create Knative Serving 页右上角的 edit YAML 链接来访问 YAML。完成表单后,或者完成对 YAML 的修改后,点 Create。
注意如需有关 KnativeServing 自定义资源定义的配置选项的更多信息,请参阅 高级安装配置选项。
-
建议您在不需要完全控制
安装 Knative Serving 后,将创建
KnativeServing
对象,并将自动定向到 Knative Serving 选项卡。您可以在资源列表中看到
knative-serving
。
验证步骤
-
在 Knative Serving 选项卡中点击
knative-serving
。 您将被自动定向到 Knative Serving Overview 页面。
- 向下滚动查看条件列表。
您应该看到一个状况为 True的条件列表,如示例镜像所示。
注意创建 Knative Serving 资源可能需要几秒钟时间。您可以在 Resources 选项卡中查看其状态。
- 如果条件状态为 Unknown 或 False,请等待几分钟,然后在确认已创建资源后再重新检查。
5.2.4. 使用 YAML 安装 Knative Serving
流程
-
创建名为
serving.yaml
的文件。 将以下示例 YAML 复制到
service.yaml
中:apiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving
应用
service.yaml
文件:$ oc apply -f serving.yaml
验证步骤
使用以下命令校验安装是否完成:
$ 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 资源可能需要几秒钟时间。
-
如果条件状态为
Unknown
或False
,请等待几分钟,然后在确认已创建资源后再重新检查。 使用以下命令检查是否已创建了 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
命名空间
流程
- 在 OpenShift Container Platform web 控制台中,导航至 Administration → Namespaces 页面。
点 Create Namespace。
输入
knative-eventing
作为项目的 Name。其他字段都是可选的。- 点击 Create。
5.3.1.2. 使用 CLI 创建 knative-eventing
命名空间
流程
使用以下命令创建
knative-eventing
命名空间:$ oc create namespace knative-eventing
5.3.2. 先决条件
- 一个具有集群管理员权限的 OpenShift Container Platform 账户。
- 已安装 OpenShift Serverless Operator。
-
创建
knative-eventing
命名空间。
5.3.3. 使用 web 控制台安装 Knative Eventing
流程
- 在 OpenShift Container Platform web 控制台的 Administrator 视角中,进入 Operators → Installed Operators。
- 检查页面顶部的 Project 下拉菜单是否已设置为 Project: knative-eventing。
点击 OpenShift Serverless Operator 的 Provided APIs 列表中的 Knative Eventing 来进入 Knative Eventing 选项卡。
点击 Create Knative Eventing 按钮。
在 Create Knative Eventing 页面中,您可以选择使用提供的默认表单或编辑 YAML 来配置
KnativeEventing
对象。建议您在不需要完全控制
KnativeEventing
对象创建的简单配置中使用该表单。可选。如果您要使用表单配置
KnativeEventing
对象,请为您的 Knative Eventing 部署进行任何要实现的更改。
点击 Create。
对于更复杂的配置,建议编辑 YAML,这可以完全控制
KnativeEventing
对象的创建。您可以通过点击 Create Knative Eventing 页右上角的 edit YAML 链接来访问 YAML。可选。如果您要通过编辑 YAML 配置
KnativeEventing
对象,请对您希望用于 Knative Eventing 部署的 YAML 进行更改。
点击 Create。
安装 Knative Eventing 后,将创建
KnativeEventing
对象,并将自动定向到 Knative Eventing 选项卡。您可以在资源列表中看到
knative-eventing
。
验证步骤
-
在 Knative Eventing 选项卡中点击
knative-eventing
。 您将被自动定向到 Knative Eventing Overview 页面。
- 向下滚动查看条件列表。
您应该看到一个状况为 True的条件列表,如示例镜像所示。
注意创建 Knative Eventing 资源可能需要几秒钟时间。您可以在 Resources 选项卡中查看其状态。
- 如果条件状态为 Unknown 或 False,请等待几分钟,然后在确认已创建资源后再重新检查。
5.3.4. 使用 YAML 安装 Knative Eventing
流程
-
创建名为
eventing.yaml
的文件。 将以下示例 YAML 复制到
eventing.yaml
中:apiVersion: operator.knative.dev/v1alpha1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing
- 可选。根据您的 Knative Eventing 部署,对 YAML 进行相应的更改。
输入以下内容来应用
eventing.yaml
文件:$ oc apply -f eventing.yaml
验证步骤
使用以下命令校验安装是否完成:
$ 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 资源可能需要几秒钟时间。
-
如果条件状态为
Unknown
或False
,请等待几分钟,然后在确认已创建资源后再重新检查。 使用以下命令检查是否已创建 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 注入,修改后,您的部署将不被支持。
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:
- 在控制器中创建并挂载包含证书的卷。
- 正确设置需要的环境变量。
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 中的证书。
支持的类型为 ConfigMap
和 Secret
。
如果没有指定控制器自定义证书,则默认为 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. 其他资源
- 如需有关配置高可用性的更多信息,请参阅 OpenShift Serverless 的高可用性。
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 控制台。
流程
-
在 OpenShift Container Platform web 控制台中,选择
openshift-operators
命名空间。 - 导航到 Operators → Installed Operators 页面。
- 选择 OpenShift Serverless Operator Operator。
- 点 Subscription → Channel。
-
在 Change Subscription Update Channel 窗口中,选择
4.4
并点 Save。 -
等待
knative-serving
命名空间中的所有 Pod 都已升级,KnativeServing 自定义资源 (CR) 报告了最新的 Knative Serving 版本。
验证步骤
要验证升级是否成功,您可以检查 knative-serving
命名空间中的 pod 状态以及 KnativeServing CR 的版本。
运行以下命令,检查 pod 的状态:
$ oc get knativeserving.operator.knative.dev knative-serving -n knative-serving -o=jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
以上命令应该返回
True
状态。运行以下命令,检查 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
命名空间。
流程
要移除 Knative Serving,请使用以下命令:
$ oc delete knativeservings.operator.knative.dev knative-serving -n knative-serving
在该命令运行完成且已从
knative-serving
命名空间中移除所有 Pod 后,使用以下命令移除命名空间:$ oc delete namespace knative-serving
5.6.2. 卸载 Knative Eventing
要卸载 Knative Eventing,必须移除其自定义资源并移除 knative-eventing
命名空间。
流程
要移除 Knative Eventing,请使用以下命令:
$ oc delete knativeeventings.operator.knative.dev knative-eventing -n knative-eventing
在该命令运行完成且已从
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。
流程
运行以下命令删除 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 控制台右上角的 图标进入 Command Line Tools 页,然后在下拉菜单中选择 Command Line Tools。
流程
-
从 Command Line Tools 页下载
kn
CLI。 解包存档:
$ tar -xf <file>
-
将
kn
二进制文件迁移至 PATH 上的目录中。 要查看路径,请运行:
$ 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
存档。
流程
- 下载 CLI。
解包存档:
$ tar -xf <file>
-
将
kn
二进制文件迁移至 PATH 上的目录中。 要查看路径,请运行:
$ echo $PATH
注意如果不使用 RHEL 或 Fedora,请确保将 libc 安装在库路径的目录中。如果 libc 不可用,您在运行 CLI 命令时可能会看到以下错误:
$ kn: No such file or directory
5.7.4. 为 macOS 安装 kn
CLI
用于 macOS 的 kn
以 tar.gz
存档形式提供。
流程
- 下载 CLI。
- 解包和解压存档。
-
将
kn
二进制文件迁移至 PATH 上的目录中。 要查看 PATH,请打开终端窗口并运行:
$ echo $PATH
5.7.5. 为 Windows 安装 kn
CLI
用于 Windows 的 CLI 以 zip 存档形式提供。
流程
- 下载 CLI。
- 使用 ZIP 程序解压存档。
-
将
kn
二进制文件迁移至 PATH 上的目录中。 要查看您的 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!"
使用以下任一方法创建一个无服务器应用程序:
- 从 OpenShift Container Platform web 控制台创建 Knative 服务。
-
使用
kn
CLI 创建 Knative 服务。 - 创建和应用 YAML 文件。
6.2. 使用 OpenShift Container Platform web 控制台创建无服务器应用程序
您可以使用 OpenShift Container Platform web 控制台中的 Developer 或 Administrator 视角创建无服务器应用程序。
6.2.1. 使用管理员视角创建无服务器应用程序
先决条件
要使用 管理员 视角创建无服务器应用程序,请确定您已完成了以下步骤。
- 安装了 OpenShift Serverless Operator 和 Knative Serving。
- 您已登录到 Web 控制台,且处于 Administrator 视角。
流程
导航到 Serverless → Services 页面。
- 点 Create Service。
手动输入 YAML 或 JSON 定义,或者将文件拖放到编辑器中。
- 点击 Create。
6.2.2. 使用 Developer 视角创建应用程序
有关在 OpenShift Container Platform 中使用 Developer 视角创建应用程序的更多信息,请参阅 使用 Developer 视角创建应用程序。
6.3. 使用 CLI 创建无服务器应用程序
以下流程描述了如何使用 kn
CLI 创建基本无服务器应用程序。
先决条件
- 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
-
安装了
kn
CLI。
流程
创建 Knative 服务:
$ kn service create <service_name> --image <image> --env <key=value>
示例命令
$ kn service create 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
应用它。
流程
通过复制以下示例来创建 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
。导航到包含
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。
流程
查找应用程序 URL:
$ oc get ksvc <service_name>
输出示例
NAME URL LATESTCREATED LATESTREADY READY REASON hello http://hello-default.example.com hello-4wsd2 hello-4wsd2 True
向集群发出请求并观察其输出:
HTTP 请求示例
$ curl http://hello-default.example.com
HTTPS 请求示例
$ curl https://hello-default.example.com
输出示例
Hello Serverless!
可选。如果您在证书链中收到与自签名证书相关的错误,您可以在 curl 命令中添加
--insecure
标志来忽略这个错误。重要在生产部署中不能使用自签名证书。这个方法仅用于测试目的。
示例命令
$ curl https://hello-default.example.com --insecure
输出示例
Hello Serverless!
可选。如果 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 网关的公共地址以及应用程序的特定主机。
流程
- 找到应用程序主机。请参阅验证无服务器应用程序部署中的相关内容。
获取入口网关的公共地址:
$ 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
手动在 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-hpa
、controller
、activator
、 kourier-control
和 kourier-gateway
组件都会启用高可用性(HA)功能。这些控制器默认配置有两个副本。
您可以通过更改 KnativeServing
自定义资源定义(CRD)中的 KnativeServing.spec.highAvailability
spec 的配置来修改每个控制器创建的副本数量。
先决条件
- 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
- 安装了 OpenShift Serverless Operator 和 Knative Serving。
- 您可以访问 OpenShift Container Platform Web 控制台并已登录。
流程
在 Web 控制台 Administrator 视角中,导航到 OperatorHub → Installed Operators。
-
选择
knative-serving
命名空间。 点击 OpenShift Serverless Operator 的 Provided APIs 列表中的 Knative Serving 来进入 Knative Serving 选项卡。
点 knative-serving,然后使用 knative-serving 页面中的 YAML 选项卡。
编辑 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。
流程
创建并应用包含以下 YAML 示例的 Jaeger 自定义资源 YAML 文件:
apiVersion: jaegertracing.io/v1 kind: Jaeger metadata: name: jaeger namespace: default
通过编辑
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
验证步骤
您可以使用 jaeger
路由来访问 Jaeger web 控制台以查看追踪数据。
获取
jaeger
路由的主机名:$ oc get route jaeger
输出示例
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD jaeger jaeger-default.apps.example.com jaeger-query <all> reencrypt None
- 在浏览器中使用端点地址来查看控制台。
第 9 章 Knative Serving
9.1. 使用 kn 完成 Knative Serving 任务
Knative kn
CLI 会扩展 oc
或 kubectl
CLI 工具的功能,以集成与 OpenShift Container Platform 上的 Knative 组件的交互。kn
允许开发人员在不直接编辑 YAML 文件的情况下部署和管理应用程序。
9.1.1. 使用 kn
的基本工作流
以下基本流程部署了一个简单的 hello
服务,它会读环境变量 RESPONSE
并打印它的输出。
您可以使用本指南作为在服务中执行创建、读取、更新和删除(CRUD)操作的参考。
流程
通过一个镜像,在
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
列出服务:
$ 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
使用
curl
服务端点命令检查该服务是否正在工作:$ curl http://hello-default.apps-crc.testing
输出示例
Hello Serverless!
更新服务:
$ 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!"。描述该服务。
$ 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
删除服务:
$ kn service delete hello
输出示例
Service 'hello' successfully deleted in namespace 'default'.
通过列出
hello
服务来验证 hello 服务是否已被删除:$ kn service list hello
输出示例
No services found.
9.1.2. 使用 kn
自动扩展工作流
您可使用 kn
修改 Knative 服务来访问自动扩展功能,而无需直接编辑 YAML 文件。
使用带有适当标志的 service create
和 service update
命令来配置自动扩展行为。
标志 | 描述 |
---|---|
| 单个副本处理的并发请求的硬性限制。 |
|
根据传入请求的并发数量建议扩展时间。默认为 |
| 最大副本数。 |
| 最小副本数。 |
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
评估标志时,标志的优先级如下:
-
--untag
:带有此标志的所有引用修订版本均将从流量块中移除。 -
--tag
:修订版本将按照流量块中的指定进行标记。 -
--traffic
:为引用的修订版本分配一部分流量分割。
9.1.3.4. 流量分割标志
kn
作为 kn service update
命令的一部分,支持在服务的流量块上进行流量操作。
下表显示流量分割标志、值格式和标志执行的操作汇总。Repetition 列表示在 kn service update
命令中是否允许重复标志的特定值。
标记 | 值 | 操作 | 重复 |
---|---|---|---|
|
|
为 | 是 |
|
|
为带有 | 是 |
|
|
为最新可用的修订版本提供 | 否 |
|
|
为 | 是 |
|
|
为最新可用的修订版本提供 | 否 |
|
|
从修订中删除 | 是 |
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
为 target
和 containerConcurrency
添加值将以并发请求的 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 自动扩展
minScale
和 maxScale
注解可用于配置可服务于应用程序的最小和最大 pod 数。这些注解可用于防止冷启动或辅助控制计算成本。
- minScale
-
如果没有设置
minScale
注解,pod 会被缩减到 0,或如果ConfigMap
中的enable-scale-to-zero
为false
,则会缩减为 1。 - maxScale
-
如果没有设置
maxScale
注解,则可创建的 pod 数没有上限。
minScale
和 maxScale
可在修订模板中配置如下:
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 负责部署、升级和维护集群日志记录。
您可以通过修改名为 instance
的 ClusterLogging
自定义资源(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
name
和size
参数,为 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 组件的日志
流程
要访问 Kibana UI(Elasticsearch 的可视化工具),请使用以下命令获取 Kibana 路由:
$ oc -n openshift-logging get route kibana
- 使用路由的 URL 导航到 Kibana 仪表板并登录。
- 确保将索引设置为 .all。如果索引未设置为 .all,则只会列出 OpenShift Container Platform 系统日志。
您可使用
knative-serving
命名空间来过滤日志。在搜索框中输入kubernetes.namespace_name:knative-serving
以过滤结果。注意Knative Serving 默认使用结构化日志记录。您可以通过自定义集群日志记录 Fluentd 设置来启用这些日志的解析。这允许在日志级别过滤来快速发现问题。
9.3.4. 使用集群日志来查找通过 Knative Serving 部署的服务的日志
使用 OpenShift Container Platform 集群日志记录时,应用程序写入控制台的日志将在 Elasticsearch 中收集。以下流程概述了如何使用 Knative Serving 将这些功能应用到所部署的应用程序中。
流程
查找 Kibana URL:
$ oc -n cluster-logging get route kibana
- 在浏览器中输入 URL 以打开 Kibana UI。
- 确保将索引设置为 .all。如果索引未设置为 .all,则只会列出 OpenShift Container Platform 系统日志。
通过使用服务部署到的 Kubernetes 命名空间来过滤日志。添加过滤条件以识别服务本身:
kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{SERVICE_NAME}
。注意除此之外还可使用
/configuration
或/revision
来过滤。您可使用
kubernetes.container_name:<user-container>
来缩小搜索范围,只显示由您的应用程序生成的日志。否则,会显示来自 queue-proxy 的日志。注意在应用程序中使用基于 JSON 的结构化日志记录,以便在生产环境中快速过滤这些日志。
9.4. 在修订版本间分割流量
9.4.1. 使用 Developer 视角在修订版本间分割流量
创建无服务器应用程序后,无服务器应用程序会显示在 Developer 视角的 Topology 视图中。应用程序修订由节点代表,无服务器资源服务由节点外的四边形代表。
代码或服务配置中的任何新更改都会触发修订版本,即特定时间点的代码快照。对于服务,您可以根据需要通过分割服务修订版本并将其路由到不同的修订版本来管理服务间的流量。
流程
要在 Topology 视图中的多个应用程序修订版本间分割流量:
- 点击由四边形表示的无服务器资源服务,在侧面面板中查看其概述信息。
点 Resources 选项卡,查看服务的 Revisions 和 Routes 列表。
图 9.1. 无服务器应用程序
- 点侧边面板顶部的由 S 图标代表的服务,查看服务详情概述。
-
点 YAML 选项卡,在 YAML 编辑器中修改服务配置,然后点 Save。例如,将
timeoutseconds
从 300 改为 301。这个配置更改会触发新修订版本。在 Topology 视图中会显示最新的修订,服务 Resources 选项卡现在会显示两个修订版本。 在 Resources 选项卡中,点 按钮查看流量分布对话框:
- 在 Splits 字段中为两个修订版本添加流量百分比。
- 添加标签以便为这两个修订版本创建自定义 URL。
点 Save 查看两个节点,分别代表 Topology 视图中的两个修订版本。
图 9.2. 无服务器应用程序修订
第 10 章 Knative Eventing
10.1. 在 Knative Eventing 中使用代理
Knative Eventing 使用 default
代理,除非特别指定。
如果您有集群管理员权限,可以使用命名空间注解自动创建 default
代理。
所有其他用户必须按照本指南中描述的手动过程创建一个代理。
10.1.1. 手动创建代理
要创建代理,您必须为每个命名空间创建一个服务账户,并为该服务帐户指定所需的 RBAC 权限。
先决条件
-
安装了 Knative Eventing,其中包括
ClusterRole
。
流程
创建
ServiceAccount
对象。输入以下命令来创建
eventing-broker-ingress
对象:$ oc -n <namespace> create serviceaccount eventing-broker-ingress
输入以下命令来创建
eventing-broker-filter
对象:$ oc -n <namespace> create serviceaccount eventing-broker-filter
授予您创建 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
通过创建并应用包含以下内容的 YAML 文件来创建代理:
apiVersion: eventing.knative.dev/v1beta1 kind: Broker metadata: namespace: default name: default 1
- 1
- 这个示例使用
default
名称,但您可以使用其他有效名称替换它。
10.1.2. 使用命名空间注解自动创建代理
如果您有集群管理员权限,您可以通过注解命名空间来自动创建代理。
先决条件
- 安装了 Knative Eventing。
- 一个具有集群管理员权限的 OpenShift Container Platform 账户。
流程
输入以下命令来标注命名空间:
$ oc label namespace default knative-eventing-injection=enabled 1 $ oc -n default get broker default
- 1
- 使用所需命名空间名替换
default
。
本例中显示的行将在
default
命名空间内自动创建一个名为default
的代理。
如果您删除了注解,则不会删除由注解创建的代理。您必须手动删除它们。
10.1.3. 使用命名空间注解删除创建的代理
从所选命名空间中(在这个示例中,是
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 类型仅用于开发环境,不应在生产环境中使用。
先决条件
- 您必须在 OpenShift Container Platform 集群中安装 OpenShift Serverless,包括 Knative Serving 和 Eventing。这可由集群管理员安装。
- 如果没有您要使用的现有 sink,请按照创建和管理无服务器应用程序文档进行操作,创建 一个 Service 以用作 sink。
- 您必须有一个频道才能连接到您的订阅。请参阅 使用 Knative Eventing 的频道。
流程
通过创建一个包含以下内容的 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。
输入以下内容应用 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
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。
流程
要检查 SinkBinding 是否已正确设置,请创建一个 Knative 事件显示服务或事件 sink,在日志中转储传入的信息:
$ kn service create event-display --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
创建一个 SinkBinding 把事件发送到服务:
$ kn source binding create bind-heartbeat --subject Job:batch/v1:app=heartbeat-cron --sink svc:event-display
创建 CronJob:
创建名为
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
在创建了
heartbeats-cronjob.yaml
文件后,请输入:$ oc apply --filename heartbeats-cronjob.yaml
输入以下命令并检查输出,检查是否正确映射了控制器:
$ 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。
流程
要检查 SinkBinding 是否已正确设置,请创建一个 Knative 事件显示服务或事件挂起,从而在日志中转储传入的信息。
将以下示例 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
创建
service.yaml
文件后,输入以下内容应用它:$ oc apply -f service.yaml
创建将事件定向到该服务的 SinkBinding。
创建名为
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。创建
sinkbinding.yaml
文件后,输入以下内容应用它:$ oc apply -f sinkbinding.yaml
创建 CronJob:
创建名为
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
在创建了
heartbeats-cronjob.yaml
文件后,请输入:$ oc apply -f heartbeats-cronjob.yaml
输入以下命令并检查输出,检查是否正确映射了控制器:
$ 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 事件。
您可以输入以下命令来查看消息转储程序功能日志:
$ 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 资源(如 Deployment
、Job
或 StatefulSet
)与接收器进行连接。
您可以使用 OpenShift Container Platform Web 控制台、kn
CLI 或应用 YAML 文件的 Developer 视角 创建和管理 Knative 事件源。
11.1.1. 先决条件
- 您必须在 OpenShift Container Platform 集群中安装 OpenShift Serverless,包括 Knative Serving 和 Eventing。这可由集群管理员安装。
11.1.2. 创建事件源
- 创建 ApiServerSource 对象。
- 创建 PingSource 对象。
11.1.3. 其他资源
- 有关使用 OpenShift Serverless 事件工作流的更多信息,请参阅 Knative Eventing 架构。
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. 后续步骤
- 请参阅有关使用 API 服务器源的 文档。
- 请参阅有关使用 ping 源的文档。
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。
流程
为
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
注意如果要重新使用具有适当权限的现有服务帐户,您必须修改该服务帐户的
authentication.yaml
文件。创建服务帐户、角色绑定和集群绑定:
$ oc apply -f authentication.yaml
创建使用代理作为事件接收器的
ApiServerSource
对象:$ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
创建 Knative 服务,在日志中转储传入的信息:
$ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
创建触发器将事件从
default
代理过滤到服务:$ kn trigger create <trigger_name> --sink svc:<service_name>
通过在 default 命名空间中启动 Pod 来创建事件:
$ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display
通过检查以下命令生成的输出来检查是否正确映射了控制器:
$ 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。
获取 pod:
$ oc get pods
查看 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 服务器源
本节介绍了使用 kn
和 oc
命令删除 ApiServerSource
对象、触发器、服务、服务帐户、集群角色和集群绑定的步骤。
先决条件
-
已安装了
kn
CLI。
流程
删除触发器:
$ kn trigger delete <trigger_name>
删除服务:
$ kn service delete <service_name>
删除 API 服务器源:
$ kn source apiserver delete <source_name>
- 删除服务帐户、集群角色和集群绑定:
$ oc delete -f authentication.yaml
11.3.3. 使用 YAML 文件创建 API 服务器源
本指南描述了使用 YAML 文件创建 ApiServerSource
对象所需的步骤。
先决条件
- 在集群中安装了 Knative Serving 和 Eventing。
-
您已在与
ApiServerSource
对象中定义的相同的命名空间中创建default
代理。
流程
要为 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
注意如果要重新使用具有适当权限的现有服务帐户,您必须修改该服务帐户的
authentication.yaml
。创建
authentication.yaml
文件后,应用该文件:$ oc apply -f authentication.yaml
要创建
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
要检查 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
要从
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
要创建事件,请在
default
命名空间中启动 pod:$ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display
要检查控制器是否已正确映射,请输入以下命令并检查输出:
$ 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,您可以查看消息转储程序功能日志。
获取 pod:
$ oc get pods
查看 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
对象、触发器、服务、服务帐户、集群角色和集群绑定。
流程
删除触发器:
$ oc delete -f trigger.yaml
删除服务:
$ oc delete -f service.yaml
删除 API 服务器源:
$ oc delete -f k8s-events.yaml
删除服务帐户、集群角色和集群绑定:
$ 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
11.4.1. 使用 Knative CLI 创建 ping 源
以下小节介绍了如何使用 kn
CLI 创建、验证和移除基本 PingSource
对象。
先决条件
- 已安装 Knative Serving 和 Eventing。
-
已安装
kn
CLI。
流程
要验证 ping 源是否可以工作,请创建一个简单的 Knative 服务,在服务日志中转储传入的信息:
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
对于您要请求的每一组 ping 事件,请在与事件消费者相同的命名空间中创建一个
PingSource
对象:$ kn source ping create test-ping-source \ --schedule "*/2 * * * *" \ --data '{"message": "Hello world!"}' \ --sink svc:event-display
输入以下命令并检查输出,检查是否正确映射了控制器:
$ 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 中观察到。
查看新创建的 pod:
$ watch oc get pods
使用
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 源
删除
PingSource
对象:$ kn delete pingsources.sources.knative.dev test-ping-source
删除
event-display
服务:$ kn delete service.serving.knative.dev event-display
11.4.2. 使用 YAML 文件创建 ping 源
以下小节介绍了如何使用 YAML 文件创建、验证和移除基本 ping 源。
先决条件
- 已安装 Knative Serving 和 Eventing。
以下操作过程要求您创建 YAML 文件。
如果更改了示例中使用的 YAML 文件的名称,则需要更新对应的 CLI 命令。
流程
要验证 ping 源是否可以工作,请创建一个简单的 Knative 服务,在服务日志中转储传入的信息。
将 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
应用
service.yaml
文件:$ oc apply --filename service.yaml
对于您要请求的每一组 ping 事件,请在与事件消费者相同的命名空间中创建一个
PingSource
对象。将 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
应用
ping-source.yaml
文件:$ oc apply --filename ping-source.yaml
输入以下命令并查看输出来检查是否正确映射了控制器:
$ 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 中观察到。
查看新创建的 pod:
$ watch oc get pods
使用
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
输入以下命令删除该服务:
$ oc delete --filename service.yaml
输入以下命令来删除
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
12.4.1. 运行 metering 报告
通过以 YAML 文件的形式应用报告来运行报告:
$ oc apply -f <report_name>.yaml
检查报告:
$ 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
Legal Notice
Copyright © 2024 Red Hat, Inc.
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman 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 Software Collections 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.