淺談Kubernetes Ingress控制器的技術選型

導語：在Kubernetes的實踐、部署中，爲了解決 Pod 遷移、Node Pod 端口、域名動態分配等問題，須要開發人員選擇合適的 Ingress 解決方案。面對市場上衆多Ingress產品，開發者該如何分辨它們的優缺點？又該如何結合自身的技術棧選擇合適的技術方案呢？在本文中，騰訊雲中間件核心研發工程師厲輝將爲你介紹如何進行Kubernates Ingress 控制器的技術選型。（編輯：中間件小Q妹）

名詞解釋

閱讀本文須要熟悉如下基本概念：

• 集羣：是指容器運行所需雲資源的集合，包含了若干臺雲服務器、負載均衡器等雲資源。
• 實例（Pod）：由相關的一個或多個容器構成一個實例，這些容器共享相同的存儲和網絡空間。
• 工做負載（Node）：Kubernetes 資源對象，用於管理 Pod 副本的建立、調度以及整個生命週期的自動控制。
• 服務（Service）：由多個相同配置的實例（Pod）和訪問這些實例（Pod）的規則組成的微服務。
• Ingress：Ingress 是用於將外部 HTTP（S）流量路由到服務（Service）的規則集合。

Kubernetes 訪問現狀

△ Kubernetes 的外部訪問方式

在 Kubernetes 中，服務跟 Pod IP 主要供服務在集羣內訪問使用，對於集羣外的應用是不可見的。怎麼解決這個問題呢？爲了讓外部的應用可以訪問 Kubernetes 集羣中的服務，一般解決辦法是 NodePort 和 LoadBalancer。

這兩種方案其實各自都存在一些缺點：

• NodePort 的缺點是一個端口只能掛載一個 Service，並且爲了更高的可用性，須要額外搭建一個負載均衡。
• LoadBalancer 的缺點則是每一個服務都必需要有一個本身的 IP，不管是內網 IP 或者外網 IP。更多狀況下，爲了保證 LoadBalancer 的能力，通常須要依賴於雲服務商。

在Kubernetes的實踐、部署中，爲了解決像 Pod 遷移、Node Pod 端口、域名動態分配，或者是 Pod 後臺地址動態更新這種問題，就產生了 Ingress 解決方案。

Ingress 選型

Nginx Ingress 的缺點

Ingress 是 Kubernetes 中很是重要的外網流量入口。在Kubernetes中所推薦的默認值爲Nginx Ingress，爲了與後面Nginx 提供的商業版 Ingress 區分開來，我就稱它爲Kubernetes Ingress。

Kubernetes Ingress，顧名思義基於 Nginx 的平臺，Nginx 如今是世界上最流行的 Nginx HTTP Sever，相信你們都對 Nginx 也比較熟悉，這是一個優勢。它還有一個優勢是 Nginx Ingress 接入 Kubernetes 集羣所需的配置很是少，並且有不少文檔來指引你如何使用它。這對於大部分剛接觸 Kubernetes 的人或者創業公司來講，Nginx Ingress 的確是一個很是好的選擇。

可是當 Nginx Ingress 在一些大環境上使用時，就會出現不少問題：

• 第一個問題：Nginx Ingress用了一些 OpenResty 的特性，但最終配置加載仍是依賴於原有的 Nginx config reload。當路由配置很是大時，Nginx reload 會耗時好久，時間長達幾秒甚至十幾秒，這樣就會嚴重影響業務，甚至形成業務中斷。
• 第二個問題： Nginx Ingress 的插件開發很是困難。若是你認爲 Nginx Ingress 自己插件不夠用，須要使用一些定製化插件，這個額外的開發任務對程序員來講是十分痛苦的。 由於Nginx Ingress自身的插件能力和可擴展性很是差。

Ingress 選型原則

既然發現了 Nginx Ingress 有不少問題，那是否是考慮選擇其餘開源的、更好用的 Ingress？市場上比 Kubernetes Ingress 好用的Ingress起碼有十幾家，那麼如何從這麼多 Ingress 中選擇適合本身的呢？

