Kong for Kubernetes 0.8釋出 提供一致的API管理生命週期

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版本對基於路徑的路由進行了重大更改，並且不建議使用某些註釋，該更新日誌有變化的完整列表。