原文作者：林静
原文链接：分享实录｜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。

大家可能会有一点点疑问，我们经常说的 API Gatewa 和今天讲的 Gateway API，只是说法反过来还是完全不同。线上的小伙伴有知道什么是 Gateway API 的，可以快速在互动区谈谈对 G·ateway API 的一个印象，或者是关键的一些技术点、关键要素。

其实 Gateway API 并没有错，API Gateway 会在最后一场专门讲述，今天这一场讲的是用 NGINX 实现 Gateway API。听起来绕口，深入了解之后，大家就会明白为什么叫 Gateway API。

理解 Gateway API 的一些细节

了解完什么是 Gateway API 的时候，我们来看一些细节。深潜到海龟维度，海龟一般表达出来的就是稳重，它会有什么样的细节？这是一张 CRD 导图，看不清楚没有关系，重点去看它的结构就可以了。

首先，导图的第一个维度，是刚才我们谈到的分类 Gateway class，因为当前整个社区的重点还是在 Gateway API 上边，比如 class、Gateway 以及 http route、像 TCP、UDP 以及 TLS 这些都在实验阶段，没有更多的定义。

所以上面的已定义的资源对象有很大的一个特点是可以看到它的结构基本上是一个 Metadata，原要素方面的一个描述。

接下来就是关于它的一个 spec。最后关于它的 status 的状态，所有看到它定义的对象，基本上都是这样的一个模型，利用 spec 或者利用这样一个结构去学习这些 CRD 资源的时候，就容易掌握一些，去学习或者了解它的时候，你很快通过结构上就可以感受得到。

下面把上面刚才说到的 3 个重要的资源对象，分别截图再去看。Gateway Class 很重要的一点就是 private reference 。意味着 Gateway Class 是可以去引用一些自定义对象，或者是引用 Kubernetes 里面的 config map 对象，利用 Gateway Class 里面属性的字段去给底层的基础实施 proxy 产品一些全局性的配置，然后下发。

举个例子，刚才我们谈到 Gatway class 所表述的底层的 provide，f5 的 BIG IP 或者是 NGINX，怎么去利用？在 Kubernetes 层面，通过直接下发一些配置项或者是参数，直接影响底层的 NGINX 或者是 BIG IP 的配置，可以利用里面的 private 事情去做。

在一个集群里面有很多个不同的 Gatway Class，可以对应到不同的底层 provider，给一个集群同时提供 NGINX 也同时提供 f5 的 BIG IP，甚至是第三方其他 privacy 类的产品都可以同时使用。

然后是 Gatway，刚才有提到它是表述 proxy 上面具体的配置，比如 address， virtual address 就是 VIP 地址，或者你的端口还有处理的协议、加载什么样的证书，都可以看到这样的一些配置。在这个维度还有 host name，如果大家都在学 NGINX，就知道这个地方的配置很像 NGINX 里面 server 块，映射到底层的一些配置项。

到 HTTP Route 里就更多了，这是我们刚才说到的在网关层面作用，围绕着 HTTP 流量去处理，很多流量上层的事情要去操作。这个时候你就会看到，在 HTTP route 里面，rules 可以去做 URL 的匹配、rewrite、改写或者是 head 头的改写都可以在 filter 里面去做。

backend 这样的引用到我们刚才说到的 Kubernetes 后面的 service 等等一些对象上去就表述出来了。相当于是从 Gatway 到 HTTP route 之间的层次关系。Gatway 定义了一些基本网络层面的属性、IP 地址协议等等。在 root 层面就定义更多的一些策略或者是一些操作的 action。

另外一点，大家也可以注意看到，在 HTTP route 里面也有一个 host name 的字段，Gatway 里面也有字段，server 层面也有 host name，到下面具体的路由层面还有一个 host name。而真正去做的时候，这些地方应该是匹配起来的。

再一点，刚才我们提到的，在所有的这些资源对象当中，都有 statues 的状态。这些 statues 的状态非常好的帮助我们去了解下发资源的状态。比如这样的配置有没有正确的下发到底层。

这样一些配置的关联，比如 route 跟 Gateway 之间关联有没有出错或者是为什么不能关联上，就可以通过各个资源的 status 对应出来，整个设计还是比较精简化的。没有什么太多没有用的东西，基本上只是定义了现在必须要的东西。

