為特定的應用部署 Kubernetes 叢集時，我們通常需要實作來自應用程式本身、業務和開發人員的需求。了解這些後，我們就可以進行架構選擇，并為 Kubernetes 選擇合适的 Ingress 控制器。
為了友善工程師高效選用合适的 Ingress 控制器，本文對業内的 Ingress 控制器做了整理和功能梳理，最後總結成一篇綜述。借助這篇文章，希望讀者能找到一個好的起點，然後開始自己的實踐。
選擇标準
為了進行客觀對比并得到有用的結果，首先我們需要一套特定的标準來确定研究方向。注意，以下評測并不能涵蓋所有 Kubernetes Ingress、API 網關、服務網格用例，但會盡可能覆寫常見要求。如果讀者希望把評測結果用于自己的案例，建議結合自己的實踐再研究一下細節和特殊性。
首先是一些非常普遍的功能，所有解決方案都已實作了它們，是以你不需要對它們過多關注：
開源；
動态服務發現；
SSL 終止；
對 WebSocket 的支援。
支援的協定
這就像是工程師選擇 Ingress 控制器時的基本“參數”。正常的 HTTP(S) 代理能夠滿足軟體要求嗎？還是需要通過 gRPC、HTTP/2.0？或是需要 TCP（帶有 SNI）、UDP？如果你的情況不是特别正常，建議仔細考慮這些問題，防止以後需要重新配置叢集。每個控制器都有自己的一組受支援的協定。
基于（基礎軟體）
控制器的核心可以有幾種類型的應用程式，比如最受歡迎的 NGINX、Traefik、HAProxy 和 Envoy 等。通常情況下，這些選擇不會對你的流量處理方式産生巨大影響，但是了解“底層”的潛在特性和習慣總是有用的。
流量路由
将流量路由到特定服務的決策依據是什麼？通常你可以用 host 和 path，但也有其他的可能性。比對這些值是否也支援 RegEx（正規表達式）？
命名空間限制
命名空間提供了一種邏輯上分離 Kubernetes 中資源的方法。有些 Ingress 控制器必須被裝在不同的命名空間中，它們的作用是僅允許流量進入屬于該命名空間的 Pod。而大多數 Ingress 控制器是針對整個叢集進行全局操作的，在這種情況下，流量可以到達任何 Pod，而無需考慮其命名空間。
上遊探針
如何将流量定向到應用程式及其服務的正常執行個體？通常你有主動和被動檢查、重試、斷路器、自定義運作狀況檢查等解決方案。如果你對可用性有嚴格的要求，并希望迅速從負載均衡中删除失敗的服務，這個功能非常重要。
負載均衡算法
對于負載均衡我們有很多選擇，從傳統的 round-robin 到非傳統的 rdp-cookie。粘滞會話（Sticky Sessions）在這裡也很常見。
認證方式
控制器支援哪些認證方式？Basic、digest、OAuth、external auth……如果你為開發人員使用了許多環境（層），或僅通過 Ingress 通路的私有層，這是個值得注意的功能。
流量配置設定
控制器是否支援常用的流量配置設定機制，如金絲雀部署、A/B 測試、鏡像？對于需要精确流量管理、高效測試、最小影響進行錯誤調試、流量管理的應用來說，這個功能非常敏感。
付費訂閱
控制器是否有帶擴充功能或技術支援的付費版本？
圖形使用者界面（Web UI）
有用于控制器配置的圖形界面嗎？這個功能對于那些喜歡簡單友善，或是需要對 Ingress 配置做一些更改的人很有用。如果開發人員希望“即時”測試流量，它也非常有用。
JWT 驗證
是否有内置的 JSON Web 令牌驗證，用于對最終應用程式的使用者進行驗證和确認？
定制配置
模闆是否具備可擴充性，允許你将自己的指令、參數等添加到标準配置模闆上？
基本的 DDOS 保護機制
基本請求速率，或基于位址、白名單、國家/地區等的流量過濾的更複雜變體。
請求跟蹤
能夠通過 OpenTracing 或其他選項監視、跟蹤、調試從 Ingress 到特定服務、Pod（最好是在服務和 Pod 之間）的請求。
WAF
支援 Web 應用程式防火牆。
Ingress 控制器
這一節将從 Kubernetes 官方控制器開始，逐漸擴充到其他廣為人知的 Ingress 控制器。
Kubernetes Ingress Controller
github.com/kubernetes/ingress-nginx
實作：Go/Lua（nginx 是用 C 寫的）
許可證：Apache 2.0
Kubernetes 的“官方”控制器（之是以稱為官方，是想把它差別于 NGINX 公司的控制器）。這是社群開發的控制器，它基于 nginx Web 伺服器，并補充了一組用于實作額外功能的 Lua 插件。
由于 NGINX 十分流行，再加上把它用作控制器時所需的修改較少，它對于 K8s 普通工程師來說，可能是最簡單和最直接的選擇。
NGINX Ingress Controller
github.com/nginxinc/kubernetes-ingress
實作：Go
這是 NGINX 公司開發的官方産品，它也有一個基于 NGINX Plus 的商業版。NGINX 的控制器具有很高的穩定性、持續的向後相容性，且沒有任何第三方子產品。
由于消除了 Lua 代碼，和官方控制器相比，它保證了較高的速度，但也是以受到較大限制。相較之下，它的付費版本有更廣泛的附加功能，如實時名額、JWT 驗證、主動健康檢查等。
NGINX Ingress 重要的優勢是對 TCP/UDP 流量的全面支援，最主要缺點是缺乏流量配置設定功能。
Kong Ingress
github.com/Kong/kubernetes-ingress-controller
Kong Ingress 由 Kong Inc 開發，有兩個版本：商業版和免費版。它基于 NGINX 建構，并增加了擴充其功能的 Lua 子產品。
最初，Kong Ingress 主要用作 API 網關，用于 API 請求的處理和路由。現在，它已經成為成熟的 Ingress 控制器，主要優點是擁有大量易于安裝和配置的附加子產品、插件（包括第三方插件）。它開啟了控制器具備大量附加功能的先河，其内置函數也提供了許多可能性。Kong Ingress 配置是用 CRD 執行的。
Kong Ingress 的一個重要特性是它隻能在一個環境中運作（而不支援跨命名空間）。這是一個頗有争議的話題：有些人認為這是一個缺點，因為必須為每個環境生成執行個體；而另一些人認為這是一個特殊特性，因為它是更進階别的隔離，控制器故障的影響僅限于其所在的環境。
Traefik
github.com/containous/traefik
許可證：MIT
最初，這個代理是為微服務請求及其動态環境的路由而建立的，是以具有許多有用的功能：連續更新配置（不重新啟動）、支援多種負載均衡算法、Web UI、名額導出、對各種服務的支援協定、REST API、Canary 版本等。
支援開箱即用的 Let’s Encrypt 是它的另一個不錯的功能，但它的主要缺點也很明顯，就是為了控制器的高可用性，你必須安裝并連接配接其 Key-value store。
在 2019 年 9 月釋出的 Traefik v2.0 中，雖然它增加許多不錯的新功能，如帶有 SNI 的 TCP/SSL、金絲雀部署、流量鏡像/shadowing 和經過改進的 Web UI，但一些功能（如 WAF 支援）還在策劃讨論中。
與新版本同期推出的還有一個名叫 Maesh 的服務網格，它建在 Traefik 之上。
HAProxy Ingress
github.com/jcmoraisjr/haproxy-ingress
實作：Go（HAProxy 是用 C 寫的）
HAProxy 是衆所周知的代理伺服器和負載均衡器。作為 Kubernetes 叢集的一部分，它提供了“軟”配置更新（無流量損失）、基于 DNS 的服務發現和通過 API 進行動态配置。 HAProxy 還支援完全自定義配置檔案模闆（通過替換 ConfigMap）以及在其中使用 Spring Boot 函數。
通常，工程師會把重點放在已消耗資源的高速、優化和效率上。而 HAProxy 的優點之一正是支援大量負載均衡算法。值得一提的是，在今年 6 月釋出的 v2.0 中，HAProxy 增加了許多新功能，其即将推出的 v2.1 有望帶來更多新功能（包括 OpenTracing 支援）。
Voyager
github.com/appscode/voyager
Voyager 基于 HAProxy，并作為一個通用的解決方案提供給大量供應商。它最具代表性的功能包括 L7 和 L4 上的流量負載均衡，其中，TCP L4 流量負載均衡稱得上是該解決方案最關鍵的功能之一。
在今年早些時候，盡管 Voyager 在 v9.0.0 中推出了對 HTTP/2 和 gRPC 協定的全面支援，但總的來看，對證書管理（Let’s Encrypt 證書）的支援仍是 Voyager 內建的最突出的新功能。
Contour
github.com/heptio/contour
Contour 和 Envoy 由同一個作者開發，它基于 Envoy。它最特别的功能是可以通過 CRD（IngressRoute）管理 Ingress 資源，對于多團隊需要同時使用一個叢集的組織來說，這有助于保護相鄰環境中的流量，使它們免受 Ingress 資源更改的影響。
它還提供了一組擴充的負載均衡算法（鏡像、自動重複、限制請求率等），以及詳細的流量和故障監控。對某些工程師而言，它不支援粘滞會話可能是一個嚴重缺陷。
Istio Ingress
istio.io/docs/tasks/traffic-management/ingress
Istio 是 IBM、Google 和 Lyft 的聯合開發項目，它是一個全面的服務網格解決方案——不僅可以管理所有傳入的外部流量（作為 Ingress 控制器），還可以控制叢集内部的所有流量。
Istio 将 Envoy 用作每種服務的輔助代理。從本質上講，它是一個可以執行幾乎所有操作的大型處理器，其中心思想是最大程度的控制、可擴充性、安全性和透明性。
通過 Istio Ingress，你可以對流量路由、服務之間的通路授權、均衡、監控、金絲雀釋出等進行優化。
Ambassador
github.com/datawire/ambassador
實作：Python
Ambassador 也是一個基于 Envoy 的解決方案，它有免費版和商業版兩個版本。
Ambassador 被稱為“Kubernetes 原生 API 微服務網關”，它與 K8s 原語緊密內建，擁有你所期望的從 Ingress controller 獲得的功能包，它還可以與各種服務網格解決方案，如 Linkerd、Istio 等一起使用。
順便提一下，Ambassador 部落格日前釋出了一份基準測試結果，比較了 Envoy、HAProxy 和 NGINX 的基礎性能。
Gloo
github.com/solo-io/gloo
Gloo 是在 Envoy 之上建構的新軟體（于 2018 年 3 月釋出），由于它的作者堅持認為“網關應該從功能而不是服務中建構 API”，它也被稱為“功能網關”。其“功能級路由”的意思是它可以為後端實作是微服務、無伺服器功能和遺留應用的混合應用路由流量。
由于擁有可插拔的體系結構，Gloo 提供了工程師期望的大部分功能，但是其中一些功能僅在其商業版本（Gloo Enterprise）中可用。
Skipper
github.com/zalando/skipper
Skipper 是 HTTP 路由器和反向代理，是以不支援各種協定。從技術上講，它使用 Endpoints API（而不是 Kubernetes Services）将流量路由到 Pod。它的優點在于其豐富的過濾器集所提供的進階 HTTP 路由功能，工程師可以借此建立、更新和删除所有 HTTP 資料。
Skipper 的路由規則可以在不停機的情況下更新。正如它的作者所述，Skipper 可以很好地與其他解決方案一起使用，比如 AWS ELB。
其他
文章介紹了 Traefik 和 Istio，卻沒有詳細介紹另一個流行的服務網格解決方案 Linkerd。這是為什麼呢？
為簡單起見，Linkerd 沒有提供自己的 Ingress 控制器，而是旨在和工程師選用的控制器相容使用。
總結
下表是各種 Ingress 控制器的摘要：
本文旨在盡可能讓讀者對 Ingress 控制器形成更完整的了解，因為每種控制器都有其優點和缺點。
- 社群官方的 Ingress 控制器成熟、易于使用，并提供了足以滿足大多數情況的出色功能；
- 如果對可靠性和功能實作的品質有很高的要求，NGINX Ingress 的商業版會是一個合适的選擇；
- Kong 擁有最豐富的插件集，在其商業版本中也提供了更多功能，它還擁有基于自定義資源的動态配置；
- 如果比較關注負載均衡和授權，請看看 Traefik 和 HAProxy。它們是開源項目，功能已經經過社群多年驗證，非常穩定，而且還在不斷發展；
- Contour 雖然隻有兩歲，但它已經具備 Envoy 之上的基礎功能；
- 基于 Envoy 的解決方案擁有最豐富的功能集，尤其是 Istio。但這是一個複雜的解決方案，意味着工程師需要具備更多相關經驗來配置、運作、操作它們；
- 在某些其他情況下，Gloo 的許多功能可能隻在付費版本中提供；
- 如果你的應用程式需要進階或經常更改的 HTTP 路由表，那麼 Skipper 可能是一個很合适的解決方案。
如果比較的是全球社群的選擇趨勢，那麼 Istio（20k+⭐）和 Traefik（超過 25k⭐）的優勢就顯而易見了。即使是社群官方控制器，它也明顯處于下風（不到 6k⭐）。相對的，Kong Ingress 和 HAProxy Ingress 最不熱門，隻有不到 1k⭐。