第 2 章 发现
2.1. 关于 OpenShift Serverless
OpenShift Serverless 提供 Kubernetes 原生构建块，供开发人员在 OpenShift Container Platform 中创建和部署无服务器、事件驱动的应用程序。OpenShift Serverless 基于开源 Knative 项目，通过启用企业级无服务器平台为混合和多云环境提供可移植性和一致性。
2.1.1. Knative Serving
Knative Serving 支持想要创建、部署和管理云原生应用程序的开发人员。它以 Kubernetes 自定义资源定义(CRD)的形式提供一组对象，用于定义和控制 OpenShift Container Platform 集群上无服务器工作负载的行为。
开发人员使用这些 CRD 创建自定义资源（CR）实例，这些实例可作为构建块用于处理复杂用例。例如：
- 快速部署无服务器容器。
- 自动缩放 pod
2.1.1.1. Knative Serving 资源
- 服务
-
service.serving.knative.devCRD 会自动管理工作负载的生命周期，以确保应用程序通过网络部署并可访问。每次用户创建的服务或自定义资源发生变化时，它都会创建一个路由、配置和新修订版本。Knative 中进行的大多数开发人员交互都是通过修改服务进行的。 - 修订
-
revision.serving.knative.devCRD 是每次对工作负载进行修改所涉及代码和配置的时间点快照。所有修订版本均为不可变对象，可以根据需要保留。 - Route
-
route.serving.knative.devCRD 可将网络端点映射到一个或多个修订版本。您可通过多种方式管理流量，包括部分流量和指定路由。 - Configuration
-
configuration.serving.knative.devCRD 可保持部署所需状态。它可在使编程过程和配置配置过程相互分离。修改配置则会创建一个新修订版本。
2.1.2. Knative Eventing
OpenShift Container Platform 上的 Knative Eventing 可让开发人员使用 事件驱动的架构 和无服务器应用程序。事件驱动的体系结构是基于事件和事件用户间分离关系的概念。
事件制作者创建事件，事件 sink、或消费者接收事件。Knative Eventing 使用标准 HTTP POST 请求来发送和接收事件制作者和 sink 之间的事件。这些事件符合 CloudEvents 规范，它允许在任何编程语言中创建、解析、发送和接收事件。
Knative Eventing 支持以下用例：
- 在不创建消费者的情况下发布事件
- 您可以将事件作为 HTTP POST 发送到代理，并使用绑定分离生成事件的应用程序的目标配置。
- 在不创建发布程序的情况下消耗事件
- 您可以使用 Trigger 来根据事件属性消耗来自代理的事件。应用程序以 HTTP POST 的形式接收事件。
要启用多种 sink 类型的交付，Knative Eventing 会定义以下通用接口，这些接口可由多个 Kubernetes 资源实现：
- 可寻址的资源
-
能够接收和确认通过 HTTP 发送的事件到 Event 的
status.address.url字段中定义的地址。KubernetesService资源也满足可寻址的接口。 - 可调用的资源
-
能够通过 HTTP 接收事件并转换它，并在 HTTP 响应有效负载中返回
0或1新事件。这些返回的事件可能会象处理外部事件源中的 Events 一样进一步处理。
您可以使用以下方法将事件从事件源传播到多个事件接收器：
2.1.3. 支持的配置
OpenShift Serverless 支持的功能、配置和集成（当前和过去的版本）包括在 支持的配置页面中。
2.1.4. 可伸缩性和性能
OpenShift Serverless 已使用配置为 3 个主要节点和 3 个 worker 节点进行测试，每个节点都有 64 个 CPU、457 GB 内存和 394 GB 存储。
使用此配置创建的最大 Knative 服务数为 3,000。这与 OpenShift Container Platform Kubernetes 服务限制 10,000 对应，因为 1 个 Knative 服务创建 3 个 Kubernetes 服务。
零响应时间的平均缩放约为 3.4 秒，最大响应时间为 8 秒，而一个简单 Quarkus 应用程序使用 99.9thile 的 4.5 秒。这些时间可能因应用程序和应用程序的运行时的不同而有所不同。
