Kong API Gateway 的三種佈署模式

上班日又到來了，前一天的實踐完成了初步使用Kong API Gateway 來進行中介層的認證實踐，接著今天的任務要了解Kong API Gateway 的各種佈署模式。Kong API Gateway 的三種主要部署模式是 Classic (Database)、Hybrid 和 DB-less。

筆者的企業中有購買Kong API Gateway Enterprise Edition，當時也為了適應公司特性，選擇了Hybrid mode作為佈署方式。多年來在各種彈性使用的場景中，深刻的認知到這是一個非常優秀的產品。

先從各種佈署模式來討論：

Classic mode(資料庫)

這種經典模式在企業中非常常見，是將所有 Kong 節點直接連接到同一套資料庫（PostgreSQL），所有設定都儲存在資料庫中，節點從 DB 讀取與更新設定。

註：過去的Kong 還支援Cassandra 分散式資料庫，但從Kong Gateway 3.4 版本就開始終止支援。主因應該是支援過多後端儲存方式過於複雜，且現有各種模式已經可以應對複雜而多變須同步設定的環境，因此現在資料庫應該僅支援PostgreSQL。
參考連結：Why We’re Deprecating Cassandra Support

• 優點

  • 設定集中管理，更新即時生效。
  • 適合單一資料中心或網路延遲可接受的環境。

• 缺點

  • 節點依賴 DB，若 DB 故障，可能影響管理操作（雖然流量可繼續處理一段時間）。
  • 大規模跨地部署時，DB 延遲可能成為瓶頸。

圖5-1 Classic mode(資料庫)

Hybrid mode(混和模式)

混合模式，也稱為控制平面/資料平面分離（CP / DP），是一種部署模型，它將叢集中的所有 Kong Gateway 節點分割為以下兩個角色之一：

• 控制平面 (CP) 節點 - 用於管理組態並提供管理 API。
• 資料平面 (DP) 節點 - 為代理程式提供流量服務。

在混合模式下，資料庫只需要存在於控制平面節點(CP)上。每個 DP 節點都連接到一個 CP 節點，並且只有 CP 節點直接連接到資料庫。 DP 節點並非直接存取資料庫內容，而是與 CP 節點保持連線以接收最新設定參數。

這種混和模式優點非常多，列舉一些如下：

• 部署彈性： 使用者可以在不同的資料中心、地理位置或區域部署資料平面群組，而無需每個 DP 群組建立本機叢集資料庫。
• 可靠性提升： 資料庫的可用性不會影響資料平面的可用性。每個資料平面 (DP) 都會將從控制平面接收的最新配置快取到本機磁碟儲存，因此即使控制平面 ( CP) 節點發生故障，資料平面 (DP) 節點仍可繼續運作。
  • 當 CP 發生故障時，DP 節點會不斷嘗試重新建立通訊。
  • 當 CP 發生故障時，DP 節點可以重新啟動，並且仍能正常代理流量。
• 減少流量： 由於只有 CP 節點需要直接連接到資料庫，因此大幅減少了往返資料庫的流量。
• 提高安全性： 如果其中一個 DP 節點受到威脅，攻擊者將無法影響 Kong Gateway 叢集中的其他節點。
• 易於管理： 管理員只需與 CP 節點互動即可控制和監控整個 Kong Gateway 叢集的狀態。

這種模式優點非常的多，唯一需要考量的是，有一些Plugin 會因為需要將變更直接與資料庫互動，例如OAuth 2.0 Authentication。其他筆者則認為優點大於其限制，非常推薦這種佈署方式。
特別是企業中可能存在各種不同的佈署營運環境，從實體機到容器平台，地端到雲端，都可以透過Data Plane 可以廣泛支援各種平台而成為最彈性的選擇。
混和模式其他參考資料：Kong Hybrid mode

圖5-2 Hybrid Mode

👑DB-Less mode(無資料庫模式)

這次系列文主軸就是使用這種DB-Less mode，其實在混和模式的Data Plane節點，就是DB-Less mode的佈署方式。但與混和模式的Data Plane需要與Control Plane 同步設定資料的不同之處，純粹的DB-Less mode則是將相關設定檔案，以宣告式(declarative)的方式將所有設定寫入在Kong 節點中。

