第 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-controllernet-istio-controllerknative-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 启动为止。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat