跳到内容

用例

网关 API 涵盖了非常广泛的用例（这既是优势，也是劣势！）。此页面决不旨在提供这些用例的详尽列表：相反，它旨在提供一些示例，这些示例可以帮助演示 API 的使用方法。

在所有情况下，请务必牢记网关 API 中使用的角色和人员。此处介绍的用例在Ana、Chihiro 和Ian 的描述中故意使用：他们正是 API 必须对他们可用的人员。（同样重要的是要记住，即使这些角色可能由同一个人担任，尤其是在规模较小的组织中，他们都有不同的关注点，我们需要分别考虑。）

用例

基本的南北向 用例

从 v0.8.0 开始的标准通道

自 v0.8.0 以来，标准通道完全支持南北向 用例。有关发布通道的更多信息，请参阅我们的版本控制指南。

Ana 创建了一个微服务应用程序，她希望在 Kubernetes 中运行该应用程序。她的应用程序将由集群外部的客户端使用，虽然 Ana 创建了该应用程序，但设置集群不在她的能力范围内。

  1. Ana 找到 Chihiro，要求他们设置一个集群。Ana 告诉 Chihiro，她的客户希望她的 API 使用以 https://ana.application.com/ 为根的 URL 来访问。

  2. Chihiro 找到 Ian 并请求一个集群。

  3. Ian 提供了一个运行网关控制器的集群，该控制器具有名为 basic-gateway-class 的GatewayClass 资源。网关控制器管理与将集群外部的流量路由到集群内部相关的基础设施。

  4. Ian 向 Chihiro 提供新集群的凭据，并告诉 Chihiro 他们可以使用 GatewayClass basic-gateway-class 来设置东西。

  5. Chihiro 将名为 ana-gateway 的Gateway 应用于集群，告诉它侦听端口 443 以获取 TLS 流量，并为它提供具有主题 CN ana.application.com 的 TLS 证书。他们将此网关与 basic-gateway-class GatewayClass 关联。

  6. Ian 在步骤 3 中提供的网关控制器为 ana-gateway 分配了一个负载均衡器和一个 IP 地址，配置了可以路由到达负载均衡器端口 443 的请求的数据平面组件，并开始监视与 ana-gateway 关联的路由资源。

  7. Chihiro 获取 ana-gateway 的 IP 地址，并在集群外部创建 ana.application.com 的 DNS 记录以匹配。

  8. Chihiro 告诉 Ana，她可以使用名为 ana-gateway 的网关来访问。

  9. Ana 编写并应用HTTPRoute 资源来配置允许哪些 URL 路径以及哪些微服务应该处理它们。她使用网关 API 路由附加过程 将这些 HTTPRoute 与网关 ana-gateway 关联。

  10. 此时，当请求到达负载均衡器时，它们会根据 Ana 的路由规范路由到 Ana 的应用程序。

这使 Chihiro 能够在网关处执行集中式策略，例如 TLS，同时允许 Ana 和她的同事控制应用程序的路由逻辑 和部署计划（例如，流量拆分部署）。

单个网关后的多个应用程序

从 v0.8.0 开始的标准通道

自 v0.8.0 以来，标准通道完全支持南北向 用例。有关发布通道的更多信息，请参阅我们的版本控制指南。

这与基本的南北向用例 非常相似，但有多个应用程序团队：Ana 和她的团队在 store 命名空间中管理一个商店应用程序，而 Allison 和她的团队在 site 命名空间中管理一个网站。

  • Ian 和 Chihiro 共同为上述内容提供了集群、GatewayClass 和 Gateway。

  • Ana 和 Allison 独立部署绑定到同一个 Gateway 资源的工作负载和 HTTPRoute。

同样，这种关注点的分离使 Chihiro 能够在网关处执行集中式策略，例如 TLS。同时，Ana 和 Allison 在他们自己的命名空间中运行他们的应用程序，在他们自己的命名空间中，但将他们的路由附加到同一个共享网关，允许他们独立控制他们的路由逻辑、流量拆分部署 等，而无需担心 Chihiro 和 Ian 处理的事情。

Gateway API Roles

基本的东向/西向 用例

在这种情况下，Ana 构建了一个工作负载，该工作负载已在具有与GAMMA 兼容的服务网格 的集群中运行。她希望使用网格通过拒绝对她的工作负载进行具有不正确 URL 路径的调用以及在任何人都对她的工作负载进行请求时强制执行超时来保护她的工作负载。

  • Chihiro 和 Ian 已经提供了运行服务网格的集群。Ana 不需要向他们发出任何请求。

  • Ana 编写了一个 HTTPRoute，该路由定义可接受的路由和超时，并且具有她工作负载的 Service 的 parentRef。

  • Ana 在与她的工作负载相同的命名空间中应用了她的 HTTPRoute。

  • 网格会自动开始强制执行 Ana 的 HTTPRoute 中描述的路由策略。

在这种情况下，跨角色的关注点分离使 Ana 能够利用服务网格，使用自定义路由逻辑，而不会对 Chihiro 或 Ian 的请求造成任何瓶颈。

网关和网格用例

这实际上是单个网关后的多个应用程序 和基本的东向/西向 用例的组合。

  • Chihiro 和 Ian 将提供一个集群、一个GatewayClass 和一个Gateway。

  • Ana 和 Allison 将在适当的命名空间中部署他们的应用程序。

  • Ana 和 Allison 然后将根据需要应用 HTTPRoute 资源。

但是，由于涉及网格，因此在这种情况下有两个非常重要的变化

  1. 如果千寻已部署了一个默认使用 网关控制器 的 服务路由，他们可能需要将其重新配置为 端点路由。（这是 GAMMA 的一个持续进行的工作领域，但预期端点路由将成为推荐方案。）

  2. 安娜和/或艾莉森需要将 HTTPRoutes 绑定到他们各自工作负载的服务，以配置网格路由逻辑。这些可以是仅针对网格的独立 HTTPRoutes，也可以是绑定到网关和服务的单个 HTTPRoutes。

与以往一样，以这种方式将关注点分离的最终目的是允许千寻在网关处强制执行集中式策略，例如 TLS，同时允许安娜和艾莉森独立控制 路由逻辑、流量拆分发布 等，无论对于 南北 还是 东西 路由。