為特定的應用部署 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
許可證：Apache 2。0
這是 NGINX 公司開發的官方產品，它也有一個基於 NGINX Plus 的商業版。NGINX 的控制器具有很高的穩定性、持續的向後相容性，且沒有任何第三方模組。
由於消除了 Lua 程式碼，和官方控制器相比，它保證了較高的速度，但也因此受到較大限制。相較之下，它的付費版本有更廣泛的附加功能，如實時指標、JWT 驗證、主動健康檢查等。
NGINX Ingress 重要的優勢是對 TCP/UDP 流量的全面支援，最主要缺點是缺乏流量分配功能。
Kong Ingress
github。com/Kong/kubernetes-ingress-controller
實現：Go
許可證：Apache 2。0
Kong Ingress 由 Kong Inc 開發，有兩個版本：商業版和免費版。它基於 NGINX 構建，並增加了擴充套件其功能的 Lua 模組。
最初，Kong Ingress 主要用作 API 閘道器，用於 API 請求的處理和路由。現在，它已經成為成熟的 Ingress 控制器，
主要優點是擁有大量易於安裝和配置的附加模組、外掛（包括第三方外掛）
。它開啟了控制器具備大量附加功能的先河，其內建函式也提供了許多可能性。Kong Ingress 配置是用 CRD 執行的。
Kong Ingress 的一個重要特性是它只能在一個環境中執行（而不支援跨名稱空間）。這是一個頗有爭議的話題：有些人認為這是一個缺點，因為必須為每個環境生成例項；而另一些人認為這是一個特殊特性，因為它是更高級別的隔離，控制器故障的影響僅限於其所在的環境。
Traefik
github。com/containous/traefik
實現：Go
許可證：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 寫的）
許可證：Apache 2。0
HAProxy 是眾所周知的代理伺服器和負載均衡器。作為 Kubernetes 叢集的一部分，它提供了“軟”配置更新（無流量損失）、基於 DNS 的服務發現和透過 API 進行動態配置。 HAProxy 還支援完全自定義配置檔案模板（透過替換 ConfigMap）以及在其中使用 Spring Boot 函式。
通常，工程師會把重點放在已消耗資源的高速、最佳化和效率上。而 HAProxy 的優點之一正是支援大量負載均衡演算法。值得一提的是，在今年 6 月釋出的 v2。0 中，HAProxy 增加了許多新功能，其即將推出的 v2。1 有望帶來更多新功能（包括 OpenTracing 支援）。
Voyager
github。com/appscode/voyager
實現：Go
許可證：Apache 2。0
Voyager 基於 HAProxy，並作為一個通用的解決方案提供給大量供應商。它最具代表性的功能包括 L7 和 L4 上的流量負載均衡，其中，
TCP L4 流量負載均衡稱得上是該解決方案最關鍵的功能之一
。
在今年早些時候，儘管 Voyager 在 v9。0。0 中推出了對 HTTP/2 和 gRPC 協議的全面支援，但總的來看，對證書管理（Let’s Encrypt 證書）的支援仍是 Voyager 整合的最突出的新功能。
Contour
github。com/heptio/contour
實現：Go
許可證：Apache 2。0
Contour 和 Envoy 由同一個作者開發，它基於 Envoy。
它最特別的功能是可以透過 CRD（IngressRoute）管理 Ingress 資源
，對於多團隊需要同時使用一個叢集的組織來說，這有助於保護相鄰環境中的流量，使它們免受 Ingress 資源更改的影響。
它還提供了一組擴充套件的負載均衡演算法（映象、自動重複、限制請求率等），以及詳細的流量和故障監控。對某些工程師而言，它不支援粘滯會話可能是一個嚴重缺陷。
Istio Ingress
istio。io/docs/tasks/traffic-management/ingress
實現：Go
許可證：Apache 2。0
Istio 是 IBM、Google 和 Lyft 的聯合開發專案，它是一個全面的服務網格解決方案——
不僅可以管理所有傳入的外部流量（作為 Ingress 控制器），還可以控制叢集內部的所有流量
。
Istio 將 Envoy 用作每種服務的輔助代理。從本質上講，它是一個可以執行幾乎所有操作的大型處理器，其中心思想是最大程度的控制、可擴充套件性、安全性和透明性。
透過 Istio Ingress，你可以對流量路由、服務之間的訪問授權、均衡、監控、金絲雀釋出等進行最佳化。
Ambassador
github。com/datawire/ambassador
實現：Python
許可證：Apache 2。0
Ambassador 也是一個基於 Envoy 的解決方案，它有免費版和商業版兩個版本。
Ambassador 被稱為“Kubernetes 原生 API 微服務閘道器”
，它與 K8s 原語緊密整合，擁有你所期望的從 Ingress controller 獲得的功能包，它還可以與各種服務網格解決方案，如 Linkerd、Istio 等一起使用。
順便提一下，Ambassador 部落格日前釋出了一份基準測試結果，比較了 Envoy、HAProxy 和 NGINX 的基礎效能。
Gloo
github。com/solo-io/gloo
實現：Go
許可證：Apache 2。0
Gloo 是在 Envoy 之上構建的新軟體（於 2018 年 3 月釋出），由於它的作者堅持認為“閘道器應該從功能而不是服務中構建 API”，它也被稱為“功能閘道器”。其“功能級路由”的意思是它可以為後端實現是微服務、無伺服器功能和遺留應用的混合應用路由流量。
由於擁有可插拔的體系結構，Gloo 提供了工程師期望的大部分功能，但是其中一些功能僅在其商業版本（Gloo Enterprise）中可用。
Skipper
github。com/zalando/skipper
實現：Go
許可證：Apache 2。0
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⭐。
