Envoy Proxy项目正在扩展，目的是为Kubernetes本身建立一套标准化、简化的API。

在KubeCon+CloudNativeCon EU上，该开源项目透露，正在开发一个扩展，即Envoy Gateway，它将使Envoy反向代理成为一个网络网关，使其不仅可以引导内部微服务流量，还可以管理进入网络的外部流量。Kubernetes是最初的目标。

Envoy Gateway背后的想法是提供“一个简化的部署模型和API层，以满足更轻的用例”，Envoy创建者MatKlein在一篇博客文章中解释道。

Envoy最初是为Lyft创建的，于2016年以开源形式发布，主要用于构建服务网格（通常与另一个CNCF项目Istio一起），帮助云原生应用程序通过sidecar相互通信。

有趣的是，Lyft本身首先将该软件用作API网关/边缘代理，这意味着它可以轻松地作为反向代理，用于内部路由外部流量，提供相同级别的可观察性和零信任安全性。

Envoy Proxy项目于2017年被CNCF采用，已达到毕业项目成熟度水平。Envoy Gateway也将由CNCF管理，作为一个衍生项目。

Kubernetes Gateway API

Klein认为，API Gateway可以被视为“Envoy Proxy核心的包装器”，不会对核心本身进行任何重大更改。它可以在各种用例中管理L4/L7流量。

对于管理员来说，该软件旨在提供一种更简单的方法来设置Kubernetes服务网格。Klein承认，Envoy本身并不容易管理。增加一点易用性可能有助于吸引更多的用户，即那些拥有较小网络的用户，他们现在倾向于部署HAProxy或Nginx来代替Kubernetes入口。

也许更重要的是，该项目希望看到开发人员和第三方工具供应商通过提供一个参考实现，将Envoy作为K8s集群的入口控制器来运行，从而决定使用Envoy Gateway访问Kubernetes。Klein解释说，该API将是“Kubernetes Gateway API，带有一些特定于Envoy的扩展”。

他说：“之所以选择这个API，是因为在Kubernetes上部署作为入口控制器是该项目的初始重点，也是因为该API获得了广泛的行业认可。”

 Ambassador Labs首席执行官RichardLi在博客中进一步解释说，使用Kubernetes Gateway进行配置将“在其API中实现路由与管理的解耦”。Ambassador与Fidelity、Tetrate和VMware是该项目的赞助商。API将隐藏开发人员和管理员之前必须处理的低级配置。

Istio贡献者和指导委员会成员ZackButcher表示，该项目将“致力于使体验变得极其简单和容易，以便各个应用程序开发人员或团队在其基础设施中获取和部署Envoy”。

Butcher还指出，融合Kubernetes Gateway API将减少目前为构建竞争控制平面而进行的重复工作。“控制平面很无聊！它们的构建成本也很高，而且很难做对。”

Klein认为，如果Kubernetes的用户群都同意部署这些API，那么他们的供应商“就可以轻松地提供替代的SaaS实现，如果用户超出了参考实现的范围，需要额外的支持和功能等，这可能是更好的选择”。

第三方软件开发人员可以向上移动，并在标准化、供应商中立的Kubernetes网关API上构建高级功能。

这不是CNCF第一次解决API网关问题。但CNCF表示，Contour和Emissary的最佳部分将被纳入这项新的努力中。

原文链接：

https://thenewstack.io/envoy-gateway-offers-to-standardize-kubernetes-ingress/