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管理的附加功能。Konghttp://has traditionally focused on">提供開源社區版和企業版。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