Kong API网关是建立在NGINX之上的开源API网关。根据公告博客文章，Kong for Kubernetes产品由两部分组成：一个是Kubernetes控制器，用于管理K8S入口配置的Kong状态；另一个是Kong Gateway，用于处理和管理传入的API请求。

公有云上大多数托管的Kubernetes部署都利用云供应商提供的Ingress控制器。这些控制器可以处理供应商的负载均衡器和其他计算抽象。Kubernetes部署还可以选择使用其他控制器，其中包括NGINX和HAProxy。

有媒体与Kong Inc.产品副总裁Reza Shafii联系，以了解有关此版本以及Kubernetes一般功能的更多信息。Shafii解释说，Kong for Kubernetes将Kong API网关具有的所有功能添加到Ingress。这些是API管理功能，即“启用对API流量的动态策略管理，例如基于OIDC的身份验证，高级速率限制，请求缓存或同时将日志和指标流式传输到不同分析提供程序的功能”。

Shafii进一步阐述了性能方面：这些包括高性能配置文件（例如，亚毫秒级延迟和每秒25K +事务），并支持多种协议和交互模式（REST，graphQL，gRPC，TCP等），同时提供以下各项的所有操作：通过Kubernetes CRD的Kong Gateway。最后一点很重要，因为这将使入口的操作方面在所有云提供商和内部部署之间保持一致。

根据Shafii的说法，尽管Kong是在nginx之上构建的，但与默认的nginx-ingress-controller以及nginx 自己的商业控制器相比，它的入口控制器具有明显的差异。这些差异在于Kong拥有的API管理功能，以及对于Kong Gateway用户而言，它为Kubernetes和非Kubernetes工作负载提供了“一致的API管理生命周期”。

0.8版本增加了Ingress对Knative的支持。Knative是Kubernetes 上用于基于容器的工作负载的无服务器平台，可为“常见应用程序用例提供更高层次的抽象”。

Knative的默认Ingress基于Istio，并且还有其他类似Gloo的选项。Shafii解释了Knative的默认Ingress与Kong提供的默认Ingress之间的区别：从社区和客户那里了解到的是，大多数用例不需要Istio就能运行无服务器工作负载。实际上，Istio的沉重负担是促使我们启动Kuma服务网格项目的原因之一。

Kong Gateway的插件体系结构和对可扩展性的关注有助于使Knative工作负载仅专注于业务逻辑，也可以将云供应商的负载平衡器与Kong的入口控制器一起使用。

Shafii填写详细信息：云负载平衡器提供了一种平衡多个Kong Gateway节点之间的流量的方法，并且Kong Gateway节点帮助管理到群集内多个服务的流量。实际上，对于大多数用户，我们建议使用负载平衡器（例如AWS或GCP的负载平衡器）来管理Kong Gateway。这在云中的虚拟专用网络内部提供了一个终结点，然后可以将该终结点暴露给其他网络（不同的AWS账户），其他合作伙伴网络或直接在Internet上。

与GCP和AWS等云供应商以及Istio和Gloo等网关提供的网络流量指标类似，Kubernetes的 Kong可以收集“指标，例如HTTP状态和错误代码，流量吞吐率/延迟和（消耗/出口）带宽消耗”。每个路线和服务级别”。

根据Shafii的说法，新版本还提供了针对Kong Gateway自身的与健康相关的指标，例如“服务的连接，当前正在使用的连接，共享的内存使用和缓存命中率”。他补充说，这些指标可以与Prometheus，Data Dog，StatsD，Zipkin和Jaeger集成。而且，0.8版本对基于路径的路由进行了重大更改，并且不建议使用某些注释，该更新日志有变化的完整列表。