Kourier：轻量级Knative Serving入口

直到最近，Knative Serving还使用Istio作为其默认的网络组件来处理外部集群流量和服务间通信。Istio是一个很好的服务网格解决方案，但如果您不需要它，它可能会给集群增加不必要的复杂性和资源使用。

这就是我们创建Kourier的原因：为了简化Knative Serving的入口端。Knative最近收养了Kourier，所以它现在是Knative家族的一员！本文介绍了Kourier，并让您开始将其作为一种更简单、更轻量级的方式来向外部网络公开Knative应用程序。

让我们先简单介绍一下Knative和Knative Serving。

Knative是什么？

Knative是一个基于Kubernetes的平台，用于部署和管理无服务器工作负载。它分为两个项目：

• Knative Serving专注于使用HTTP流量触发容器。
• Knative Eventing专注于使用事件触发容器。

本文介绍了Kourier如何使用Knative Serving。

Knative Serving

Knative Serving提供以下功能：部署、自动缩放和资源节约。在部署方面，Knative Serving简化了我们将应用程序部署到Kubernetes的方式，并添加了修订的概念。修订是在创建或修改服务时采用的不可变服务配置。此功能允许您快速回滚更改，并为Knative提供高级流量管理，如蓝绿色部署和镜像流量。

对于自动缩放，Knative Serving会根据为该服务定义的最大并发请求自动缩放容器。例如，如果所需的最大并发性设置为1，则会为每个新请求旋转一个Kubernetes pod。

在资源节约方面，Knative Serving确保休眠应用程序被缩放为零，并为下一个请求做好准备。

以下是使用Knative Serving的简单应用程序部署示例：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
 name: helloworld-go
 namespace: default
spec:
 template:
   spec:
     containers:
       - image: docker.io/jmprusi/helloworld-go
         env:
           - name: TARGET
             value: "Go Sample v1"

正如您所看到的，这是一个“Hello，world”应用程序。我们只需要定义容器映像和所需的环境变量。我们不需要定义服务、部署或选择器。有关更多详细信息，请参见Knative API规范。

Kourier是什么？

与Istio一样，Kourier是一个基于Envoy网关的轻量级入口，没有额外的自定义资源定义（CRD）。它由两部分组成：

• Kourier网关是Envoy，使用连接回Kourier控制平面的基本引导配置运行。
• Kourier控制平面处理Knative入口对象，并使Envoy配置保持最新。
   

Kourier的工作原理

Kourier会执行以下操作：

• 读取由Knative Serving创建的入口对象。
• 将这些对象转换为Envoy配置。
• 将配置暴露给它所管理的特使(Envoy)。

图1更详细地显示了Kourier如何与Knative Serving合作，将Knative应用程序暴露在网络中。

图1。Kourier在Knative Serving工作流程中。

在Knative Serving中部署新服务时，它会创建一个Ingress对象，该对象包含有关如何公开服务的信息。ingress对象包括以下元素：

• 主机、路径和标头：这些元素与传入请求中包含的相同元素相匹配。当存在匹配时，我们知道应该将请求代理到与ingress对象相关联的Knative服务。
• 拆分：我们使用拆分来在已部署服务的不同修订版之间划分传入流量。
• 可见性：定义应该从群集中还是从外部访问服务。
• 传输层安全性（TLS）：指定Red Hat OpenShift机密，该机密包含使用HTTPS公开服务所需的证书和密钥。

Kourier订阅由Knative Serving管理的入侵变化。每次创建、删除或修改入口时，Kourier都会收到通知。当这种情况发生时，Kourier会分析入口中的信息，并将信息转换为Envoy配置中的对象。Envoy配置可能很复杂，但集群和路由是它们所包含的两个对象。集群是属于同一服务的Internet协议地址（IP）的集合。路由包含用于匹配给定请求的所有信息：主机、路径、标头等。路由还可以指定匹配时请求应转到哪个群集代理。

在将入口转换为Envoy配置中的对象后，我们可以使用Envoy-xDS API将该配置公开给集群中的Envoy。Kourier管理集群。

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

需要注意的是，在所有这些过程中，Kourier并没有创建任何只有它才能理解的自定义资源。相反，Kourier只处理由Knative Serving（入口）管理的对象，以及由Kubernetes管理的对象——比如端点、机密（包括TLS配置的那些）等等。这就是为什么我们说Kourier是一个“Knative原生”入口。

Kourier与Knative的集成

作为Knative本地人，Kourier是一个符合Knative的入口。我们的意思是，当使用Kourier时，Knative Serving的所有功能都能很好地工作。其中包括服务的不同版本之间的流量划分、TLS、超时、重试、扩展服务时的自动端点发现等等。

为了确保Kourier是一致的，并支持添加到Knative Serving的每一个新功能，我们配置了一个运行Knative Serving一致性测试套件的连续集成（CI）系统。正如您从测试网格中看到的，Kourier是少数几个一致通过套件中所有测试的Knative入口实现之一。

与Kourier一起使用Envoy外部授权过滤器

可以将Kourier配置为使用Envoy外部授权过滤器进行流量授权。对于每个传入的请求，Kourier都会联系外部服务，以检查该请求是否应获得授权。如果获得授权，Kourier将代理请求到适当的服务。如果不是，它将向调用者返回一个错误。使用此功能的一种方法是基于开放策略代理（OPA）框架构建服务。OPA支持Envoy的外部授权协议，并允许我们使用专门为编写授权策略而设计的高级语言定义授权规则。

开始使用Kourier

如果您正在使用OpenShift，您可以在操作员目录中找到Red Hat OpenShift无服务器操作员。无服务器操作员会自动安装Kourier。（有关安装详细信息，请参阅安装OpenShift Serverless Operator。）

或者，您可以在已经运行Knative Serving的集群中安装Kourier。在这种情况下，只需输入：

$ kubectl apply --filename https://github.com/knative/net-kourier/releases/download/v0.15.0/kourier.yaml

注意：将版本号（在本例中为v0.15.0）替换为要安装的版本。

以下是将Knative配置为使用Kourier的代码：

kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"ingress.class":"kourier.ingress.networking.knative.dev"}}'

这应该足够开始了。有关更复杂的安装，请参阅Knative文档中的安装说明。

结论

正如我们在本文开头提到的，Knative最近被Kourier采用，因此它是目前支持的Knative Serving实现之一。查看Knative项目下Kourier的GitHub存储库。