第 5 章 Kourier 和 Istio ingresses

OpenShift Serverless 支持以下两个入口解决方案：

  • Kourier
  • Istio 使用 Red Hat OpenShift Service Mesh

默认为 Kourier。

5.1. Kourier 和 Istio ingress 解决方案

5.1.1. Kourier

Kourier 是 OpenShift Serverless 的默认入口解决方案。它有以下属性：

  • 它基于 envoy 代理。
  • 它很简单且轻量级。
  • 它提供 Serverless 需要提供其一组功能的基本路由功能。
  • 它支持基本可观察性和指标。
  • 它支持 Knative Service 路由的基本 TLS 终止。
  • 它仅提供有限的配置和扩展选项。

5.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"部分。

5.1.3. 流量配置和路由

无论您使用 Kourier 或 Istio，Knative Service 的流量都会通过 net-kourier-controller 或 net-istio-controller 在 knative-serving 命名空间中进行配置。

控制器读取 KnativeService 及其子自定义资源来配置入口解决方案。两个入口解决方案都提供一个作为流量路径一部分的入口网关 pod。两个入口解决方案都基于 Envoy。默认情况下，Serverless 对每个 KnativeService 对象有两个路由：

  • 由 OpenShift 路由器转发的 cluster-external 路由，如 myapp-namespace.example.com。
  • 包含集群域的 cluster-local 路由，如 myapp.namespace.svc.cluster.local。这个域可以用来从 Knative 或其他用户工作负载调用 Knative 服务。

ingress 网关可以在服务模式或代理模式中转发请求：

  • 在服务模式中，请求直接进入 Knative 服务的 Queue-Proxy sidecar 容器。
  • 在代理模式中，请求首先通过 knative-serving 命名空间中的 Activator 组件。

选择模式取决于 Knative、Knative 服务和当前流量的配置。例如，如果 Knative Service 缩减为零，则请求将发送到 Activator 组件，该组件充当缓冲区，直到新的 Knative 服务 pod 启动为止。