Ingress 最終是基於 HTTP 網關的，市面上 HTTP 網關主要有這麼幾種：Nginx、Golang 原生的網關，以及新崛起的 Envoy 。可是每一個開發人員所擅長的技術棧不一樣，因此適合的 Ingress 也會不同。

那麼問題來了，咱們如何選擇一個更加好用的 Ingress 呢？或者縮小點範圍，熟悉 Nginx 或 OpenResty 的開發人員，應該選擇哪個 Ingress 呢？

下面來介紹一下我對 Ingress 控制器選型的一些經驗。

△ 選型原則

基本特色

首先我認爲Ingress 控制器應該具有如下基本功能，若是連這些功能都沒有，那徹底能夠直接pass。

• 必須開源的，不開源的沒法使用。
• Kubernetes 中 Pod 變化很是頻繁，服務發現很是重要。
• 如今 HTTPS 已經很普及了，TLS 或者 SSL 的能力也很是重要，好比證書管理的功能。
• 支持 WebSocket 等常見協議，在某些狀況下，可能還須要支持 HTTP2 、QUIC 等協議。

基礎軟件

前面有提到，每一個人擅長的技術平臺不同，因此選擇本身更加熟悉的 HTTP 網關也顯得相當重要。好比 Nginx、HAProxy、Envoy 或者是 Golang 原生網關。由於你熟悉它的原理，在使用中能夠實現快速落地。

在生產環境上，高性能是一個很重要的特性，但比之更重要的是高可用。這意味着你選擇的網關，它的可用性、穩定性必定要很是強，只有這樣，服務才能穩定。

功能需求

拋開上述兩點，就是公司業務對網關的特殊需求。你選擇一個開源產品，最好確定是開箱能用的。好比你須要 GRPC 協議轉換的能力，那固然但願選的網關具有這樣的功能。這裏簡單列一下影響選擇的因素：

• 協議：是否支持 HTTP二、HTTP3；
• 負載均衡算法：最基本的WRR、一致性哈希負載均衡算法是否可以知足需求，仍是須要更加複雜的相似EWMA負載均衡算法。
• 鑑權限流：僅須要簡單的鑑權，或更進階的鑑權方式。又或者須要集成，可以快速的開發出像騰訊雲 IM 的鑑權功能。Kubernetes Ingress除了前面咱們提到的存在Nginx reload 耗時長、插件擴展能力差的問題，另外它還存在後端節點調整權重的能力不夠靈活的問題。

選擇 APISIX 做爲 Ingress controller

相比Kubernetes Ingress，我我的更推薦 APISIX。雖然它在功能上比 Kong 會少不少，可是 APISIX 很好的路由能力、靈活的插件能力，以及自己的高性能，可以彌補在 Ingress 選型上的一些缺點。對於基於 Nginx 或 Openresty 開發的程序員，若是對如今的 Ingress 不滿意，我推薦大家去使用 APISIX 做爲 Ingress。

如何將 APISIX 做爲 Ingress 呢？咱們首先要作出一個區分，Ingress 是 Kubernetes 名稱的定義或者規則定義，Ingress controller 是將 Kubernetes 集羣狀態同步到網關的一個組件。但 APISIX 自己只是 API 網關，怎麼把 APISIX 實現成 Ingress controller 呢？咱們先來簡要了解一下如何實現 Ingress。

實現 Ingress，本質上就只有兩部份內容：

• 第一部分：須要將 Kubernetes 集羣中的配置、或 Kubernetes 集羣中的狀態同步到 APISIX 集羣。
• 第二部分：須要將 APISIX中 的一些概念，好比像服務、upstream 等概念定義爲 Kubernetes 中的 CRD。

若是實現了第二部分，經過 Kubernetes Ingress 的配置，即可以很快的產生 APISIX。經過 APISIX Ingress controller 就能夠產生 APISIX 相關的配置。當前爲了快速的將 APISIX 落地爲可以支持 Kubernetes 的 Ingress ，咱們建立了一個開源項目，叫 Ingress controller。

