Kourier 和 Istio Ingress
OpenShift Serverless 支持以下两种入口解决方案
-
Kourier
-
使用 Red Hat OpenShift Service Mesh 的 Istio
默认值为 Kourier。
Kourier 和 Istio 入口解决方案
Kourier
Kourier 是 OpenShift Serverless 的默认入口解决方案。它具有以下特性：
-
它基于 envoy 代理。
-
它简单轻量。
-
它提供 Serverless 需要提供其功能集的基本路由功能。
-
它支持基本的可观测性和指标。
-
它支持 Knative 服务路由的基本 TLS 终止。
-
它只提供有限的配置和扩展选项。
使用 OpenShift Service Mesh 的 Istio
使用 Istio 作为 OpenShift Serverless 的入口解决方案可以启用基于 Red Hat OpenShift Service Mesh 提供的额外功能集：
-
所有连接之间的原生 mTLS
-
无服务器组件是服务网格的一部分
-
额外的可观测性和指标
-
授权和身份验证支持
-
自定义规则和配置，由 Red Hat OpenShift Service Mesh 支持
但是，这些附加功能会带来更高的开销和资源消耗。详情请参阅 Red Hat OpenShift Service Mesh 文档。
有关 Istio 的要求和安装说明，请参阅 Serverless 文档的“将 Service Mesh 与 OpenShift Serverless 集成”部分。
流量配置和路由
无论您使用 Kourier 还是 Istio，Knative 服务的流量都分别由 `knative-serving` 命名空间中的 `net-kourier-controller` 或 `net-istio-controller` 配置。
控制器读取 `KnativeService` 及其子自定义资源以配置入口解决方案。两种入口解决方案都提供一个成为流量路径一部分的入口网关 Pod。两种入口解决方案都基于 Envoy。默认情况下，Serverless 为每个 `KnativeService` 对象提供两条路由：
-
**集群外部路由**，由 OpenShift 路由器转发，例如 `myapp-namespace.example.com`。
-
**集群本地路由**，包含集群域，例如 `myapp.namespace.svc.cluster.local`。此域可以并且应该用于从 Knative 或其他用户工作负载调用 Knative 服务。
入口网关可以在服务模式或代理模式下转发请求：
-
在服务模式下，请求直接进入 Knative 服务的 Queue-Proxy 侧车容器。
-
在代理模式下，请求首先通过 `knative-serving` 命名空间中的 Activator 组件。
模式的选择取决于 Knative、Knative 服务和当前流量的配置。例如，如果 Knative 服务缩放到零，则请求将发送到 Activator 组件，该组件充当缓冲区，直到启动新的 Knative 服务 Pod。