當為特定應用程序啟動 Kubernetes 集群時，您需要了解應用程序本身、業務和開發人員對該資源的貢獻。 有了這些信息，您就可以開始做出架構決策，特別是選擇特定的 Ingress 控制器，目前此類控制器的數量已經很多了。 為了獲得可用選項的基本概念，而無需閱讀大量文章/文檔等，我們準備了此概述，包括主要（生產就緒）Ingress 控制器。
我們希望它能幫助同事選擇架構解決方案——至少它將成為獲得更詳細信息和實際實驗的起點。 之前，我們在網上研究了其他類似的材料，奇怪的是，沒有找到一個或多或少完整的、最重要的是結構化的評論。 那麼讓我們來填補這個空白吧！
標準
原則上，為了進行比較並獲得任何有用的結果，您不僅需要了解主題領域，還需要有一個用於設置研究向量的特定標準列表。 在不假裝分析使用 Ingress / Kubernetes 的所有可能情況的情況下，我們試圖強調控制器的最一般要求 - 做好準備，在任何情況下，您都必須單獨研究所有細節和細節。
但我將從那些已經變得如此熟悉以至於在所有解決方案中實現但未被考慮的特徵開始：
- 服務的動態發現（service discovery）；
- SSL 終止；
- 使用網絡套接字。
現在來說說對比點：
支持的協議
基本選擇標準之一。 您的軟件可能無法在標準 HTTP 上運行，或者可能需要同時在多個協議上運行。 如果您的情況是非標準的，請務必考慮此因素，以便以後不必重新配置集群。 對於所有控制器，支持的協議列表各不相同。
以軟件為核心
該控制器所基於的應用程序有多種變體。 流行的有 nginx、traefik、haproxy、envoy。 在一般情況下，它可能對流量的接收和傳輸方式沒有太大影響，但了解“幕後”的潛在細微差別和特徵總是有用的。
流量路由
可以根據什麼來決定特定服務的流量方向？ 通常這些是主機和路徑，但還有其他可能性。
集群內的命名空間
命名空間（namespace）——在 Kubernetes 中邏輯分割資源的能力（例如，舞台上、生產上等）。 每個命名空間中必須單獨安裝 Ingress 控制器（然後它可以引導流量 僅 到該空間的吊艙）。 還有一些（以及它們的明顯大多數）在整個集群中全局工作 - 其中流量被定向到集群的任何 Pod，無論命名空間如何。
上游樣本
如何將流量引導至應用程序、服務的健康實例？ 有主動和被動檢查、重試、斷路器的選項 （有關更多詳細信息，請參見，例如， )、自己的健康檢查實現（自定義健康檢查）等。 如果您對可用性和及時從平衡中刪除失敗的服務有很高的要求，那麼這是一個非常重要的參數。
平衡算法
有很多選擇：從傳統的 到異國情調 ，以及諸如 .
認證
控制器支持哪些授權方案？ Basic、digest、oauth、external-auth - 我認為這些選項應該很熟悉。 如果有許多開發者（和/或只是私有）循環通過 Ingress 訪問，這是一個重要的標準。
流量分佈
控制器是否支持金絲雀部署（canary）、A/B測試、流量鏡像（mirroring/shadowing）等常用的流量分配機制？ 對於需要精確的流量管理來進行高效測試、離線調試產品錯誤（或以最小的損失）、流量分析等的應用程序來說，這是一個非常痛苦的話題。
付費訂閱
控制器是否有付費選項，具有高級功能和/或技術支持？
圖形用戶界面（Web UI）
是否有任何 GUI 來管理控制器配置？ 主要是為了“方便”和/或需要對 Ingress 的配置進行一些更改，但使用“原始”模板很不方便。 如果開發人員想要對動態流量進行一些實驗，它可能會很有用。
JWT 驗證
存在內置的 JSON Web 令牌驗證，用於用戶對最終應用程序的授權和驗證。
配置定制的可能性
模板可擴展性是指擁有允許您將自己的指令、標誌等添加到標準配置模板的機制。
基本的DDOS防護機制
簡單的速率限制算法或更複雜的基於地址、白名單、國家/地區等的流量過濾選項。
請求跟踪
能夠監視、跟踪和調試從 Ingress 到特定服務/Pod 的請求，最好也是在服務/Pod 之間進行請求。
WAF
支持 .
控制器
控制者名單的形成基於 и 。 由於特異性或流行率低（發展早期），我們將其中一些排除在審查之外。 其餘的將在下面討論。 讓我們從解決方案的一般描述開始，然後使用匯總表。
來自 Kubernetes 的入口
網址：
許可證：Apache 2.0
這是 Kubernetes 的官方控制器，由社區開發。 從名字上可以明顯看出，它是基於 nginx 的，並輔以一組不同的 Lua 插件，用於實現附加功能。 由於 nginx 本身的受歡迎程度以及用作控制器時對其進行的最小修改，對於普通工程師（具有 Web 經驗）來說，此選項可能是最簡單且最容易配置的。
NGINX Inc. 的 Ingress
網址：
許可證：Apache 2.0
nginx 開發者的官方產品。 有一個基於的付費版本 。 主要思想是高度的穩定性、持續的向後兼容性、沒有任何無關的模塊以及宣稱的速度提高（與官方控制器相比），這是由於拒絕 Lua 而實現的。
免費版本顯著減少，甚至與官方控制器相比（由於缺少相同的 Lua 模塊）。 同時，付費版還具有相當廣泛的附加功能：實時指標、JWT 驗證、主動健康檢查等。 相對於 NGINX Ingress 的一個重要優勢是完全支持 TCP / UDP 流量（社區版本也是如此！）。 減 - 流量分配功能雖然“對開發者來說是最優先考慮的”，但實施起來還需要時間。
金剛入口
網址：
許可證：Apache 2.0
Kong Inc. 開發的產品有兩個版本：商業版和免費版。 基於nginx，擴展了大量Lua模塊。
最初，它專注於處理和路由 API 請求，即作為一個 API 網關，但目前它已經成為一個成熟的 Ingress 控制器。 主要優點：許多附加模塊（包括來自第三方開發人員的模塊）易於安裝和配置，並在其幫助下實現了廣泛的附加功能。 然而，內置函數已經提供了許多可能性。 作業配置是使用 CRD 資源完成的。
該產品的一個重要功能 - 在同一輪廓內工作（而不是跨命名空間）是一個有爭議的話題：對於某些人來說，這似乎是一個缺點（您必須為每個輪廓生成實體），而對於某些人來說，這是一個功能（乙о更高級別的隔離，如如果一個控制器損壞，則問題僅限於電路）。
特拉菲克
網址：
許可證：麻省理工學院
最初創建的代理是為了處理微服務及其動態環境的請求路由。 因此，有許多有用的功能：無需重新啟動即可更新配置、支持大量平衡方法、Web 界面、指標轉發、支持各種協議、REST API、金絲雀版本等等。 另一個不錯的功能是對 Let's Encrypt 證書的開箱即用支持。 缺點是為了組織高可用性（HA），控制器需要安裝並連接自己的 KV 存儲。
HAProxy的
網址：
許可證：Apache 2.0
HAProxy 長期以來一直被稱為代理和流量平衡器。 作為 Kubernetes 集群的一部分，它提供“軟”配置更新（不丟失流量）、基於 DNS 的服務發現、使用 API 的動態配置。 通過替換 CM 來完全自定義配置模板以及使用其中的 Sprig 庫函數的能力可能很有吸引力。 一般來說，該解決方案的主要重點是高速、優化和資源消耗效率。 該控制器的優點是支持創紀錄數量的不同平衡方法。
航海家
網址：
許可證：Apache 2.0
基於HAproxy控制器，其定位為通用解決方案，支持大量提供商的廣泛功能。 提供了在 L7 和 L4 上平衡流量的機會，並且平衡 TCP L4 流量作為一個整體可以稱為該解決方案的關鍵功能之一。
輪廓
網址：
許可證：Apache 2.0
該解決方案不僅基於 Envoy：它是由 共同 與這個流行代理的作者。 一個重要的功能是能夠使用 IngressRoute CRD 資源單獨控制 Ingress 資源。 對於擁有多個使用同一集群的開發團隊的組織來說，這有助於最大限度地提高相鄰循環中流量的安全性，並在更改 Ingress 資源時保護它們免受錯誤的影響。
它還提供了一組擴展的平衡方法（有請求鏡像、自動重複、限制請求速率等等）、對流量和故障的詳細監控。 也許對於某些人來說，缺乏對粘性會話的支持將是一個重大缺點（儘管工作 ).
Istio Ingress
網址：
許可證：Apache 2.0
全面的服務網格解決方案，不僅是管理外部傳入流量的入口控制器，而且還控制集群內的所有流量。 在底層，Envoy 被用作每個服務的 sidecar 代理。 本質上，這是一個“無所不能”的大聯合體，其主要思想是最大限度的可管理性、可擴展性、安全性和透明度。 有了它，您可以微調流量路由、服務之間的訪問授權、平衡、監控、金絲雀發布等等。 在系列文章中閱讀有關 Istio 的更多信息““。
大使
網址：
許可證：Apache 2.0
另一種基於 Envoy 的解決方案。 它有免費版和商業版。 它的定位是“完全原生於 Kubernetes”，從而帶來了相應的優勢（與 K8s 集群的方法和實體緊密集成）。
比較表
因此，本文的高潮是這張巨大的表格：
可以點擊查看更近的視圖，也可以採用以下格式 .
總結
本文的目的是讓您更全面地了解（但絕不是詳盡無遺！）在您的特定情況下應該做出什麼選擇。 像往常一樣，每個控制器都有自己的優點和缺點......
Kubernetes 的經典 Ingress 因其可用性和驗證性良好，功能足夠豐富——一般情況下，它應該“足夠養眼”。 但是，如果對穩定性、功能水平和開發水平有更高的要求，您應該關注帶有 NGINX Plus 和付費訂閱的 Ingress。 Kong 擁有最豐富的插件集（以及相應的它們提供的機會），而在付費版本中，插件數量甚至更多。 它有足夠的機會充當 API 網關、基於 CRD 資源的動態配置以及基本 Kubernetes 服務。
隨著對平衡和授權方法的要求不斷增加，請查看 Traefik 和 HAProxy。 這些都是開源項目，經過多年的驗證，非常穩定並且正在積極發展。 Contour 已經推出幾年了，但它看起來仍然太年輕，並且只在 Envoy 之上添加了基本功能。 如果應用程序前面有 WAF 存在/嵌入的要求，則應注意來自 Kubernetes 或 HAProxy 的相同 Ingress。
功能最豐富的是基於 Envoy 構建的產品，尤其是 Istio。 它似乎是一個“無所不能”的綜合解決方案，然而，這也意味著配置/啟動/管理的入門門檻比其他解決方案要高得多。
我們選擇並仍然使用 Kubernetes 的 Ingress 作為標準控制器，它可以滿足 80-90% 的需求。 它非常可靠，易於配置和擴展。 一般來說，在沒有特定要求的情況下，它應該適合大多數集群/應用程序。 同樣通用且相對簡單的產品中，可以推薦Traefik和HAProxy。
聚苯乙烯
另請閱讀我們的博客：
- “回到 Istio 的微服務”： , , ;
- «“;
- «“。
來源： www.habr.com