DB-Less mode可以降低複雜性並建立更靈活的部署模式。在這種模式下，已配置的實體（例如路由、服務和插件）會儲存在節點的記憶體中。在無資料庫模式下運作時，將使用第二個檔案向 Kong Gateway 提供設定。該檔案包含使用 Kong Gateway 宣告式(declarative)設定語法以 YAML 或 JSON 格式呈現的設定。

DB-Less mode和宣告式(declarative)設定的結合有許多好處：

• 減少依賴項的數量： 如果需求的Plugin 設定不需要任何資料庫的互動，就可以免去資料庫的安裝，以降低各種依賴項目風險的發生。
• 設定值始終處於已知狀態： 不同於設定到Control Plane會需要透過被同步到Data Plane，網路的傳遞可能會發生任何狀況，而宣告式設定則不會有這種問題。
• 設定變更管理優勢： DB-Less mode 非常適合 CI/CD 場景中的自動化。實體的設定值可以保存在 Git Repo作為管理的單一來源。

此模式有一些限制：

• 因為所有設定都被撰寫在設定檔中，管理API無法使用。
• 任何在資料庫中儲存資訊的插件（例如速率限制（叢集模式））都無法完全發揮作用。

圖5-3 DB-Less Mode

本日小結

過去的經驗

其實筆者在多年前，為組織規劃了使用混和模式(Hybrid mode)，當時的場景是需要協助多個子公司進行閘道(Data Plane / API Gateway)的佈署，控制中心則由筆者所屬的公司代為維運。

這種架構設計方式的優點，在於各子公司對於維運能力要求的不同，例如有些子公司需要7* 24維運要求，機房對於網路設備以即可恢復程度也投入較高成本。而筆者所在的公司則僅有5* 8 的維運要求，在這種狀況下，子公司所持有的Data Plane如果在遇到與Control Plane 之間的網路異常問題，也可以暫時持續提供API 服務給消費者。

而且Data Plane 可以彈性被佈署到不同的環境中，不論是實體主機或是VMWare，支援多種Linux版本。另外更相容於容器化平台，可以使用單體docker 或是支援K8S平台。這種彈性更讓筆者在過去數年可以協助不同的子公司完成各式各樣的任務。

曾經發生的災難

而為何本次系列文會以DB-Less作為範例來介紹，其實這跟曾經發生過的災難有關。前面有提到，子公司的Data Plane可以靈活被佈署到各種不同的環境進行服務。而且初始設計下，即使Data Plane 結點被重開機，也可以維持前次取得的設定值，持續提供服務。

但三年前曾經發生過，子公司是將Data Plane佈署在Open Shift 平台，以容器的形式存在。在網路一切通暢的狀況下，Data Plane 初始啟動時，會連線到Control Plane 上面將設定值同步回去開始提供服務，這不成問題。

然而，災難就是會發生在各種因素的綜合之下所導致，子公司當時希望升級Open Shift到另一個cluster中。但由於該平台的網路設定錯誤(應該是Egress)，導致Data Plane 與Control Plane的設定都無法同步。

容器化服務的初始化與一般作業系統不同，會從一個完全乾淨的容器開始，在無法同步設定檔的狀況下，表示服務無法使用。

當天雖然經歷過混亂，但也在當時接觸到DB-Less mode可以快速先協助緩解與排錯的優勢，才讓筆者突然意識到這種模式的優點。

探索DB-Less mode的魅力

過去三年，筆者在DevOps 領域打滾了許久，除了體會到要將程式碼進行版本控管的重要性以外，對於Infrasture as Code(IaC)也認為應該將相關設定納入版本控管倉之中。

這種DB-Less mode正是將設定檔給宣告出來，進而讓結點得以參考提供服務，這正符合了IaC的要求與精神。

筆者認為，這種模式搭配CI/CD，可以佈署到各式各樣不同的容器化世界中，並可以搭配金絲雀或是藍綠佈署，達到各節點變更管理的彈性與高可用性。

加上這種模式對於讀者來說，可以直接運行於Docker Desktop，搭配docker compose的佈署示範，可以免去讀者在學習時，還需要安裝資料庫的麻煩。

因此，本系列文將全部都以DB-Less mode作為後續的示範，希望各位讀者能夠有所得與相關啟發。

好啦，本日結束，明天再戰。