有了这样的一些基本知识或者了解一些细节之后，可以做一个简单的小总结。也就是今天讲的 Gateway API 到底可以总结出哪些关键属性？

第一点总结，它是帮助我们从单一的自服务演进到了基于角色的自服务。这句话听起来有点抽象，但是大家如果已经在实践中大量使用了 Ingress，毕竟在企业当中，你会把整个 Kubernetes 平台给到业务员去使用的时候，就能深刻感受到这里面的变化。

左边是一个标准的 Ingress，在定义里面会看到有相应的 TLS 证书部分的要素，还有规则部分的要素、host name 的要素，业务部分基于 PaaS 这些应用部门关心的一些要素。

你会看到所有的这些要素都在同一个文件里面，那么在实际工作中到底是让谁来管理？如果是业务部门来管理，往往实际功能，很多用户还是由业务部门来写这些 Ingress 或者是应用的负责人去写这些 Ingress。

这个时候 Ingress 就意味着业务部门或者应用管理人员，实际上是需要向企业里面的一些基础实施人员去了解到这个东西底层用的是什么技术、上面有哪些可扩展的字段配置是给到我的，我要去学习跟底层相关性的一些东西。

同时还会知道，这个服务到底要挂公司的哪一套证书，证书的有效期什么时候去更新，什么时候去迭代？本身这个事情不应该由业务部门去管？它应该有基础架构实施的一些平台或者是基础架构层面的人去管。

但是因为 Ingress 的设计，使得我们不得不去让业务部门或者应用人员去考虑这些问题。所以即便后来我们有了 Ingress class 去做区分，但是它依然不能够很有效地把上底层的这种基础架构实施直接表达在上层一个对象。

因为 Ingress Class 更多的时候表达出来的是一个 shutting，它很难去传递一些配置、要素到底层。所以它即便加了 Ingress Class 之后，Ingress 里面角色对象区分还是不够清晰。

当进入到 Gateway API 模型之后，就可以比较清晰地看到把三个维度全部拆开，每一个维度的人员、每一个维度的对象都有自己的资源对象去管控，各个部分都有边界。这样的好处是进入到演进 2， 因为有了角色、资源对象，就可以做 RBAC。

什么样的人基于什么样的角色做什么样的资源控制，RBAC 就很好去设计。建议有 4 种标准的对象，还可以做一些其他工作，比如应用的管理人员，在局部的 name space 下有 Gateway 层面的了解权限。

比如现在一个应用是一个大项目组，它底下有很多的小应用，找到足够派到大应用的一个基础架构人员去了解到它或者管理到在 name space 下的一些属性，包括刚才谈到的提供什么样的证书，使用什么样的 Gateway Class。

这样调整的边界或者逻辑就会比较清晰，不至于是混合在一起的时候，让不同的人去管理同一个文件，相对来说，一个企业里面安全度、协作度会高一些，RBAC 就很好做。

第三点就是刚才谈到的可移植性，因为我们已经谈到了很多的资源对象，但是这些资源对象怎么分类、怎么样去实现、确保可移植性是标准化可落地的？Kubernetes 的 Gateway API 在社区里面定义了三类资源对象。

第一类是核心类的 Core。刚才谈到的 routing、Traffic Splitting、Gateway、Gateway Class 等等都属于 Core 部分要去实现的，意味着所有的提供商实现者都必须按照严格的要求做扩展，去实现一定是按照社区的标准，随着使用越来越多，未来普遍性越来越高。它可能会把 extended 部分的 API 资源挪到 Core 部分中去。

第三部分就是完全自定义的，不同的实现者和不同的实现厂商去实现会有自己的操作空间，有 room 去实现它自己的能力。比如 NGINX、NGINX plus 里面有很多特有的特性，能不能通过在这个位置上面去实现这些特性？其实可以通过 Custom 这个地方去实现，以之为导向。这些东西生态上是统一的，大家都遵循同样一套规范、标准，发展起来会比较容易。

为何要发展 Gateway API

另外一个维度，是刚才谈到的技术层面，Ingress 有很多的缺陷或者能力不足，包括它刚才说到需要很多的 annotations，很多协议是不能够扩展的。怎么样去解决这些问题，就要依赖于 Gateway API 去解决 Ingress 的不足。

