Kong 1.0 正式发布，提供服务网格支持和插件开发工具包

Kong Inc. 已经发布了 Kong 1.0，这是其旗舰 API 网关产品的最新正式版本（GA）。虽然通常是部署在网络边缘处理外部“南北”API 流量，但 Kong 也可以作为“服务网格”部署在任何后端服务之前。

正文

Kong Inc. 已经发布了 Kong 1.0 ，这是其旗舰 API 网关产品的最新正式版本（GA）。该版本是一个“可伸缩的、快速的、开源的微服务 API 网关，用于管理、保护和连接混合和原生云架构”。虽然通常是部署在网络边缘，用于处理外部“南北”API 流量，但 Kong 也可以作为“服务网格”部署在任何后端服务之前，并且可以通过插件进行扩展，以提供身份验证、流量控制、可观测性等功能。

虽然 Kong 1.0 最初发布是在去年 9 月，但最新的 GA 发布博客声明中写道，“通过发布 1.0，我们承诺今后保持向后兼容。”Kong 基于开源的 NGINX 代理、负载平衡器和 Web 服务器构建，一直专注于提供针对 API 管理的附加功能。Kong 提供开源社区版和企业版。Kong 1.0 GA 的重点还包括“服务网格”实现、Mutual TLS、gRPC 流量支持、新的迁移框架（以简化数据存储模式迁移）和插件开发工具包（PDK）。

Kong 开发模型（图片来自 Kong 网站）
根据产品网站的介绍，借助 Kong 1.0，用户现在可以将其部署到服务网格配置中，把它作为一个“挎斗（sidecar ）”代理，与其他服务 / 应用程序进程一起运行。但是，在“流和服务网格”标题下，有关这个新特性的文档目前还相当有限。Kong 的“服务网格”定义表明，网格是由建立起连接的 Kong 节点构成的：

在 Kong 中，服务网格是动态构建的，只有在 Kong 节点之间存在活动连接时才存在。简而言之，这意味着 Kong 节点 [原文如此] 不需要知道其他 Kong 节点，而服务也不需要知道 Kong。

其他服务网格实现文档往往更关注整个网格的管理和编排以及控制平面（UI、路由和策略规范、遥测收集和相关工具）和数据平面（代理实现，从控制平面接收指令）的划分，例如， Linkerd 、 Istio 、 Consul Connect 的文档。另外，教程所需的 iptable 手动操作通常也比较少，并且也不需要当前在 Kong 服务网格文档中介绍的通过 CLI 操作路由。然而，这是一个相对较新的 Kong 特性，“服务网络”的市场化概念仍在更广泛的行业中出现。GitHub 也接受社区文档贡献。

发布博客中确认了数据平面和控制平面的分离。在 Kong 1.0 之前，工程师“需要分别配置每个集群的数据和控制平面”，但现在，他们“可以在一个集中的位置做出修改，并反映到多个 Kong 集群上”。据推测，这将需要部署 Kong 集群，还需要安装 Cassandra 或 PostgreSQL 数据存储。

发布文档还指出，成功实现插件开发工具包（PDK）是现在标记为Kong 1.0 的其中一个原因。PDK 是一组Lua 函数和变量，可由定制插件使用，当工程师希望在Kong 中实现自己的逻辑时可以创建这样的插件。与从头开始编写插件相比，PDK 提供了许多优势，包括：标准化——所有Kong 插件都需要一套标准的功能，PDK 对此提供了开箱即用的支持；可用性——PDK 的接口比基本的ngx_lua API“易于使用”（参见 OpenResty lua_nginx_module ）；兼容性——PDK 的语义版本是为了保持向后兼容性，将来，插件将能够锁定它们所依赖的 PDK 版本。

其他与 Kong 竞争的“原生云”API 网关产品包括  KrakenD 、 Ambassador 、 Gloo 、 Contour 、 Gravatee 等。在代理领域，竞争对手包括 Envoy 、 NGINX 开源和 NGINX Plus 、 HAProxy 等。正如 InfoQ 电子期刊最近所讨论的那样，还有许多服务网格产品，包括 Istio 、 Linkerd 、 Consul Connect 。

变更日志提供了有关该Kong 版本的所有更改。在这个版本中有许多破坏性的变化，因此，建议工程师阅读 1.0 的建议升级路径。

查看英文原文： Kong 1.0 GA Released with Service Mesh Support and Plugin Development Kit