Gateway API正在成为服务网格战争的导火索
服务网格提供商们正全面转向Kubernetes Gateway API，将Ingress替换为可供各Kubernetes节点和集群共享管理的单一API。
各大领先服务网格提供商近来纷纷对Kuberentes Gateway API青睐有加，着手将Ingress替换为可供各Kubernetes节点和集群共享管理的单一API。虽然Gateway API与服务网格一样，最初是想为基础设施提供除Kubernetes之外的管理途径，但如今其已经在Kubernetes缔造者谷歌手中成了专为Kubernetes配置的又一种配套解决方案。
Salt Security公司一线CTO Nick Rago在采访中表示，“总的来说，如果把Gateway API引入Kubernetes能够帮助基础设施服务商、平台管理员和开发者消除操作间存在的种种摩擦，缓和开发者在部署上下游API和服务时遇到的现实难题，那这种融合其实也并无不可。”随着Gateway API规范的发展成熟加上网关控制器服务商支持更多规范，用户组织将有望借此摆脱对于特定供应商/平台的高度依赖与知识锁定。
仍有争议
从这个角度看，也许我们就能理解为什么Linkerd、Istio，特别是谷歌纷纷推出基于这一标准API的新项目。然而在这看似分久必合的大势之下，Gateway API身上仍存在不少争议。
Linkerd在今年8月发布Linkerd 2.12时，公司CEO Willaim Morgan就曾提到将“采用Gateway API作为核心配置机制的第一步”。然而，Morgan对于通行标准和供应商锁定等风险仍然保持着谨慎、甚至可以说是警惕的态度。
毕竟根据不同项目的成熟度差异，统一的标准也许并不适合某些特定用例，所以这种审慎的态度完全可以理解。
Ambassador Labs开发者关系负责人Daniel Bryant也在采访中强调，“标准可能是福音，但也可能是种诅咒，具体要取决于基础域/产品到底处在生命周期中的哪个阶段。标准既可以成为高层次创新的驱动力，也可能给创新工作戴上镣铐。在我看来，Kubernetes Ingress及其网络已经是个被充分探索、充分理解的领域，所以为其制定标准应该有助于支持后续创新。正因为如此，才会有Emissary-ingress和Contour这样的Ingress项目决定采用Gateway API规范，Linkerd和Istio等服务网格产品也对该规范表达了支持态度。”
而且按照标准来看，谷歌对Gateway API显然也是高度认可。在采访邮件中，谷歌云首席工程师Louis Ryan对于Linkerd、Istio、特别是谷歌众项目对Gateway API的支持做出了如下解释：
“Kubernetes已经证明自己就是标准化API的客观中枢，且获得了广泛的跨行业参与与支持。Gateway API也从中受益，成为适用于入口、出口和集群内等各类流量管理用例的高质量解决方案。因此，将Gateway API应用于网格流量管理是非常符合逻辑的发展方向，相信建立这样一个全面、由社区驱动的持久标准能够给广大用户带来助益。”
Istio指导委员会之所以决定将其服务网格项目作为孵化项目捐赠给云原生计算基金会（CNCF），部分原因就是想改进Istio通过Gateway API与Kubernetes相集成（同时也将更好地与无代理网格和Envoy的gRPC相集成）的能力。在这里，Gateway API明显是被作为Ingress的理想替代方案。
Istio领先工具提供商solo.io创始人兼CEO Idit Levine表示，“Istio被捐赠给CNCF让我确信该项目状况良好，这意味着Istio绝不是谷歌自己的项目，而是真正的社区项目。”
在此之前，IBM（与谷歌及共享汽车服务商Lyft一样，均为Istio项目的初创成员之一）和其他社区成员曾经对Istio项目的治理问题表达过担忧，特别是谷歌在2020年就提出将该项目纳入开放使用共享（OUC）组织的倡议。
Linkerd CEO William Morgan在一篇博文中表示，Linkerd 2.12已经在支持Kubernetes Gateway API方面迈出了第一步。虽然Gateway API的最初设计目标是为Kubernetes中的Ingress资源提供更丰富、更灵活的替代方案，但它“同时也给服务网格的流量表达建立起良好基础，允许Linkerd将额外添加的配置机制保持在最低限度。”
“对Linkerd来说，Gateway API的价值就在于它已经作为Kubernetse的组成部分存在于用户集群之上。从这个角度来说，Linkerd可以将Gateway API作为构建基础，由此减少我们所需引入的新配置数量。这种配置轻量化能力符合我们的发展预期，即尽可能不让其他项目的复杂性「污染」服务网格空间。”
Bryant认为，Gateway API规范承诺的可移植性“对运营商和平台工程师们也很有吸引力。虽然他们大多已经决定长期选择服务网格，但使用网关API确实能让组织以标准化方式配置和部署所有服务网格，并在必要时更换具体实现（虽然更换过程不会很容易）。”
但Linkerd也只提供了部分Gateway API（例如HTTPRoute等CRD），用以配置Linkerd的基于路由策略。通过这种方式，Linkerd既能使用Gateway API类型，又无需在承担规范当中“对Linkerd没有意义”的部分。Morgan在博文中指出，随着Gateway API的发展及针对Linkerd需求的调整，Linkerd希望能以最小化用户摩擦的方式实现源类型切换。
在Morgan看来，“目前最大的隐患是Gateway API可能被某个特定项目或企业所把控，导致其利益定位与整体社区的需求出现错位。虽然目前的Gateway API在入口用例上已经足够完整和稳定，但与整个服务网格的适配还有不少需要优化的地方，这里的发展空间还很大。最让人担心的是，目前Gateway API的很多贡献者都来自谷歌，同时也参与到Istio项目的开发。所以如果Gateway API把后续发展方向跟Istio绑定了起来，那么它的定位就会跟最终用户的意愿发生偏离。在这种情况下，标准反而成了一种枷锁，会迫使Linkerd这类项目各自开发自己的API。”
未来方向
与此同时，企业管理协会（EMA）分析师Torsten Volk认为，Linkerd只保留部分Gateway API的作法就很好，与服务网格提供商们保证网格体验“轻松简单”的愿景完全一致。
Volk指出，“这些提供商们并不想引入任何会拉高用户使用成本的元素，也不想引入可能影响网络延迟、导致性能下降的机制。这些提供商甚至会在自家网站上打出「尽量减少YAML，尽量减少CRD」的标语，表达自己对于各种所谓高级功能的批判性评估立场。换句话说，他们只想要Gateway API当中好的部分，差的和没用的部分一律滚蛋。因为一旦失去了这份简单性和高性能优势，Linkerd与Istio之间也就没什么区别了。”
当然，Istio和Linkerd仍然是两种相互竞争的服务网格解决方案。对于那些需要GKE支持的服务网格用户来说，Istio就是最理解的服务网格工具。而根据Volk的观察，“但与此同时，也有很多其他代理、入口控制器和服务网格平台供应商并不急于全面支持Gateway API。他们经验丰富，知道Gateway API标准中哪些对自己有用、哪些毫无意义。”
Bryant指出，HashiCorp、Kong、Ambassador等厂商正发声支持Gateway API。“大多数Kubernetes API Gateway提供商已经在一定程度上支持Gateway API规范。Emissary-ingress和Ambassador Edge Stack甚至早早就开始支持，而且会坚持这条路线不动摇。”
Ambassador Labs还与Envoy Gateway项目的其他创始贡献者（包括Tetrate、VMware、Fidelity等）合作，希望为Kubernetes Gateway API规范制定出一套参考实现方案。Bryant总结称，“我们的目标是在标准化的K8s API Gateway上开展合作，立足共同的起点构建功能、推动创新。”
推荐阅读：