42.Gateway API

Gateway API

注意

本文根据Gateway API 0.5.1版本撰写。目前Gateway API仅用于处理Kubernetes集群中的南北向(入口)流量,未来也有可能处理集群内(东西向)流量。关于使用Gateway API处理东西向流量的提议详见此文档

除了直接使用ServiceIngress之外,Kubernetes社区还发起了 Gateway API项目,它可以帮助我们将Kubernetes中的服务暴露到集群外。

Gateway API是一个由 SIG-NETWORK 管理的开源项目。该项目的目标是在Kubernetes生态系统中发展服务网络APIGateway API提供了暴露Kubernetes应用的资源——GatewayClassGatewayHTTPRouteTCPRoute 等。

Gateway API已经得到了大量的网关和服务网格项目支持,请在Gateway官方文档中查看支持状况

目标

Gateway API旨在通过提供表现性的、可扩展的、面向角色的接口来改善服务网络,这些接口由许多厂商实现,并得到了业界的广泛支持。

Gateway API是一个API资源的集合 —— GatewayClassGatewayHTTPRouteTCPRoute 等。使用这些资源共同为各种网络用例建模。

下图中展示的是Kubernetes集群中四层和七层的网络配置。从图中可以看到通过将这些资源对象分离,可以实现配置上的解耦,由不同角色的人员来管理,而这也是Gateway API的相较于Ingress的一大特色。

Kubernetes Gateway API 简介

Gateway APIIngress有什么不同?

Ingress的主要目标是用简单的、声明性的语法来暴露HTTP应用。Gateway API暴露了一个更通用的代理API,可以用于更多的协议,而不仅仅是HTTP,并为更多的基础设施组件建模,为集群运营提供更好的部署和管理选项。

Gateway相较于Ingress做了哪些改进?

以下是Gateway APIIngress的改进点。

更具表现力

Gateway表达了更多的核心功能,比如基于头的匹配、流量加权和其他功能,而这些功能在Ingress中只能通过自定义方式实现。

更具扩展性

Gateway API允许在API的各个层次上链接自定义资源。这就允许在API结构的适当位置进行更精细的定制。

面向角色

它们被分离成不同的API资源,这些资源映射到Kubernetes上运行应用程序的常见角色。

通用性

这不是一种改进,而是应该保持不变。正如Ingress是一个具有众多实现的通用规范一样,Gateway API被设计成一个由许多实现支持的可移植规范。

共享网关

它们允许独立的路由资源绑定到同一个网关,从而实现负载均衡器和VIP的共享。这允许团队安全地共享基础设施,而不需要直接协调。

类型化后端引用

通过类型化后端引用,Routes可以引用Kubernetes服务,也可以引用任何一种被设计为Gateway后端的Kubernetes资源。

跨命名空间引用

跨越不同Namespaces的路由可以绑定到网关。这样,尽管对工作负载进行了命名空间划分,但仍可共享网络基础设施。

GatewayClass 将负载均衡实现的类型形式化。这些类使用户可以很容易和明确地了解资源模型本身有什么样的能力。

在了解了Gateway API的目的后,接下来我们再看下它的资源模型、请求流程、TLS配置及扩展点等。

角色划分

Gateway API开发者为其使用场景定义四类角色:

  • 基础设施提供方:如AWSGKE
  • 集群运维:管理整个集群的计算、存储、网络、安全等
  • 应用程序开发者:为自己开发的应用负责,管理应用的健壮性
  • 应用管理员:不是所有的公司都有,通常在一些复杂系统中会有专门的应用管理员