刚才谈到的角色同样也需要解决。整个社区资源和资源所属对象之间充满摩擦，这个时候团队之间需要基于契约来讨论一个事情，那么团队和 owner 之间沟通成本就会比较低，比如企业的 SRE 有具体的细分，每个角色之间就需要更多的沟通，如果沟通不在一张白纸上去沟通，那就意味着要尽量让大家在同一个层面沟通。

有了这个能力后，我们谈到的 Gateway Class 实现它有一个很大的好处是它可以引用自定义，或者是引用 Kubernetes 的  config map。

所引用配置项、配置对象资源，都属于 Kubernetes 里面的资源。那就意味着底层的基础实施提供者所维护的这些东西，变成了站在 Kubernetes 角度去维护，会把传统的团队和 Kubernetes 团队更好地融合起来，在企业里面做的 SRE 和 Devops 也更好地融合起来。这样就帮助企业融合了传统技术架构师和 Kubernetes 团队之间的关系。

另外一方面它也解决了一个问题，以前 Kubernetes 都是站在开发者的角度思考问题。当然也有小伙伴表示，现在 Kubernetes 很多都是在平台部门在做，但本质上讲，Kubernetes 本身在设计阶段很多东西还是站在有利于开发者的角度定义非常简单的网络规范。

只要两个之间能够通，不管用什么方法通，就意味着两个 pose 之间是可以服务通讯的，是站在比较理想化的角度去做这些事情，但是当你把整个 Kubernetes 这样一套平台落到一个企业当中的时候，考虑的问题不单单是有利于开发者的一个问题，还要考虑有利于基础架构实施、有利于网络、有利于安全。

Gateway API 其实就是要去做这样一些融合的事情。正如刚才我们讲到的，一个 Ingress 的资源是耦合的，可以通过一个很具体的当前资源考虑怎么去把它拆分开。先在界面上看这两个资源拆分，就可以看出来它的一些变化。

左侧是标准的 Ingress，如果我们要做这个事情，它有很多的 Annotations、规则要去考虑。但是如果在新的 Kubernetes Gateway API 的模型下去考虑这个问题，可以通过拆分成不同的资源对象、不同的要素，去实现。

Gateway & route 层面，都是在关注自己的东西，而不是关注别的东西，每个人都有每个人的角色，大家在一个规则的角度、遵守一种规则，去做同样的一个事情或者达成同样一个目标，这才是融合。

刚才我们谈的这些，其实都是技术层面的原因，实际上，如果抛开技术问题，思考为什么社区要去做 Gateway API，大家可以从三个角度去理解的，第一个就是产品，第二个是市场，第三个是客户。

从产品角度来讲，本质上是因为 Kubernetes 已经趋于稳定，大量的客户在践行 Kubernetes，这个时候它早期面向开发者设计的很多能力都需要去补齐。

大家今天看 Kubernetes 的一些更新迭代发展，它增加 endpoint slices、增加多集群的这些功能其实都是在真正落进深水区之后。它本身并不是面向开发者的，但也越来越开始面向基础架构实施去增强一些能力。所以从产品的角度，社区、Kubernetes 上游社区，需要解决上边的不足去还这样的技术债。

第二个就是市场，市场其实是教育了 Kubernetes 的上游。在开源社区里面，Kubernetes 提供了一个生态，有众多的玩家在这里玩。甚至有很多的玩家是来自于非常强的企业级市场的领导者，他们实际上对真正的企业用户、实际终端用户有大量的经验，这些企业所制造的产品或者是所提出来的概念会被反哺，或者是会被吸收到社区当中。

其实我们刚才谈到的 Gateway API 里面很多的资源对象设计的思路，在 Istio、Aspen mesh 都能够看得到。包括 NGINX 做的 Ingress controller 当中提供的 mogeable 的 Ingress，基于 CRD 模式的概念等，本质上都是讲角色拆分的概念，帮助我们去解决实际的问题。所以你会看到它们最终都被社区或者上游吸收过去了，这是市场给到社区的反馈。

