原文作者：林静
原文链接： 分享实录｜NGINX Gateway API（上）
转载来源：NGINX 开源社区
NGINX 唯一中文官方社区 ，尽在 nginx.org.cn
编者按——本文为 NGINX Sprint China 2022 年度线上大会的分享实录，点击文末此处免费观看大会完整视频回放。
本文主要讲解关于 NGINX Gateway API 的话题，会从五个方面去和大家探讨 NGINX Gateway 的技术实现，内容包括什么是 Gateway API、理解 Gateway API、为何要发展 Gateway API、了解 Gateway API 的当前发展、两个不同的 Gateway API 实现与演示。
大家可能会有一点点疑问，我们经常说的 API Gatewa 和今天讲的 Gateway API，只是说法反过来还是完全不同。线上的小伙伴有知道什么是 Gateway API 的，可以快速在互动区谈谈对 G·ateway API 的一个印象，或者是关键的一些技术点、关键要素。
其实 Gateway API 并没有错，API Gateway 会在最后一场专门讲述，今天这一场讲的是用 NGINX 实现 Gateway API。听起来绕口，深入了解之后，大家就会明白为什么叫 Gateway API。
什么是 Gateway API？
Gateway API 可以从很多的维度解释。
首先 Gateway API 是一个项目，属于 Kubernetes Network Special Interest，也就是 K8s 的兴趣小组，这些兴趣小组会负责不同的方向， Gateway API 是属于网络的 SIG 小组。
在 Kubernetes 的环境下，主要用它去部署 4 层或 7 层的路由以及策略，做很多跟 Kubernetes 网络层面或者流量通讯层面的事情。就像 PPT 里面看到的副标题，它其实是一套全新的 Kubernetes 的服务的一种网络资源。
看到互动群里面小伙伴表示刚讨论的主语不一样，从语法上其实就能够区分出来到底要强调什么东西。今天要强调的是 API，它是一套资源规范，表现形式是一套 CRD 的资源以及相应的准入控制。
对于开发者或者实现者，这一套本身是接口规范或者是开发规范，因为对于 Gateway API 来说，目前社区只是在定义一个标准，没有去做具体的实现，所有的实现都要靠第三方去实现，对于开发者来说，这也是一套开发的规范。
正如刚才副标题所讲，它是 K8s 中处理流量的一套标准，实际上 Gateway API 本身是从 19 年开始去提这样的事情。
最早，Gateway API 本身在小组命名是 Service API，我个人认为 Gateway API 会更加贴切一些，更加准确地描述了这套规范所想表达或解决的问题以及对于这套 Kubernetes 与基础架构之间的关系，所以用 Gateway API 会更准确一些，Service API 感觉上面会更泛一些，或者是它的重点更没有特别去突出它。
Gateway API 是 Kubernetes 的 KEP，它会有很多的增强 proposal、KEP，Gateway API 应该是 KEP 里面的 SI 8 或者是 SI 9，是增强规范中建议的。从我们早期的试验型 Gateway API 的 API 组里面把它迁移到当前正式的 Gateway API 的资源组里。
所以相对于 Kubernetes 来说，Gateway API 当前是正式的 Kubernetes 网络的 API 组资源规范里面的一个种类，它并不是可有可无的，需要把它当成非常重要的事情去做的规范。
Gateway API 里面有什么样的资源？刚才我们谈什么是 Gateway API，对它做了一些初步定义。首先做一个基本分类、简单的描述与映射，主要的类型是来自于 Gateway Class、*Routes，这里面说的包含了 HTTP Route、TLS、TCP、UDP 或者是 GRPC。
未来可能还会有更多 Policy 类型的资源，在使用中这些资源之间是有很多的引用关系。
首先第一点，Gateway Class 你可以理解成是底层基础，实施层面的某种 proxy 产品或者解决方案的抽象，这个抽象在 Kubernetes 里面表达为 Gateway Class。从这句话大家就可以理解，Gateway Class 是用来映射到底层的某种解决方案或者是某种提供上的设备或者是一个产品。
所以在这张图里面大家可以看到 Gateway Class，它可以表达为公有云上的各种公有云的SLB服务，也可以表达为 NGINX 的 proxy 服务，或者表达为 F5 BIG IP 产品的服务，Gateway Class 就是这样的一个抽象。
Gateway Class 抽象之后是底层，上层的配置就会由 Gateway 和各种各样的 Route 去表达。Gateway 是直接和 Gateway Class 进行关联的一个对象，Gateway 表达的是各种各样的 proxy 上面的配置的抽象。
比如这样的一个服务的入口，应该是什么样的 IP 地址、什么样的端口、什么样的协议、什么样的证书等等，这些东西都属于在 Gateway 层面进行表达的，表达完之后它映射到底层具体的解决方案。
上层就是这些解决方案，比如像公有云上的，或者是 NGINX 上的，或者 F5 上各种各样的配置。Gateway 下面还会引入很多策略性的东西，比如现在有一个 proxy ，有了一个代理，在这个代理之上要加很多的策略，比如七层的策略或者是一些安全的策略等等，这些事情都有各种各样的 Routes 或者是 policy 进行挂载。
这些 Routes 主要表达的就是 7 层上面各种各样的处理，接着就会把流量送到 backend 的 service 上面就形成了。可以看出来这些资源对象之间的一些基本的引用关系或者是一些逻辑关系。
Gateway API 有什么样的特点，刚才讲了定义也讲到了基本类型。但是线上有些小伙伴到目前为止还有一些困扰：Gateway API 是不是有点像 Ingress？确实它和 Ingress 有很多地方相通，大家不要混淆。
Gateway API 里面的特点，有很重要的一点，就是你会发现它可以面向不同的维度去映射不同的东西，那就意味它有角色，就像上一张图一样，是底层的基础设施的提供者。可能是 K8s 平台的管理员，或者是应用的业务管理人员，或者是开发人员，他们都有决策权限。所以在 Gateway API 里面，它很大的一个特点是面向角色的，不同的角色有不同的资源对象，进行对应映射。
第二个特点是可移植的。刚才我们有提到，社区只是在定义一套规范，但是一套规范并不一定要出一个具体的实现方案，这些方案要由第三方实现，我所定义的这些规范的接口或者是标准，应该在各种环境下都适用，达到同样的一致性结果，这样有利于去做各种各样的迁移，强调一致性。
第三个特点是功能丰富。我们都知道 Kubernetes 里面 Ingress 能力相对比较弱，很多功能都是依赖于我们去实现 Ingress 这些解决方案厂商所提供的各种各样的扩展功能，很多的 Annotations 来扩展，但是本身 Ingress 从 Kubernetes 定义 Ingress 资源对象的时候，其实是非常简单的。
基本的 SSL、HTTP 的路由还是非常简单的，但是在生产环境中，可能需求不止这些，这个时候标准的 Ingress 可能就不能满足要求，我们需要有更多的实现。所以 Gateway API 也是基于这一点去解决或者是增强 Ingress 方面所提供的能力不足的问题。
第四点就是可扩展，它与功能丰富其实是在同一个维度上面，但是它又强调了在这些标准之外，还可以扩展出很多东西。这样就意味着通过扩展的方式可以去兼容或者实现不同的个性化。刚才我们谈到实现整个 Gateway API 是由不同厂商去实现，不同厂商会有不同的技术、不同的方案，他们个性化的特点，或者是强项，如何发挥这些强项、如何利用好这些强项，就是在可扩展当中要去做的事情。
第五点就是可跨 NS，它是指可跨 name space 边界的一个资源引用。这里面也表达了在 Gateway API 里面，资源对象是可以跨 name space 引用。比如 Gateway 和 Route 是完全可以在不同的 name space 下的，可以彼此之间引用，引用之间也可以做一些控制。
刚才我们谈到，这两个资源对象是由不同的角色去解决边界之间的沟通与安全问题，其实也是在 Gateway API 里面要去解决的。所以跨资源引用以及安全的引用这方面也是 Gateway API 里面的很重要的部分。
最后一点就是支持不同类型的协议和 backend。不同类型的协议可以理解成上面我们谈到的功能丰富里面的一个维度，但是它还强调了支持不同的 backend。
backend 就是指整个流量从外部进入到 Kubernetes 网关体系，把流量引给了后端标准 Kubernetes 的 service 以及后端的在云上的某种 serviceless 的 function 函数、存储桶，比如 S3 这样的 bucket。这些东西都是由 Gateway API 扩展出来的，也就是在未来通过 Gateway API，不仅仅是向一个服务去引流，而是可以向更多的不同的后端对象去引流，进行控制。所以大家可以看出来，这里面 Gateway API 的特点就显现出来了，它不单单是提供某种服务，更多的是表达一种能力。
NGINX 唯一中文官方社区 ，尽在 nginx.org.cn
更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源：
