本文可以為正在選型 Kubernetes Ingress Controller 產品的使用者提供一些幫助。
作者張晉濤,API7.ai 雲原生專家,Apache APISIX Committer、Kubernetes Ingress Nginx Reviewer
Apache APISIX Ingress
Apache APISIX Ingress 是一個使用 Apache APISIX 作為資料面的 Kubernetes Ingress controller 實現。
目前,它支援多種規則的配置方式,包括 Ingress、APISIX Ingress CRD (自定義資源)以及 Gateway API。
其整體採用資料面與控制面分離的架構,由 Apache APISIX 承載實際的業務流量。因此大大提升了整體的安全性,極大避免了由於資料面被攻擊而導致 Kubernetes 叢集被攻擊的可能。
Traefik
Traefik 是由 Traefik Labs 開源的一款反向代理和負載均衡器。它在 Kubernetes 中支援多種規則的配置方式,包括 Ingress、Traefik IngressRoute(自定義資源)和 Gateway API。
Traefik 是一個統一的二進位制檔案,控制面和資料面的代理邏輯均繫結在一起。因此,如果受到攻擊或者有遠端執行的安全漏洞被利用,極有可能存在 Kubernetes 叢集被攻擊的情況。
APISIX Ingress vs Traefik
接下來我將從以下幾個維度對 Apache APISIX Ingress 和 Traefik 進行一些對比,方便大家在選型時對產品有更多的認知。
協議支援
作為閘道器,最為核心的能力便是要能夠正確的代理流量。作為 Kubernetes 叢集的入口閘道器,主要處理如下兩部分的流量:即 Client 到閘道器的流量和閘道器與 Upstream 的流量。如下所示:
Client <----> Ingress <----> Upstream Service
當前的協議多種多樣,以下簡單彙總了兩個專案對協議的支援,僅供參考。
協議 | APISIX Ingress | Traefik |
---|---|---|
HTTP/HTTPS | 支援 | 支援 |
HTTP/2 | 支援 | 支援 |
HTTP/3 | 不支援 | 支援 |
TCP | 支援 | 支援 |
UDP | 支援 | 支援 |
WebSocket | 支援 | 支援 |
Dubbo | 支援 | 不支援 |
此外,無論是 APISIX Ingress 還是 Traefik,均可透過 HTTP/2 或者 TCP 代理等方式支援 gRPC、MQTT 等協議,故而未在上述表格中列出。
從協議支援的角度來看,APISIX Ingress 和 Traefik 各有優勢。此外,APISIX 對於 HTTP/3 的支援正在規劃中,後續也可隨時關注社群動態。
可擴充套件性
由於業務需求多種多樣,所以可擴充套件性也是進行技術選型的一個主要指標。APISIX Ingress 和 Traefik 均提供了一些擴充套件方式,我們將分別進行介紹。
APISIX Ingress
在 APISIX Ingress 中進行功能擴充套件,主要是透過開發自定義外掛來完成。當前,APISIX Ingress 主要支援如下幾種外掛的開發方式:
- 透過 Lua 進行外掛的開發:這種方式相對簡單,並且幾乎沒有效能損耗;
- 透過 Plugin Runner 開發:這種模式下支援 JAVA/Python/Go 等多種計算語言進行開發,方便使用者利用現有的業務邏輯,同時無需學習新語言;
- 透過 WASM 進行外掛外掛:這種模式下,可以使用任何支援構建出 WASM 的語言進行外掛開發;
此外,還可以透過 Serverless 外掛來直接編排 Lua 程式碼,滿足業務需求。
當然,如果你有 Lua 模組的開發經驗,也可以直接編寫 Lua 模組,然後進行載入即可,只需在配置檔案中增加如下內容即可:
apisix:
...
extra_lua_path: "/path/to/example/?.lua"
具體關於外掛的的開發步驟和使用,請參考 Apache APISIX 的外掛開發文件。
Traefik
Traefik 也提供了相關外掛機制用於功能擴充套件。但是 Traefik 是由 Go 進行開發的,因此它的外掛也需要用 Go 進行開發。
在開發完成後,就可以在 Traefik 的配置中新增如下內容進行引用了(需注意,外掛的名字需要與包名保持一致)。例如:
experimental:
localPlugins:
example:
moduleName: github.com/traefik/pluginproviderdemo
總體來看,APISIX Ingress 提供了更多種的擴充套件方式,可以根據實際情況進行靈活選擇。可以根據自己喜歡或擅長的工具即可,更容易實現與現有業務整合。而 Traefik 目前則只支援透過 Go 語言進行開發,選擇較少。
生態
在進行技術選型時候,除了考慮一些效能表現,還需要對產品的整個生態支援進行考察。比如專案所使用的協議、專案歸屬以及與現有基礎設施是否可以整合等等。下方簡單整理了幾個角度進行呈現(包含了控制面和資料面)。
對比維度 | APISIX Ingress | Traefik |
---|---|---|
歸屬 | Apache 軟體基金會(ASF) | Traefik Labs |
協議 | Apache 2.0 | MIT |
誕生時間 | 2019 年 6 月 | 2015 年 8 月 |
consul | 支援 | 支援 |
nacos | 支援 | 不支援 |
Eureka | 支援 | 不支援 |
etcd | 支援 | 支援 |
zookeeper | 支援 | 支援 |
DNS | 支援 | 不支援 |
此外,這兩個專案都非常積極與一些周邊專案進行了整合與合作。比如 Rancher、KubeSphere 等。
從生態合作角度來看,APISIX Ingress 比 Traefik 提供了更為廣泛的整合能力,尤其是與基礎元件。因此在進行技術選型時,可以結合當前自己所用的基礎元件的情況進行權衡。
來自使用者的聲音
在今年,我們也看到了很多來自使用者的聲音,他們開始在業務架構中用上了 APISIX Ingress。比如地平線使用 APISIX Ingress 替換了 Traefik,主要是考慮如下方面:
- 透過 Annotation 增加的配置不易重用;
- Traefik 中預設的行為與 NGINX 中不同,使用者在使用時候會產生困惑;
在切換為 Apache APISIX Ingress 後,得益於 APISIX Ingress 豐富的外掛生態,絕大多數需求均可透過內建外掛滿足。並且外掛的配置可直接透過 APISIX Ingress 的 ApisixRoute 資源進行定義,比較直觀。也可以透過 ApisixPluginConfig 進行外掛模板的配置,在其他的 ApisixRoute 資源中進行引用。
APISIX Ingress 的資料面效能更佳,能高效地應對日益增長的業務流量,而不會陷入效能瓶頸。
除地平線以外,包括少年得到,觀為智慧等公司也都使用 APISIX Ingress 替換了 Traefik,更多使用者案例請參考使用者案例。
此外,Apache APISIX 社群非常活躍,在 GitHub 和 Slack 等頻道上都會快速響應。也期待各位在社群積極進行反饋與討論。
總結
本文從協議支援、可擴充套件性和生態等方面對比了 Apache APISIX Ingress 和 Traefik。從內容中也可以看到,APISIX Ingress 在可擴充套件性和生態整合方面有一定的優勢,使用者可以更容易地對 APISIX Ingress 進行擴充套件,以及與一些基礎元件進行整合。
希望本文可以為正在選型 Kubernetes Ingress Controller 產品的使用者提供一些幫助。