一个 a 解决方案，不能迁移到另外一个环境，不能迁移到 b 解决方案的时候，对于用户来说是有成本的，所以从社区角度来讲，它需要面对客户去提供一个尽量标准的方向。随着用户成熟度提高，生产场景越来越丰富，就意味着社区需要去做这些事情。

了解 Gateway API 的当前发展

我们深知用户的企业当中，很难有真正理想化的团队在一起的工作。越是践行 Kubernetes 技术比较早的大型客户，它的历史 IT 规模越大。往往它都是多团队、跨团队的，这些基础实施、团队相互之间是需要协作、互相连接的。

所以从产品、市场到客户，我们都可以看到 Kubernetes 本身是极大要改变的，因此当前 Gateway API 的发展就变得非常的迫切。截至 2022.11. 尚处于 Beta，主要实现了 HTTP Route，其它部分资源对象依然尚未实现或处于试验状态。

Istio 也开始兼容 Gateway API，使得在服务网格中使用统一的 Gateway API 管理南北与东西流量成为新晋方向。对于用户来说，管理成本低、心智好。

Tetrate、linkerd、Istio 均在继续推进支持 Gateway API 的接口规范。社区里面有一个 GAMMA 小组，是 Gateway API for Mesh 的管理小组，他们会去推动在南北向、东西向规范的统一。这样用户在 Kubernetes 里面，管理流量标准会更加统一。

我们刚才讲可移植性、标准化是很好的，但它也会带来限制性。上游社区本身非常开放会比较好，但是如果上游社区，希望借助这样一个标准去非标准化，可能会限制一些实现厂商的创新，这个也是在社群里看到的一个争议比较大的地方。

不要让 Gateway API 变成少数公司控制方向的一个东西，而是要尽量的兼容，我们希望是真正能够站在用户的角度去考虑，而不是过度标准化。

另外一点，整个生态当中，f5、NGINX 在积极发展，我们有一张图去阐述这样的一个生态。整个生态中，上游的 Kubernetes 的 SIG 小组带领 Gateway API 规范定义之后，整个生态比较丰富。无论是贡献者、控制器层面的开发者，还是数据面的参与者都是比较丰富的。

可以看到大量的 proxy 类型，或者是 Ingress 领域当中已经存在的玩家，依然在这里是最活跃的，因为本身这些技术是相通的，它只是一个新的下一代标准。

其中数据面还是比较有意思的，数据面依然是公有云厂商基于自己的 load Balance 数据面去实现 Gateway API。我们看到 GCP 是目前唯一一个在公有云上进入到一个 GA 状态的，基于 Gateway API 实现了很多的特点。

另外一点就是基于 proxy 软件，比如 envoy、NGINX，envoy 属于云原生领域上大家比较关注的新生代，它功能确实很强大，但是也很复杂。另外一点就是像 NGINX 这些老牌的厂商或者老牌的产品，本身的技术栈已经被大量的用户使用，今天上午看到的很多的企业都在用 NGINX。

这样的好处是对于用户来说学习的成本比较低，学习的曲线不会像 envoy 那么高，掌控度也更容易，因为我们使用的是熟悉的技术领域去做这样的事情。

还有一块领域基于 F5，F5 本身属于在基础架构层面提供了很多能力的实施，它可以是软件的，也可以是硬件的。当我们需要在企业里面提供很多企业级的丰富特性、专有协议的一些特性，或者是需要非常高的性能的时候，以 F5 作为这种模型的数据面，它也是一个很好的选择，可以有效地把基础实施层面和 K8s 这样的一些流量进行连接，帮助 K8s 更好地发布流量，所以生态还是比较丰富的。

当前的 Gateway API 的实现方其实有很多，刚才说的整个社区，本身只是做了一个规范，并没有去做实现，实际上要靠各种各样的解决方案去提供。当然大家也可以看到，目前所有的厂商或者是所有的解决方案都还没有进入到真正激烈的状态。也是因为 Gateway API 还在定义或者发展当中，所以这些实现方也都还没有进入到激烈的状态。

但是我们相信随着 Gateway API 进一步的发展，相应的实现方也就会伴随着它很快实现产品的发布。

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源：

开源社区官网：https://www.nginx.org.cn/

微信公众号：https://mp.weixin.qq.com/s/XVE5yvDbmJtpV2alsIFwJg