Ingress controller 架構圖

上圖爲Ingress controller 項目的總體架構圖。左邊部分爲 Kubernetes 集羣，這裏能夠導入一些 yaml 文件，對 Kubernetes 的配置進行變動。右邊部分則是 APISIX 集羣，以及它的控制面和數據面。從架構圖中能夠看出，APISIX Ingress 充當了 Kubernetes 集羣以及 APISIX 集羣之間的鏈接者。它主要負責監聽 Kubernetes 集羣中節點的變化，將集羣中的狀態同步到 APISIX 集羣。另外，因爲Kubernetes 倡導全部組件都要具有高可用的特性，因此在 APISIX Ingress 設計之初，咱們經過雙節點或多節點的模式來保證 APISIX  Ingress controller 的保障高可用。

總結

各種 Ingress 橫向對比

相對於市面上流行的 Ingress 控制器，咱們簡單對比來看看 APISIX Ingress 有什麼優缺點。上圖是外國開發人員針對 Kubernetes Ingress 選型作的一張表格。我在原來表格的基礎上，結合本身的理解，將 APISIX Ingress 的功能加入了進來。咱們能夠看到，最左邊的是APISIX，後邊就是 Kubernetes Ingress 和 Kong Ingress，後面的 Traefik，就是基於 Golang 的 Ingress。HAproxy 是比較常見的，過去是比較流行的負載均衡器。Istio 和 Ambassador 是國外很是流行的兩個Ingress。

接下來咱們總結下這些 Ingress各自的優缺點：

• APISIX Ingress：APISIX Ingress 的優勢前面也提到了，它具備很是強大的路由能力、靈活的插件拓展能力，在性能上表現也很是優秀。同時，它的缺點也很是明顯，儘管APISIX開源後有很是多的功能，可是缺乏落地案例，沒有相關的文檔指引你們如何使用這些功能。
• Kubernetes Ingress：即 Kubernetes 推薦默認使用的 Nginx Ingress。它的主要優勢爲簡單、易接入。缺點是Nginx reload耗時長的問題根本沒法解決。另外，雖然可用插件不少，但插件擴展能力很是弱。
• Nginx Ingress：主要優勢是在於它徹底支持 TCP 和 UDP 協議，可是缺失了鑑權方式、流量調度等其餘功能。
• Kong：其自己就是一個 API 網關，它也算是開創了先河，將 API 網關引入到 Kubernetes 中當 Ingress。另外相對邊緣網關，Kong 在鑑權、限流、灰度部署等方面作得很是好。Kong Ingress 還有一個很大的優勢：提供了一些 API、服務的定義，能夠抽象成 Kubernetes 的 CRD，經過Kubernetes Ingress 配置即可完成同步狀態至 Kong 集羣。缺點就是部署特別困難，另外在高可用方面，與 APISIX 相比也是相形見絀。
• Traefik ：基於 Golang 的 Ingress，它自己是一個微服務網關，在 Ingress 的場景應用比較多。他的主要平臺基於 Golang，自身支持的協議也很是多，整體來講是沒有什麼缺點。若是你們熟悉 Golang 的話，也推薦一用。
• HAproxy：是一個久負盛名的負載均衡器。它主要優勢是具備很是強大的負載均衡能力，其餘方面並不佔優點。
• Istio Ingress 和 Ambassador Ingress 都是基於很是流行的 Envoy。說實話，我認爲這兩個 Ingress 沒有什麼缺點，可能惟一的缺點是他們基於 Envoy 平臺，你們對這個平臺都不是很熟悉，上手門檻會比較高。

綜上所述，你們在瞭解了各個 Ingress 的優劣勢後，能夠結合自身狀況快速選擇適合本身的 Ingress。

做者介紹

厲輝，騰訊雲中間件API網關核心研發成員，Apache APISIX PPMC。熱愛開源，樂於分享，活躍於Apache APISIX社區。

歡迎掃碼關注咱們的微信公衆號，期待與你相遇~