1 跨命名空间路由

Gateway API 具有跨命名空间路由的核心支持。当多个用户或团队共享底层网络基础设施时，这很有用，但必须对控制和配置进行分段，以尽量减少访问和容错域。

Gateway 和 Route(HTTPRoute,TCPRoute,GRPCRoute) 可以部署到不同的命名空间中，路由可以跨命名空间边界连接到网关。本指南探讨了路由附件，并演示了独立团队如何安全地共享同一网关。

在本指南中，有两个独立的团队，store 和 site，在同一个Kubernetes集群中的 store-ns 和 site-ns Namespaces 中运行。

这些是他们的目标，以及他们如何使用Gateway API资源来实现这些目标：

• store 团队有两个应用程序，home(/) 和 login(/login)。该团队希望尽可能地隔离应用程序之间的访问和配置，以尽量减少访问和故障域。它们使用连接到同一 Gateway 的单独HTTPRoutes来隔离路由配置，如金丝雀部署，但仍然共享相同的IP地址、端口、DNS域和TLS证书。

• store 团队在 store-ns 命名空间中部署了一个名为 store 的 Service，该 Service 也需要在相同的IP地址和域后面公开。

• Foobar 公司为所有应用程序提供 foo.example.com 域名。这是由一个在infrans命名空间中运行的中央基础设施团队控制的。

• 最后，安全团队控制 foo.example.com 的证书。通过单一共享网关管理此证书，他们能够集中控制安全性，而无需直接涉及应用程序团队。

Gateway API资源之间的逻辑关系如下所示：

1.1 跨命名空间路由连接

路由连接是一个重要的概念，它规定了路由如何连接到网关并对其路由规则进行编程。当命名空间中的路由共享一个或多个网关时，这一点尤其重要。网关和路由连接是双向的——只有网关所有者和路由所有者都同意这种关系，连接才能成功。这种双向关系的存在有两个原因：

• 路由所有者不想通过他们不知道的路径过度暴露他们的应用程序。

• 网关所有者不希望某些应用程序或团队在未经许可的情况下使用网关。例如，内部服务不应该通过互联网网关访问。

网关支持连接约束，这些约束是网关侦听器上的字段，用于限制可以连接的路由。网关支持命名空间和路由类型作为附件约束。任何不符合连接约束的路由都无法连接到该网关。同样，Routes通过Route的parentRef字段明确引用它们想要连接的网关。这些共同创建了基础设施所有者和应用程序所有者之间的握手，使他们能够独立定义应用程序如何通过网关公开。这实际上是一种减少管理开销的策略。应用程序所有者可以指定其应用程序应使用的网关，基础设施所有者可以限制网关接受的命名空间和路由类型。

1.2 共享网关

基础设施团队将 Gateway shared-gateway 部署到 infra-ns 命名空间中：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
  namespace: infra-ns
spec:
  gatewayClassName: shared-gateway-class
  listeners:
  - name: https
    hostname: "foo.example.com"
    protocol