Gateway API通过Kubernetes服务网络的面向角色的设计在分布式灵活性和集中控制之间取得了平衡。使得许多不同的非协调团队可以使用共享网络基础设施(硬件负载均衡器、云网络、集群托管代理等,所有团队都受集群运维设置的策略约束。下图展示了在进行Gateway管理时的角色划分。

Gateway 管理中的角色划分(图片来自:https://gateway-api.sigs.k8s.io/)

集群运维人员创建从 GatewayClass 派生的 Gateway 资源。此Gateway部署或配置它所代表的底层网络资源。通过GatewayRoute之间的路由附加进程 ,集群运维人员和特定团队必须就可以附加到此Gateway并通过它公开其应用程序的内容达成一致。集群运维人员可以在网关上实施 TLS 集中式策略。同时,StoreSite团队在他们自己的Namespaces运行,但是将他们的Routes附加到同一个共享Gateway,允许他们独立控制自己的路由逻辑。这种关注点分离允许Store队管理自己的流量拆分部署,同时将集中策略和控制权留给集群运维人员。

这种灵活性技能保持API的标准和可移植性,还使其可以适应截然不同的组织模型和实现。

资源模型

注意:资源最初将作为CRD存在于networking.x-k8s.ioAPI组中。未限定的资源名称将隐含在该API组中。

Gateway API的资源模型中,主要有三种类型的对象:

  • GatewayClass:定义了一组具有共同配置和行为的网关。
  • Gateway:流量请求端点,流量从这里被翻译成集群内的服务。
  • Route:描述了通过Gateway而来的流量如何映射到服务。

GatewayClass

GatewayClass 定义了一组共享共同配置和行为的Gateway,每个 GatewayClass 由一个控制器处理,但控制器可以处理多个 GatewayClass

GatewayClass 是一个集群范围的资源。必须至少定义一个 GatewayClassGateway 才能够生效。实现Gateway API的控制器通过关联的 GatewayClass 资源来实现,用户可以在自己的 Gateway 中引用该资源。

这类似于 IngressIngressClassPersistentVolumesStorageClass。在Ingressv1beta1中,最接近 GatewayClass 的是 ingress-class 注解,而在Ingress V1中,它的作用与 IngressClass 一样。

下面是一个 GatewayClass 的配置示例。

kind: GatewayClass
metadata:
  name: cluster-gateway
spec:
  controllerName: "example.net/gateway-controller"

GatewayClass 一般由基础设施提供商来创建,用户不需要关注控制器如何实现,只需要了解该 GatewayClass 创建的对应 Gateway 的属性即可。

Gateway API的提供者还可以开放了一部分参数配置给网关管理员,管理员可以使用 GatewayClass.spec.parametersRef 字段来配置:

kind: GatewayClass
metadata:
  name: internet
spec:
  controllerName: "example.net/gateway-controller" # 该字段的值应为集群唯一的
  parametersRef:
    group: example.net/v1alpha1
    kind: Config
    name: internet-gateway-config
---
apiVersion: example.net/v1alpha1
kind: Config
metadata:
  name: internet-gateway-config
spec:
  ip-address-pool: internet-vips
  ...

建议使用 GatewayClass.spec.parametersRef 自定义资源配置,不过你也可以使用ConfigMap

在刚部署GatewayClass后,GatewayClass.status 中的状态类型为 Accepted 但是 statusFalse,控制器处理完配置后 status 将变为 True,如果在该过程中出现错误,那么会显示在状态中,如下所示。

kind: GatewayClass
...
status:
  conditions:
  - type: Accepted
    status: False
    Reason: BadFooBar
    Message: "foobar" is an FooBar.

Gateway

Gateway 描述了如何将流量翻译到集群内的服务。它定义了一个将流量从不了解Kubernetes的地方翻译到了解Kubernetes的地方的方法。例如,由云负载均衡器、集群内代理或外部硬件负载均衡器发送到Kubernetes服务的流量。虽然许多用例的客户端流量源自集群的 “外部”,但这并不是必需的。

Gateway 定义了对实现 GatewayClass 配置和行为约定的特定负载均衡器配置的请求。该资源可以由运维人员直接创建,也可以由处理 GatewayClass 的控制器创建。

由于 Gateway 规范捕获了用户意图,它可能不包含规范中所有属性的完整规范。例如,用户可以省略地址、端口、TLS设置等字段。这使得管理 GatewayClass 的控制器可以为用户提供这些缺省设置,从而使规范更加可移植。这种行为将通过 GatewayClass 状态对象来明确。

一个 Gateway 可以包含一个或多个 Route 引用,这些 Route 引用的作用是将一个子集的流量引导到一个特定的服务上。

Gateway 规范中定义了以下内容:

  • GatewayClassName:定义此网关使用的 GatewayClass 对象的名称。
  • Listeners:定义主机名、端口、协议、终止、TLS设置以及哪些路由可以附加到监听器。
  • Addresses:定义为此Gateway请求的网络地址。

如果以上规范中的配置无法实现,Gateway将处于错误状态,状态条件中会显示详细信息。

下面展示的是使用 Envoy Gateway 生成的Gateway示例:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
            {"apiVersion":"gateway.networking.k8s.io/v1beta1","kind":"Gateway","metadata":{"annotations":{},"name":"eg","namespace":"default"},"spec":{"gatewayClassName":"eg","listeners":[{"name":"http","port":8080,"protocol":"HTTP"}]}}
  creationTimestamp: "2022-10-22T07:03:28Z"
  generation: 1
  name: eg
  namespace: default
  resourceVersion: "326707757"
  uid: 20f37614-1814-4c4a-b3ee-8d923a1a78f8
spec:
  gatewayClassName: eg
  listeners:
    - allowedRoutes:
        namespaces:
          from: Same
      name: http
      port: 8080
      protocol: HTTP
status:
  addresses:
    - type: IPAddress
      value: 11.11.11.11 # 如果 Envoy Gateway 部署在云上,云会创建一个 LoadBalancer 实例从而获得一个外部 IP,该 IP 为网关 IP
  conditions:
    - lastTransitionTime: "2022-10-22T07:03:28Z"
      message: The Gateway has been scheduled by Envoy Gateway
      observedGeneration: 1
      reason: Scheduled
      status: "True"
      type: Scheduled
    - lastTransitionTime: "2022-10-22T07:04:17Z"
      message: Address assigned to the Gateway, 1/1 envoy Deployment replicas available
      observedGeneration: 1
      reason: Ready
      status: "True"
      type: Ready
  listeners:
    - attachedRoutes: 1
      conditions:
        - lastTransitionTime: "2022-10-22T07:03:30Z"
          message: Listener is ready
          observedGeneration: 1
          reason: Ready
          status: "True"
          type: Ready
      name: http
      supportedKinds:
        - group: gateway.networking.k8s.io
          kind: HTTPRoute

从上面的示例中我们可以看到 status 中显示了Gateway的状态,如网关的IP地址,监听器上附着的路由以及更新时间。

Route

Route 对象定义了特定协议的规则,用于将请求从 Gateway 映射到Kubernetes服务。

v1alpha2开始,Gateway API中包含四种 Route 资源类型。对于其他协议,鼓励使用特定于实现的自定义路由类型。未来可能会向API添加新的路由类型。

注意

目前只有 HTTPRouteGateway API正式支持的,其他的路由类型还在实验中,详见版本文档

HTTPRoute

HTTPRoute 用于多路复用HTTP或终止的HTTPS连接。它适用于检查HTTP流并使用HTTP请求数据进行路由或修改的情况,例如使用HTTP Header进行路由或在运行中修改它们。

HTTPRoute的规范中包括:

  • parentRefs:定义此路由要附加到的Gateway
  • hostnames(可选:定义用于匹配HTTP请求的主机头的主机名列表。
  • rules:定义规则列表以针对匹配的HTTP请求执行操作。每条规则由 matchesfilters(可选)和 backendRefs(可选)字段组成。

下图展示了流量经过网关和HTTPRoute发送到服务中的过程。

流量经过网关和 HTTPRoute 到服务中的过程

TLSRoute

TLSRoute 用于多路复用TLS连接,通过SNI进行区分。它适用于使用SNI作为主要路由方法的地方,并且对HTTP等高级协议的属性不感兴趣。连接的字节流被代理,无需对后端进行任何检查。

TCPRouteUDPRoute

TCPRoute(和 UDPRoute)旨在用于将一个或多个端口映射到单个后端。在这种情况下,没有可用于在同一端口上选择不同后端的鉴别器(Discriminator,因此每个 TCPRoute 确实需要监听器上的不同端口。你可以终止TLS,在这种情况下,未加密的字节流被传递到后端。你可以选择不终止TLS,在这种情况下,加密的字节流被传递到后端。

GRCPRoute

GRPCRoute 用于路由gRPC流量。支持 GRPCRoute 的网关需要支持HTTP/2,而无需从HTTP/1进行初始升级,因此可以保证gRPC流量正常流动。

Route类型列表

下面的「路由鉴别器」一栏是指可以使用哪些信息来允许多个Routes共享Listener上的端口。

对象 OSI 路由鉴别器 TLS支持 目的
HTTPRoute 7 HTTP协议中的任何内容 仅终止 HTTPHTTPS路由
TLSRoute 4层和第7层之间的某个位置 SNI或其他TLS属性 直通或终止 TLS协议的路由,包括不需要检查HTTP流的HTTPS
TCPRoute 4 目的端口 直通或终止 允许将TCP流从Listener转发到Backends
UDPRoute 4 目的端口 没有任何 允许将UDP流从监听器转发到后端
GRPCRoute 7 gRPC协议中的任何内容 仅终止 基于HTTP/2HTTP/2明文的gRPC路由

请注意,通过 HTTPRouteTCPRoute 路由的流量可以在网关和后端之间进行加密(通常称为重新加密。无法使用现有的Gateway API资源对其进行配置,但实现可以为此提供自定义配置,直到Gateway API定义了标准化方法。

ReferenceGrant

注意

ReferenceGrant 资源仍在实验阶段,更多信息请参考版本文档

ReferenceGrant 可用于在Gateway API中启用跨命名空间引用。特别是,路由可能会将流量转发到其他命名空间中的后端,或者Gateway可能会引用另一个命名空间中的Secret

过去,我们已经看到跨命名空间边界转发流量是一种理想的功能,但如果没有 ReferenceGrant 之类的保护措施, 就会出现漏洞

如果从其命名空间外部引用一个对象,则该对象的所有者必须创建一个 ReferenceGrant 资源以显式允许该引用,否则跨命名空间引用是无效的。

将路由添加到网关

Route附加到Gateway表示在Gateway上应用的配置,用于配置底层负载均衡器或代理。Route如何以及哪些Route附加到Gateway由资源本身控制。RouteGateway资源具有内置控件以允许或限制它们的连接方式。组织可以同时利用Kubernetes RBAC,实施有关如何公开Route以及在公开在哪些Gateway上公开的策略。

如何将Route附加到网关以实现不同的组织策略和责任范围有很大的灵活性。下面是GatewayRoute可以具有的关系:

  • 一对一GatewayRoute可以由单个所有者部署和使用,具有一对一的关系。
  • 一对多Gateway可以绑定许多Route,这些Route由来自不同命名空间的不同团队拥有。
  • 多对一Route也可以绑定到多个Gateway,允许单个Route同时控制跨不同IP、负载均衡器或网络的应用程序。

路由绑定

Route 绑定到 Gateway 时,代表应用在 Gateway 上配置了底层的负载均衡器或代理。哪些 Route 如何绑定到 Gateway 是由资源本身控制的。RouteGateway 资源具有内置的控制,以允许或限制它们之间如何相互选择。这对于强制执行组织策略以确定 Route 如何暴露以及在哪些 Gateway 上暴露非常有用。请看下面的例子。

一个Kubernetes集群管理员在 Infra 命名空间中部署了一个名为 shared-gwGateway,供不同的应用团队使用,以便将其应用暴露在集群之外。团队A和团队B(分别在命名空间 “A” 和 “B” 中)将他们的 Route 绑定到这个 Gateway。它们互不相识,只要它们的 Route 规则互不冲突,就可以继续隔离运行。团队C有特殊的网络需求(可能是性能、安全或关键业务,他们需要一个专门的 Gateway 来代理。团队C在 “C” 命名空间中部署了自己的 Gateway specialive-gw,该Gateway只能由 “C” 命名空间中的应用使用。

不同命名空间及 GatewayRoute 的绑定关系如下图所示。

路由绑定示意图
路由绑定示意图

将路由附加到网关包括以下步骤:

  1. Route需要在其 parentRefs 字段中引用Gateway的条目;
  2. Gateway上至少有一个监听器允许其附加。

策略附件

策略附件(Policy Attachment)是一种自定义策略资源,例如超时、重试、健康检查等,这些功能在不同的网关实现中的细节各不相同个,为了Gateway API的可移植性,我们将这些工作作为插件附加到资源上。

附加到Gateway API资源和实施的策略必须使用以下方法来确保API实施之间的一致性。此模式包含三个主要组件:

  • 将策略附加到资源的标准化方法。
  • 支持在策略资源中配置默认值和覆盖值。
  • 用于说明默认值和覆盖值应如何交互的层次结构。

这种标准化不仅可以实现一致的模式,还可以让未来的工具(例如kubectl插件)能够可视化已应用于给定资源的所有策略。

你可以使用 targetRef 字段指定策略附件附加到的资源对象,例如下所示:

apiVersion: networking.acme.io/v1alpha1
kind: RetryPolicy
metadata:
  name: foo
spec:
  default:
    maxRetries: 5
  targetRef:
    group: networking.acme.io
    kind: ExternalService
    name: foo.com

该在例子中,为一个外部服务配置了一个重试策略。你可以给几乎任何可以发送、接收流量的对象附加策略,例如 GatewayClassGatewayServiceRouteNamespace ,不过附加策略的时候,需要注意其优先级。

策略优先级

你可以给策略附件指定 overridedefault 值,其在入口和网格内不同资源上的覆盖值和默认值的优先级是如下图所示。

Gateway API 的默认值和覆盖值的优先层级

从图中我们可以看到:

  • 覆盖值:上层覆盖下层

  • 默认值:下层覆盖上层

引用网关

Route可以通过在 parentRef 中指定命名空间(如果RouteGateway在同一个名称空间中则该配置是可选的)和Gateway的名称来引用GatewayRoute可以使用 parentRef 中的以下字段进一步选择Gateway下的监听器子集:

  1. SectionName:当设置了 sectionName 时,Route选择具有指定名称的监听器;
  2. Port:当设置了 port 时,Route会选择所有指定的监听端口且协议与此类Route兼容的监听器。

当设置了多个 parentRef 字段时,Route选择满足这些字段中指定的所有条件的监听器。例如,当 sectionNameport 两者都设置时,Route选择具有指定名称的监听器并在指定端口上监听。

限制路由附加

每个Gateway监听器都可以通过以下机制限制其可以附加的路由:

  1. Hostname:如果监听器上设置了 hostname ,附加路由的 hostnames 中必须至少有一个重叠值。
  2. Namespace:监听器上的 allowedRoutes.namespaces 字段可用于限制可以附加路由的位置。该 namespaces.from 字段支持以下值:
    • SameNamespace 是默认选项。只有与该网关相同的命名空间中的路由才会被选择。
    • All 可选择来自所有命名空间的 Route
    • Selector 意味着该网关将选择由Namespace标签选择器选择的Namespace子集的Route。当使用Selector时,那么 listeners.route.namespaces.selector 字段可用于指定标签选择器。AllSameNamespace 不支持该字段。
  3. Kind:监听器上的 allowedRoutes.kinds 字段可用于限制可能附加的路由种类。

如果未指定上述任何一项,网关监听器将信任从支持监听器协议的同一命名空间附加的路由。

Gateway - Route附加示例

在下面的例子中 gateway-api-example-ns1 命名空间中的my-routeRoute想要附加到 foo-gateway 中,不会附加到任何其他Gateway上。请注意, foo-gateway 位于与Gateway不同的命名空间中。foo-gateway 必须允许来自 gateway-api-example-ns2 命名空间中的HTTPRoute附加。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-route
  namespace: gateway-api-example-ns2
spec:
  parentRefs:
    - kind: Gateway
      name: foo-gateway
      namespace: gateway-api-example-ns1
  rules:
    - backendRefs:
        - name: foo-svc
          port: 8080

foo-gateway 允许my-routeHTTPRoute附加。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: foo-gateway
  namespace: gateway-api-example-ns1
spec:
  gatewayClassName: foo-lb
  listeners:
    - name: prod-web
      port: 80
      protocol: HTTP
      allowedRoutes:
        kinds:
          - kind: HTTPRoute
        namespaces:
          from: Selector
          selector:
            matchLabels:
              # 该 label 在 Kubernetes 1.22 中自动添加到所有命名空间中
              kubernetes.io/metadata.name: gateway-api-example-ns2

对于一个更宽松的示例,下面的网关将允许所有HTTPRoute资源从带有 expose-apps: true 标签的命名空间附加。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: gateway-api-example-ns1
spec:
  gatewayClassName: foo-lb
  listeners:
    - name: prod-web
      port: 80
      protocol: HTTP
      allowedRoutes:
        kinds:
          - kind: HTTPRoute
        namespaces:
          from: Selector
          selector:
            matchLabels:
              expose-apps: "true"

组合类型

GatewayClass、Gateway、xRouteService 的组合将定义一个可实现的负载均衡器。下图说明了不同资源之间的关系。

Gateway API 流程图
Gateway API流程图

请求流程

使用反向代理实现的网关的一个典型的客户端/网关API请求流程如下:

  1. 客户端向 http://foo.example.com 发出请求。
  2. DNS将该名称解析为 Gateway 地址。
  3. 反向代理在 Listener 上接收请求,并使用Hostheader来匹配 HTTPRoute
  4. 可选地,反向代理可以根据 HTTPRoute 中的 match 规则执行请求header/或路径匹配。
  5. 可选地,反向代理可以根据 HTTPRoute 中的 filter 规则修改请求,即添加/删除header
  6. 最后,反向代理可以根据 HTTPRoute 中的 forwardTo 规则,将请求转发到集群中的一个或多个对象,即 Service

TLS配置

我们可以在 Gateway 监听器上配置TLS,还可以跨命名空间引用。

首先我们先说明几个术语:

  • 下游:客户端和网关之间的链接。
  • 上游:网关与路由器指定的后端服务之间的链接。

其关系如下图所示。

客户端/服务器和 TLS

通过Gateway API可以分别对上游或下游的TLS进行配置。

根据监听器协议,支持不同的TLS模式和路由类型,如下表所示。

监听器协议 TLS模式 支持的路由类型
TLS 直通 TLSRoute
TLS 终止 TCPRoute
HTTPS 终止 HTTPRoute

请注意,在Passthrough(直通) TLS模式下,没有TLS设置生效,因为来自客户端的TLS会话不会在网关处终止。本文的其余部分假定TLS在网关处终止,这是默认设置。

下游TLS

下游TLS设置使用网关级别的监听器进行配置。

监听器和TLS

监听器基于每个域或子域公开TLS设置。监听器的TLS设置适用于满足 hostname 条件的所有域。

在以下示例中,default-cert Gateway为所有请求提供Secret资源中定义的TLS证书。尽管该示例涉及HTTPS协议,但也可以将相同的功能用于TLS-only协议以及TLSRoutes

listeners:
  - protocol: HTTPS # Other possible value is `TLS`
    port: 443
    tls:
      mode: Terminate # If protocol is `TLS`, `Passthrough` is a possible mode
      certificateRef:
        kind: Secret
        group: ""
        name: default-cert

如果 hostname.match 设置为Exact,则TLS设置仅适用于在 hostname.name 中设置的特定主机名。

示例

具有不同证书的监听器

在下面的示例中,配置Gateway服务于 foo.example.combar.example.com 域。这些域的证书在Gateway中指定。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: tls-basic
spec:
  gatewayClassName: acme-lb
  listeners:
    - name: foo-https
      protocol: HTTPS
      port: 443
      hostname: foo.example.com
      tls:
        certificateRefs:
          - kind: Secret
            group: ""
            name: foo-example-com-cert
    - name: bar-https
      protocol: HTTPS
      port: 443
      hostname: bar.example.com
      tls:
        certificateRefs:
          - kind: Secret
            group: ""
            name: bar-example-com-cert

通配符TLS监听器

在下面的示例中,Gateway*.example.comfoo.example.com 域配置了不同的通配符证书。由于特定匹配具有优先权,所有对 foo.example.com 的请求将使用 foo-example-com-cert,所有对 exmaple.com 的其他请求使用 wildcard-example-com-cert 证书。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: wildcard-tls-gateway
spec:
  gatewayClassName: acme-lb
  listeners:
    - name: foo-https
      protocol: HTTPS
      port: 443
      hostname: foo.example.com
      tls:
        certificateRefs:
          - kind: Secret
            group: ""
            name: foo-example-com-cert
    - name: wildcard-https
      protocol: HTTPS
      port: 443
      hostname: "*.example.com"
      tls:
        certificateRefs:
          - kind: Secret
            group: ""
            name: wildcard-example-com-cert

跨命名空间证书引用

在此示例中,配置Gateway引用不同命名空间中的证书。在目标命名空间中创建 ReferenceGrant 以允许跨命名空间引用。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: cross-namespace-tls-gateway
  namespace: gateway-api-example-ns1
spec:
  gatewayClassName: acme-lb
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "*.example.com"
      tls:
        certificateRefs:
          - kind: Secret
            group: ""
            name: wildcard-example-com-cert
            namespace: gateway-api-example-ns2
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: ReferenceGrant
metadata:
  name: allow-ns1-gateways-to-ref-secrets
  namespace: gateway-api-example-ns2
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: Gateway
      namespace: gateway-api-example-ns1
  to:
    - group: ""
      kind: Secret

扩展

网关TLS配置提供了一个 options 映射来为特定于实现的功能添加额外的TLS设置。此处可能包含的一些功能示例是TLS版本限制或要使用的密码。

扩展点

API中提供了一些扩展点,以灵活处理大量通用API无法处理的用例。

以下是API中扩展点的摘要。

  • BackendRefs:此扩展点应用于将流量转发到核心Kubernetes服务资源以外的网络端点。例如S3存储桶、Lambda函数、文件服务器等。
  • HTTPRouteFilterHTTPRoute 中的这种API类型提供了一种挂钩HTTP请求的请求/响应生命周期的方法。
  • 自定义路由:如果上述扩展点都不能满足用例的需要,实施者可以选择为API当前不支持的协议创建自定义路由资源。自定义路由类型需要共享与核心路由类型相同的字段。这些包含在 CommonRouteSpecRouteStatus 中。

参考

上一页