网关

本页面介绍了使用 GKE Gateway Controller 的 Kubernetes Gateway API 的 Google Kubernetes Engine (GKE) 实现。

本页面适用于为组织设计和架构网络的云架构师和网络专家。如需详细了解我们在 Google Cloud 内容中提及的常见角色和示例任务，请参阅常见的 GKE Enterprise 用户角色和任务。

Gateway API 是面向服务网络的开源标准。Gateway API 会优化 Ingress 资源，并通过以下方式对其进行改进：

  • 面向角色：网关由与集群运营商、开发者和基础架构提供商组织角色相对应的 API 资源组成。这允许集群运营人员定义许多不同非协调开发者团队如何使用共享基础架构。

  • 可移植：Gateway API 是一种开源标准，有很多实现方案。它采用灵活一致性的概念设计，促进了高度可移植的核心 API（如 Ingress），它仍然具有灵活性和可扩展性，以支持环境和实现的原生功能。这使概念和核心资源在不同实现和环境中保持一致，从而降低复杂性并提高用户熟悉性。

  • 富有表现力：Gateway API 资源可以为基于标头的匹配、流量加权和其他只能在 Ingress 中通过自定义注解实现的功能提供内置功能。

Gateway API 资源

Gateway API 是一种以角色为导向的资源模型，专为与 Kubernetes 网络进行交互的角色而设计。如下图所示，此模型采用了一种能够为平台管理员集中处理政策和控制措施的方法，让不同的非协调服务所有者能够安全地共享同一底层网络基础架构。

GKE 提供了网关级别。集群运营商会根据这些级别创建网关资源。应用开发者创建绑定到网关资源的 HTTPRoute 资源。
图：Gateway API 概览

Gateway API 包含以下资源类型：

  • GatewayClass：定义集群范围的资源以作为在集群中创建负载均衡器的模板。GKE 提供可在 GKE 集群中使用的 GatewayClass。
  • Gateway：定义负载均衡器监听流量的位置和方式。集群运营商根据 GatewayClass 在其集群中创建网关。GKE 会创建负载均衡器，用于实现 Gateway 资源中定义的配置。
  • HTTPRoute：定义用于将请求从网关路由到 Kubernetes 服务的特定于协议的规则。GKE 支持 HTTPRoute 以用于基于 HTTP(S) 的流量路由。应用开发者会创建 HTTPRoute 以使用网关公开其 HTTP 应用。
  • 政策：定义网关资源的一组特定于实现的特征。您可以将政策附加到网关、路由或 Kubernetes Service。

GatewayClass

GatewayClass 是一种为 Kubernetes 集群中的 HTTP(S)（级别 7）负载均衡器定义模板的资源。GKE 会提供 GatewayClass 作为集群范围的资源。集群运营人员会在其集群中创建网关时指定 GatewayClass。

不同的 GatewayClass 对应于不同的 Google Cloud 负载均衡器。根据 GatewayClass 创建 Gateway 时，系统会创建相应的负载均衡器来实现指定的配置。

下表列出了 GKE 集群中可用的 GatewayClass 及其底层负载均衡器类型。如需了解 GatewayClass 的完整详情，请参阅 GatewayClass 功能和规范。

GatewayClass 名称 说明
gke-l7-regional-external-managed 基于区域级外部应用负载均衡器构建的区域外部应用负载均衡器
gke-l7-rilb 基于内部应用负载均衡器构建的内部应用负载均衡器

每个 GatewayClass 存在底层负载平衡器的限制。

网关

集群运营人员会创建 Gateway 来定义负载均衡器监听流量的位置和方式。网关从其关联的 GatewayClass 获取其行为（即实现方式）。

网关规范包括网关的 GatewayClass，该类可监听端口和协议以及哪些路由可绑定到网关。网关会根据路由元数据选择路由；具体是 Route 资源的种类、命名空间和标签。

如需查看部署 Gateway 的示例，请参阅部署 Gateway。

HTTPRoute

HTTPRoute 定义如何将网关接收的 HTTP 和 HTTPS 请求定向到 Service。应用开发者会创建 HTTPRoute 来通过网关公开其应用。

HTTPRoute 指定了可从中路由流量的网关、将服务路由到哪些 Service，以及定义 HTTPRoute 所匹配的流量的规则。网关和路由绑定是双向的，这意味着这两个资源必须相互选择才能绑定。HTTPRoutes 可以根据请求标头中的详细信息匹配请求。

政策

政策定义了网关资源的特征（通常是特定于实现的），集群运营者可以将政策附加到网关、路由或 Kubernetes Service。政策定义底层 Google Cloud 基础架构的运行方式。

政策通常附加到命名空间，可以引用同一命名空间中的资源，并使用 RBAC 授予访问权限。Gateway API 的分层特性使您可以将政策附加到命名空间中的顶层资源 (Gateway)，并让不同命名空间中该顶层资源下的所有资源都能接收该政策的特征。

GKE Gateway Controller 支持以下政策：

  • HealthCheckPolicy：定义用于检查后端 Pod 的健康状态的健康检查的参数和行为。
  • GCPGatewayPolicy：定义 Google Cloud 负载均衡器前端的特定参数。这类似于 Ingress 资源的 FrontendConfig。
  • GCPBackendPolicy：定义负载均衡器的后端服务应如何将流量分配到端点。这类似于 Ingress 资源的 BackendConfig。

网关所有权和使用模式

