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

创作场景

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