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