网关和路由资源让它们在组织内拥有和部署方式非常灵活。这意味着单个负载均衡器可以由基础架构团队进行部署和管理，但特定网域或路径下的路由可以委派给另一个 Kubernetes 命名空间中的其他团队。GKE Gateway Controller 支持负载均衡器的多租户使用，以及跨命名空间、集群和区域进行共享。如果需要更多分布式所有权，也不必共享网关。以下是 GKE 中网关的一些最常见的使用模式。

自行管理的网关

单个所有者可以仅为自己的应用部署网关和路由，并且以独占的方式使用它们。以这种方式部署的网关和路由类似于 Ingress。下图展示了部署和管理自己网关的两个不同的服务所有者。与 Ingress 类似，每个网关都对应着自己唯一的 IP 地址和负载均衡器。TLS、路由和其他政策完全由服务所有者控制。

单个所有者可以完全控制网关和路由

这种使用模式对于 Ingress 很常见，但由于缺少共享资源，在跨多个团队时很难扩缩。Gateway API 资源模型提供了以下使用模式，可为分布式控制和所有权提供各种选项。

每个命名空间的平台管理网关

通过分离网关和路由资源，平台管理员可以代表服务所有者来控制网关。平台管理员可以按命名空间或团队来部署网关，可以为该命名空间授予以独占方式使用网关的权限。这样，服务所有者便可完全控制路由规则，不存在与其他团队发生冲突的风险。这样，平台管理员可以控制 IP 分配、端口公开、协议、网域和 TLS 等方面。平台管理员还可以决定团队可以使用哪些类型的 Gateway，例如内部或外部 Gateway。此使用模式可明确区分不同角色的责任。

利用跨命名空间路由，路由能够跨命名空间边界连接到网关。网关可以限制哪些命名空间中的路由能够建立连接。同样，路由指定它们连接到的网关，但它们只能连接到允许路由的命名空间的网关。这种双向连接可以灵活控制每一端，从而实现使用模式的多样化。

在下图中，平台管理员已部署一个网关，用于对每个命名空间进行独占式访问。例如，已配置 store 网关，以便只有来自 store 命名空间的路由才能连接到该网关。每个网关代表一个唯一的负载均衡 IP 地址，因此允许每个团队按照网关为其选择的任何网域或路由部署任意数量的路由。

每个命名空间的网关都提供对该命名空间的独占式网关访问权限。

每个集群的共享网关

跨命名空间共享网关可为平台管理员提供更集中的所有权形式。这样，在不同命名空间中运行的不同服务所有者可以共享同一 IP 地址、DNS 网域、证书或路径，从而在服务之间实现精细路由。利用网关，平台管理员可以控制为特定网域路由哪些命名空间。这与前一个示例相似，但网关允许来自多个命名空间的路由连接。

在下图中，平台管理员已将两个网关部署到 infra 命名空间。external 网关允许来自 web 和 mobile 命名空间的路由连接到网关。来自 accounts 命名空间的路由不能使用 external 网关，因为 accounts 命名空间仅适用于内部服务。internal 网关允许内部客户端使用专用 IP 地址在 VPC 内进行私密通信。

每个集群的网关允许集群内的不同命名空间共享一个网关

m.example.com 网域委派给 mobile 命名空间，该命名空间允许移动服务所有者在 m.example.com 网域下配置所需的任何路由规则。这使得服务所有者可以在不请求管理员更改的情况下更好地控制新 API 端点的引入并控制流量。

GKE Gateway Controller

GKE 单集群 Gateway 控制器会监控 Gateway API 资源的 Kubernetes API，并协调 Cloud Load Balancing 资源，以实现 Gateway 资源指定的网络行为。

单集群 Gateway 控制器不是网络数据平面，不会处理任何流量。

下图显示了单集群 GKE Gateway Controller 的架构。使用的底层控制器取决于所部署 Gateway 的 GatewayClass。

单集群 Gateway 控制器为 GKE 部署和管理负载均衡器，但不处理网络流量。

控制器 单集群网关控制器
管理者 Google Cloud
集群范围 单集群网关
部署位置 在其 GKE 集群所在的区域内按区域部署。
启用方式 默认在 GKE 中启用。
支持的 GatewayClasses
  • gke-l7-regional-external-managed GA
  • gke-l7-rilb GA

Ingress 和网关

Ingress 和网关的比较

网关和 Ingress 都是用于路由流量的开源标准。网关由 Kubernetes 社区设计，吸取了从 Ingress 和服务网格生态系统中吸取的经验教训。Gateway 是 Ingress 的下一代产品，提供与 Ingress 功能相同的功能。这两种 Gateway 可同时使用，且不会发生冲突。但随着时间的推移，Gateway 和路由资源将提供 Ingress 中不提供的更多功能，从而吸引用户在之前可能使用过 Ingress 的地方开始使用 Gateway。

在 GKE 中，所有 Ingress 资源都可以直接转换为 Gateway 和 HTTPRoute 资源。单个 Ingress 同时对应着网关（用于前端配置）和 HTTPRoute（用于路由配置）。以下示例展示了对应的网关和 HTTPRoute 配置。请注意，网关和 HTTPRoute 资源可以由不同的用户分别创建。网关可以有多个路由，而一个路由也可以连接到多个网关。网关和路由之间的关系如网关使用模式中所述。

入站流量

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "gce-internal"
spec:
  rules:
  - host: "example.com"
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: site
            port:
              number: 80
      - pathType: Prefix
        path: /shop
        backend:
          service:
            name: store
            port:
              number: 80

网关

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute

路线

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        value: /
    backendRefs:
    - name: site
      port: 80
  - matches:
    - path:
        value: /shop
    backendRefs:
    - name: store
      port: 80

后续步骤