Gateway API是一个开源的API标准，起源于Kubernetes SIG-NETWORK兴趣小组。从起源的角度看，Gateway API的根基很好，自开源以来备受关注，并被寄予厚望，它旨在通过一个声明性的、可扩展的和面向角色的接口来发展Kubernetes服务网络，并希望成为供应商的网关API标准，获得广泛的行业支持。简而言之，Gateway API希望能取代Ingress API。

Gateway API项目自2019年开始开源，但经历了缓慢的发展，直到2022年7月，随着GAMMA（Gateway API for Mesh Management and Administration）的推出，发布了Beta版本。人们认为，这里有两个主要原因：

- Ingress已经存在了很长时间，并且是几乎所有Ingress控制器的默认实现，而Kubernetes用户早已习惯了Ingress，尽管Ingress在易用性和功能丰富性方面存在很大差距。

- 服务网格或API网关项目，如Istio、Linkerd、Kong、Contour、Ambassador等都有自己的API标准，Gateway API还没有被用户很好地接受。

​

- 由于Gateway API没有强大的用户基础，缺乏对功能和经验的反馈，因此迭代缓慢。

Gateway API距离成熟、大规模商用还有多远？​

首先从目前的生态分析，Gateway API被Kubernetes圈普遍认可，包括开源项目、甚至商业服务GKE的支持。归根到底，Gateway API由Kubernetes网络组发起、维护，并且吸引了大量开源网络项目的维护者参与。当然实际背后控制者是Google，Google在开源技术的领导力毋庸置疑。但是不得不认识到，目前所有Gateway API的支持都处于初级阶段。

其次，从兼容性的角度看，一些成熟的项目，比如Istio，用户长期以来习惯了Istio的API标准，Istio社区也不会贸然的废弃原有的API，转而只支持Gateway API。因此这种多种API并存的局面将会持续很久，即使在未来Gateway API成熟了。

最后，前面讲到Gateway API对超时、重试、故障注入等能力预留了扩展能力，但是这种基本的网络能力，Gateway API应该提供标准的API，而不是让用户自己去定义私有的标准。这也违背了Gateway API想要统一服务网络标准的初衷。除此之外，灵活的扩展性如果违背了易用性，显然用户是不会买账的。

综上所述，笔者认为至少在一两年之内，Gateway API将会持续迭代，短时间内很难形成成熟的标准。或许可以期待，2024年以后服务网格和API网关的标准将会统一。

​