什么是Knative Serving和Kourier?

22-09-28 banq

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网络层实现了接收到的请求到容器的路由。
网络层有三种选择: IstioContourKourier 。
不管你选择哪一个,你仍然使用 Envoy 来实现路由。
Network层根据Route产生的Knative/Ingress信息,启动、配置、更新Envoy容器,实现路由。

如果使用 Istio 或 Contour,则需要在 Kubernetes 集群中安装它们的自定义资源和自定义控制器。此外,我们需要运行从 Knative/Ingress 生成 Istio 和 Contour Ingress的自定义控制器( net-istionet-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 配置可能很复杂,但集群和路由是它们包含的两个对象:
  1. 集群是属于同一服务的 Internet 协议地址 (IP) 的集合。路由包含用于匹配给定请求的所有信息:主机、路径、标头等。
  2. 路由还可以指定在匹配时请求应该转到哪个集群代理。


在一个入口Ingress被转化为Envoy配置中的对象后,我们可以使用Envoy xDS APIs将该配置暴露给集群中的Envoys。Kourier负责管理集群。

当Knative扩大服务中的pod数量时,Kourier会自动选择最新的pod的IP,并开始将流量代理给它。同样,当pod的数量减少时,Kourier会收到通知,并停止向计划删除的pod发送请求。

值得注意的是,在所有这些过程中,Kourier不会创建任何只有它能理解的自定义资源。
相反,Kourier只与Knative Serving(入口)管理的对象,以及类似Kubernetes的端点、秘密(包括TLS配置的对象)等管理的对象一起工作。这就是为什么我们说Kourier是一个 "Knative-native "的摄入器。


更多Kourier