Knavite Serving是构成Knative的组件之一。Knative支持在 Kubernetes 上构建serverless无服务器、事件驱动的应用程序。
Knative 由两个组件组成：Serving和Eventing 。
Serving 支持在 Kuberentes 上实现 Serverless Container。Serverless Container 是指容器化应用程序从 0个容器实例启动，开始响应某个事件（HTTP 请求等），根据需要扩展到多个单元并进行处理的环境。
Serving将围绕网络的配置和处理、容器从零开始的自动缩放以及容器版本管理自动化，这些都是实现无服务器容器所必需的。 这使得用户能够在Kubernetes上轻松实现基于无服务器容器的服务。
事件支持在Kubernetes上使用HTTP请求实现事件的Pub/Sub，并且有官方样本和配置图可用于服务和事件的具体例子。
在这里，Knative Serving被用来实现一种机制，即与请求的主机名相对应的API服务器从零状态启动，或扩展到多个服务器，在收到HTTP请求后进行处理并返回响应。
Knative Serving 的关键组件
Knative Serving有典型的自定义资源，如Service、Route、Configuration、Revision 和 Ingress。 当你创建一个服务资源时，其他资源会由Knative Serving自定义控制器自动生成。 还可以定义配置、路线等来控制行为。
1、服务Service
- 一个自定义的资源（此后称为Knative/Service服务），它抽象了用Serving启动容器和实现对容器的路由所需的元素。
- 一旦Knative/服务被创建，Knative的自定义控制器就会根据Knative/服务中定义的信息创建配置、修订、路由和入口。
2、配置Configuration
保持最新的修订定义
3、修订Revision
- 在某一特定时间点的配置快照，当配置被新创建或更新时，从配置中定义的信息生成。
- Knative自定义控制器根据Revision中定义的信息创建Deployments等。
4、路由Route
- 管理将请求路由到生成的 pod 的修订版本
- 从 Route 生成 一个自定义资源Ingress，它抽象了后面描述的 Network 层设置。
- 网络层有多个实现选项（Istio、Contour、Kourier），使用哪个实现来生成 Ingress 在 CofigMap 中指定
- 网络层根据生成的 Ingress 资源设置路由
5、入口Ingress
一个自定义的资源，扩展了Knative的标准Kubernetes Ingress资源（以下简称Knative/Ingress）。
它被网络层引用，并提供信息以实现Knative Serving中的请求路由。
网络Newtork层
在 Knative Serving 中，Network网络层实现了接收到的请求到容器的路由。
网络层有三种选择： Istio、Contour和Kourier 。
不管你选择哪一个，你仍然使用 Envoy 来实现路由。
Network层根据Route产生的Knative/Ingress信息，启动、配置、更新Envoy容器，实现路由。
如果使用 Istio 或 Contour，则需要在 Kubernetes 集群中安装它们的自定义资源和自定义控制器。此外，我们需要运行从 Knative/Ingress 生成 Istio 和 Contour Ingress的自定义控制器（ net-istio、net-contour ） 。
而Kourier 是为 Knative Serving 开发的 Ingress 实现，不需要任何自定义资源定义，只需一个自定义控制器。
Kourier 的自定义控制器net-kourier直接从 Knative/Ingress 生成 Envoy 设置，并通过将设置反映到 Envoy 容器来实现路由。
相比于网络层使用 Istio 或 Contour，使用 Kourier 进行配置极其简单，选择的原因是它具备必要且充分的功能。
Kourier关键部件
与 Istio 一样，Kourier 是基于 Envoy 网关的轻量级入口，没有额外的自定义资源定义 (CRD)。它由两部分组成：
- Kourier 网关是使用基本引导配置运行的 Envoy，该配置连接回 Kourier 控制平面。
- Kourier 控制平面处理 Knative 入口对象并保持 Envoy 配置最新。
Kourier 执行以下操作：
- 读取由 Knative Serving 创建的入口对象。
- 将这些对象转换为 Envoy 配置。
- 将配置公开给它管理的 Envoy。
在 Knative Serving 中部署新服务时，它会创建一个Ingress入口对象，其中包含有关如何公开服务的信息。入口对象包括以下元素：
- 主机、路径和标头：这些元素与传入请求中包含的相同元素匹配。当有匹配时，我们知道请求应该被代理到与入口对象关联的 Knative 服务。
- 拆分：我们使用拆分在已部署服务的不同修订版之间划分传入流量。
- Visibility：定义服务是应该从集群内部还是外部访问。
- 传输层安全性 (TLS)：指定Red Hat OpenShift密钥，其中包含使用 HTTPS 公开服务所需的证书和密钥。
Kourier 订阅由 Knative Serving 管理的入口Ingress的变化。每次创建、删除或修改入口时都会通知 Kourier。发生这种情况时，Kourier 会分析入口中的信息，并将信息转换为 Envoy 配置中的对象。Envoy 配置可能很复杂，但集群和路由是它们包含的两个对象：
- 集群是属于同一服务的 Internet 协议地址 (IP) 的集合。路由包含用于匹配给定请求的所有信息：主机、路径、标头等。
- 路由还可以指定在匹配时请求应该转到哪个集群代理。
在一个入口Ingress被转化为Envoy配置中的对象后，我们可以使用Envoy xDS APIs将该配置暴露给集群中的Envoys。Kourier负责管理集群。
当Knative扩大服务中的pod数量时，Kourier会自动选择最新的pod的IP，并开始将流量代理给它。同样，当pod的数量减少时，Kourier会收到通知，并停止向计划删除的pod发送请求。
值得注意的是，在所有这些过程中，Kourier不会创建任何只有它能理解的自定义资源。
相反，Kourier只与Knative Serving（入口）管理的对象，以及类似Kubernetes的端点、秘密（包括TLS配置的对象）等管理的对象一起工作。这就是为什么我们说Kourier是一个 "Knative-native "的摄入器。