K8s 工程師必懂的 10 種 Ingress 控制器

點擊這裏，查看剩餘Ingress控制器及其餘重要內容

簡介： 爲了幫助讀者對 Ingress Controler 創建更完整的認識，今天，社區對現下流行的十種方案作了具體介紹。

爲特定的應用部署 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 測試、鏡像？對於須要精確流量管理、高效測試、最小影響進行錯誤調試、流量管理的應用來講，這個功能很是敏感。

關鍵字：Kubernetes 負載均衡 網絡協議 應用服務中間件 Go API Apache nginx 容器 Perl