OpenFunction 发布了0.7 版本，其中有个特性是这么介绍的： 《K8s Gateway API 提供了领先的函数入口和流量管理能力》。 下面我们就来回顾一下K8s Gateway API的基础知识，它旨在解决什么问题，有什么好处呢？
在 Kubernetes 集群边缘对外提供网络服务的时候，通常需要借助 Ingress 对象，这个对象提供了暴露 Service 所必须的核心要素，例如基于主机名的路由、对 URL 路径的适配以及 TLS 配置等。但是在实际开放服务的时候，往往会有更多的具体需求，这时 Ingress 对象所提供的核心功能就有些力不从心了，各种 Ingress 控制器往往会使用 metadata.annotations 中的特定注解，来完成对 Ingress 特定行为的控制，完成各自的个性化功能，例如认证、路径变更、黑白名单等，这就让 Ingress 对象变成了一个奇怪的东西：结构化的核心结构，和非结构化的标注结合起来形成各种 Ingress 方言，并且后期还出现了 Traefik Middleware 这样的 CRD 配置，这给 Ingress 功能的集中管理造成了一个较大的困扰；另外 Ingress 中可以随意定制主机名、路径以及后端服务，也给共享集群的用户造成了一定的安全隐患。包括 Contour、Traefik 在内的 Ingress 控制器后期都提供了各自的基于 CRD 的功能表达，客观上也让 Ingress 世界更为分裂。
SIG-Network 基于实际现状和需求，提出了全新的 Gateway API 来作为 Ingress 的继任者，总体来说，相对于 Ingress，Gateway API 有几个显著特点：
- 职责分离，运维、开发等不同的角色都能够在适合的边界内完成工作；
- 扩展核心能力，并使用更结构化的方式进行表达；
- 易于扩展：Gateway API 为各种不同实现的控制器提供了一致的扩展方法。
目前该 API 还处于 beta 阶段(v1beta1)。 已经有了大量的控制器提供了支持，具体列表可以参见：https://gateway-api.sigs.k8s.io/implementations/。
概念层次
Gateway API 是一系列资源的集合，相比 Ingress API，Gateway API 最大的进步就是将流量规范独立成 API，大大提升了扩展性和灵活性。目前提供了 HTTPRoute、TCPRoute、UDPRoute 和 TLSRoute 规范来匹配特定协议的规则。
这里借用 张晓辉的 文章 SMI 与 Gateway API 的 GAMMA 倡议意味着什么？ 流量规范独立之后，网关的实现、基础设施的管理以及流量路由的定义得到了解耦合，这得益于 Gateway API 面向角色的 API 设计：
- 厂商实现了Gateway API 并定义了自己
GatewayClass类型，一系列的实现[11]可供选择。 - 集群管理员安装 Gateway API 的实现，部署跨命名空间的共享网关实例，或者命名空间独享的网关实例。如下图，集群管理员部署了跨
store和site命名空间的网关foo。 - 开发人员创建
HTTPRoute资源将流量路由到指定的后端服务。
Ingress 中包含了 IngressClass/Ingress 两层概念，而 Gateway API 包含了三层概念：GatewayClass、Gateway 和 Route，其中的 Route 实际是包含了 HTTPRoute、TCPRoute、TLSRoute 和 UDPRoute 在内的一组对象。
GatewayClass
它是一个集群范围内的资源，由云基础设施中的 Gateway API 控制器提供，其职责和原有的 Ingress Class 类似。
Gateway
Gateway 对象是命名空间范围对象，可以视作是 GatewayClass 的一个实例，它通常是由具体机群的运维人员进行维护的，在 Gateway 对象中可以指定该对象负责的主机名称范围，用标签选择器选择对应的 Service，甚至还可以指定该 Gateway 生效的命名空间。这样就给具体应用的对外开放划定了一个范围，防止应用随意占用主机名，并完善命名空间的隔离能力。
Route
前文讲到，Route 对象除了像原有的 Ingress 对象一样提供 HTTP 服务的开放能力之外，还提供了 TCP、TLS 和 UDP 的对应资源，从而缓解了 Nginx、HAProxy Ingress 控制器使用 Configmap 配置 TCP/UDP 的窘境。HTTPRoute 除了提供基础的 Ingress 对象能力之外，还提供了一些“越界”的功能，例如对流量进行复制、分流；更重要的是其中还提供了 Filter 能力，这是一个扩展点，除了自带的核心处理能力之外，底层设施还可以在这里接入自己的 CRD，对流量进行处理，从而为流量处理能力的扩展提供了一个统一入口。UDPRoute 和 TCPRoute 也提供了对流量的判别能力，但是这部分仅提供了扩展点，而没有像 HTTP 一样的成熟能力。
