Kubernetes的Ingress控制器比較
翻譯：https://medium.com/flant-com/comparing-ingress-controllers-for-kubernetes-9b397483b46b
注意：此比較是受kubedex.com文章的啟發，該文章一直缺少我們需要的一些實際數據。請檢查它以及本文結尾處列出的其他有用鏈接。
標准
為了進行高質量的比較並獲得有用的結果，你必須對主題有一個很好的了解，但這還不是全部。你還需要一套特定的條件來設置研究載體。我們不假裝分析所有可能的Kubernetes Ingress/API網關/服務網格用例，但嘗試強調控制器的最常見要求。要成功完成你自己的案例，還必須研究每種情況的所有細節和特殊性。
讓我們從非常普遍的功能入手，以至於所有解決方案都已實現了這些功能，因此不予考慮：
- 開源（我們只是不想在K8s堆棧的這一級別上擁有其他選項）；
- 動態服務發現；
- SSL終止；
- 對WebSocket的支持。
現在，我們要進行比較：
支持的協議
這是做出選擇的基本參數。常規的HTTP(S)代理足以滿足您的軟件要求嗎？還是通過gRPC，HTTP/2.0工作？也許它還需要TCP（帶有SNI）或UDP？如果您的場景是非標准的，請確保進行了仔細考慮，以免以后再配置集群。每個控制器都有其自己的一組受支持的協議。
依賴（基礎軟件）
控制器的核心可以有幾種類型的應用程序。最受歡迎的是NGINX，Traefik，HAProxy，Envoy。通常，選擇可能不會嚴重影響您的流量處理方式，但是了解“潛在用戶”的潛在特征和習慣總是很有用的。
流量路由
將流量路由到特定服務的決定的依據是什么？通常，可以使用主機和路徑，但是還有其他可能性。匹配這些值是否也支持RegEx（正則表達式）？
命名空間限制
命名空間提供了一種邏輯上分離Kubernetes中資源的方法（例如，在生產，暫存等之間）。必須在每個名稱空間中分別安裝Ingress控制器（它們僅允許流量進入屬於該名稱空間的Pod）。並且有一些（實際上是絕大多數）在整個集群中全局運行。在這種情況下，流量可以去往任何Pod，而不管其名稱空間如何。
上游探針
您如何將流量定向到應用程序及其服務的正常實例？有主動和被動檢查，重試，熔斷器，自定義運行狀況檢查等解決方案。如果對可用性有嚴格的要求並迅速從負載平衡中刪除失敗的服務，則這是一個非常重要的參數。
負載均衡算法
在這里，我們有很多選擇，從傳統的輪詢到rdp-cookie等非常規的選擇。粘性會話在此類別中也很常見。
認證方式
控制器支持哪些授權方案？基本，摘要，OAuth，外部身份驗證...我想，你已經知道它們。如果我們為開發人員使用許多環境（層）和/或僅通過Ingress訪問的私有層，則這是一個重要參數。
流量分發
控制器是否支持常用的流量分配機制，如金絲雀部署，A / B測試，鏡像/陰影？對於需要精確和仔細的流量管理以進行富有成效的測試，調試生產錯誤且影響最小，流量分析等的應用程序，這是一個非常敏感的主題。
付費訂閱
控制器是否有帶擴展功能和/或技術支持的付費版本？
圖形用戶界面（Web UI）
有沒有用於控制器配置的圖形界面？對於那些希望使用便利和/或需要對Ingress的配置進行一些更改，而又希望避免使用“原始”模板的用戶而言，這一點很重要。如果開發人員想“即時”測試流量，它也很有用。
JWT驗證
是否有內置的JSON Web令牌驗證，用於對最終應用程序的用戶進行驗證和驗證？
定制配置
在具有允許您將自己的指令，標志等添加到標准配置模板的機制的意義上，模板具有可擴展性。
基本的DDOS保護機制
基本速率限制算法或基於地址，白名單，國家/地區等的流量過濾的更復雜的變體。
請求跟蹤
能夠通過OpenTracing或其他選項監視，跟蹤和調試從Ingress到特定服務/容器（最好在服務/容器之間）的請求。
WAF
支持Web應用程序防火牆。
Ingress控制器
控制器列表已從Kubernetes官方文檔開始，並擴展了其他知名選項。但是，由於特定的性質或較低的知名度/開發的早期階段，其中的一些被排除在外。其余內容在下面進行了檢查。我們將從總體描述開始，並在最后提供摘要表。
Kubernetes Ingress控制器
- github.com/kubernetes/ingress-nginx
- 語言實現：Go/Lua（而Nginx用C編寫）
- 許可證：Apache 2.0
Kubernetes的“官方”控制器。它是由社區開發的。您可能會從名稱中猜到，它基於nginx Web服務器，並補充了一組用於實現額外功能的Lua插件。
由於NGINX的普及以及在用作控制器時對其進行的最小改動，對於處理K8的普通工程師來說，它可能是最簡單，最直接的選擇。
NGINX Ingress控制器
- github.com/nginxinc/kubernetes-ingress
- 語言實現：Go/Python
- 許可證：Apache 2.0
這是NGINX開發人員的官方產品，該產品也具有基於NGINX Plus的商業版本。NGINX控制器具有很高的穩定性，持續的向后兼容性，沒有任何第三方模塊，並且由於消除了Lua代碼而保證了較高的速度（與官方控制器相比）。
即使與官方控制器相比，免費軟件版本也受到很大限制（由於缺少上述Lua模塊）。同時，付費版本具有相當廣泛的附加功能：實時指標，JWT驗證，活動的運行狀況檢查等。與NGINX Ingress相比，重要的優勢是對TCP / UDP流量的全面支持（在社區版本中也是如此！）。主要缺點是缺乏交通分配功能，盡管這項工作似乎正在進行中。
Kong
- github.com/Kong/kubernetes-ingress-controller
- 語言實現：Go
- 許可證：Apache 2.0
Kong Ingress由Kong Inc開發，並且有兩個版本：商業版本和免費版本。Kong Ingress建立在NGINX之上，並增加了擴展其功能的Lua模塊。
最初，它作為API網關專注於API請求的處理和路由。但是，到目前為止，它已成為成熟的Ingress控制器。它的主要優點是易於安裝和配置的大量其他模塊/插件（包括來自第三方開發人員的模塊/插件）。它為多種附加功能開辟了道路。附帶地，內置功能已經提供了許多可能性。使用CRD執行配置。
Kong的一個重要功能是它只能在一個環境中運行（而不是支持跨命名空間）。這是一個頗具爭議的話題：有些人認為它是一個缺點（必須為每個環境生成實例），而另一些人則認為它是一項特殊功能（較高的隔離度，因此一個控制器的故障影響僅限於其環境） ）。
Traefik
- github.com/containous/traefik
- 語言實現：Go
- 許可證：MIT
最初，此代理是為微服務請求及其動態環境的路由而創建的，因此具有許多有用的功能：連續更新配置（不重新啟動），支持多種負載平衡算法，Web UI，指標導出，支持各種協議，REST API，Canary版本等。開箱即用的“讓我們加密證書”支持是另一個不錯的功能。主要缺點是，為了組織控制器的高可用性，您必須安裝並連接其自己的KV存儲器。
雖然許多不錯的新功能（包括帶有SNI的TCP / SSL，金絲雀部署和流量鏡像/陰影，改進的Web UI）已經在Traefik v2.0的新版本（19年9月）中發布，但其中一些功能（例如WAF支持）已經發布還在討論中。
19年9月，引入了來自同一開發商的另一種服務網格解決方案。它被稱為Maesh，建在Traefik的頂部。
HAProxy
- github.com/jcmoraisjr/haproxy-ingress
- 語言實現：Go（而HAProxy用C編寫）
- 許可證：Apache 2.0
HAProxy是眾所周知的代理服務器和負載平衡器。作為Kubernetes集群的一部分，它提供了“軟”配置更新（無流量丟失），基於DNS的服務發現，通過API的動態配置。HAProxy還支持完全自定義配置文件模板（通過替換ConfigMap）以及在其中使用Spring Boot函數。通常，開發人員將重點放在已消耗資源的高速，優化和效率上。HAProxy的優點之一是大量受支持的平衡算法。
值得一提的是，在最近的（June'19）v2.0版本中出現了許多新功能，並且即將推出的v2.1有望具有更多的新功能（包括OpenTracing支持）。
Voyager
- github.com/appscode/voyager
- 語言實現：Go
- 許可證：Apache 2.0
Voyager基於HAProxy，並作為通用解決方案提供，適合大量提供商使用。它的顯着特點包括L7和L4流量均衡。通過一切手段，航海者TCP L4流量平衡可能被稱為該解決方案的主要特點之一。
雖然完整的HTTP / 2和GRPC協議的支持已經在今年早些時候出現（與V9.0.0版本），為支持證書管理的（支持讓的加密證書）可能是從那時起集成在航海最新的突出特點。
Contour
- github.com/heptio/contour
- 語言實現：Go
- 許可證：Apache 2.0
Contour不僅基於Envoy，而且還與該流行代理的作者共同開發。通過特殊的CRD（稱為IngressRoute的新API）管理Ingress資源的能力是其特殊功能。對於具有多個開發團隊並發使用一個集群的組織，這有助於保護相鄰環境中的流量並保護它們免受Ingress資源更改時產生的錯誤的影響。
它還提供了一組擴展的平衡算法（鏡像，自動重復，限制請求率等等），詳細的流量和故障監控。對於某些人來說，也許缺少對粘性會議的支持將是一個嚴重的缺陷（朝這個方向的持續努力已經走了很長一段路）。
Istio
- istio.io/docs/tasks/traffic-management/ingress
- 語言實現：轉到
- 許可證：Apache 2.0
Istio是IBM，Google和Lyft（Envoy的原始作者）的聯合項目，它是一個全面的服務網格解決方案。它不僅可以管理所有傳入的外部流量（作為Ingress控制器），還可以控制集群內部的所有流量。在幕后，Istio將Envoy用作每種服務的輔助代理。從本質上講，它是一個可以執行幾乎所有操作的大型處理器。其中心思想是最大程度的控制，可擴展性，安全性和透明性。
借助Istio Ingress，您可以微調流量路由，服務之間的訪問授權，平衡，監控，金絲雀發布等。
這里是學習Istio的精彩介紹：“ 使用Istio返回微服務 ”。
Ambassador
- github.com/datawire/ambassador
- 語言實現：Python
- 許可證：Apache 2.0
大使是另一個基於特使的解決方案。它有免費和商業版本。大使被描述為“微服務的Kubernetes原生API網關”，它帶來了相應的好處-例如與K8s原語的緊密集成。它具有Ingress控制器所期望的功能，也可以與各種服務網格解決方案（Consul，Linkerd，Istio）一起使用。
順便說一下，大使工程師最近發布了他們的基准測試結果，比較了Envoy（如Ambassador Pro），HAProxy和NGINX（如社區的官方Kubernetes Ingress）的性能。
Gloo
- github.com/solo-io/gloo
- 實施於：Go
- 許可證：Apache 2.0
Gloo是在Envoy之上構建的新軟件（於18年3月發布），被稱為“功能網關”，因為其作者堅持認為“網關應從功能而非服務中構建API 。”其“功能級路由”的意思是它可用於為后端為微服務，無服務器功能和/或舊版應用程序實現的混合應用程序路由流量。
Gloo具有可插拔的體系結構，可提供您可能期望的大多數功能，但是其中一些功能僅在其商業版本（Gloo Enterprise）中可用。它的文檔說明了如何輕松地將它與Linkerd＆Istio等服務網格解決方案集成。
Skipper
- github.com/zalando/skipper
- 語言實現：Go
- 許可證：Apache 2.0
Skipper是HTTP路由器和反向代理，因此不支持多種協議（例如，添加gRPC時沒有熱情）。從技術上講，它使用Endpoints API（而不是Kubernetes Services）將流量路由到Pod。它的巨大優勢是通過其豐富的過濾器集可以創建，更新和刪除所有HTTP數據的高級HTTP路由功能。船長的路由規則可以在不停機的情況下進行更新。正如Skipper的作者所言，它可以很好地與其他解決方案一起使用，例如提供其他功能的AWS ELB（與其他Ingress解決方案相比）。
這是 Skipper與它的作者（Zalando）制作的其他Kubernetes Ingress控制器的比較。
其他注意事項
在這里有Traefik和Istio時，您可能會注意到缺少另一個流行的服務網格解決方案-Linkerd。不列出的原因如下：
為簡單起見，Linkerd不提供其自己的入口控制器。相反，Linkerd旨在與您選擇的入口控制器一起使用。
比較表
本文的結尾是這個巨大的摘要表：
您可以單擊它以進行更詳細的查看。該表還提供Google表格格式。
摘要
本文的目的是提供對每種特定情況下可以完成的操作的更完整的理解（盡管一點也不詳盡！）。通常，每個控制器都有其優點和缺點。
Kubernetes官方Ingress易於使用，成熟，並提供了足以滿足大多數情況的出色功能。如果對可靠性和功能實現的質量有很高的要求，則應注意基於NGINX Plus的Ingress商業版本。Kong擁有最豐富的插件集（以及它們提供的機會），並且在其商業版本中提供了更多功能，它還擁有基於自定義資源的動態配置。
看看Traefik和HAProxy的如果有增加了平衡和授權方法的要求。它們是開源項目，多年來證明了自己的功能，非常穩定且不斷發展。Contour已經存在了兩年，但它看起來仍然很年輕，並且主要具有Envoy之上的基本功能。如果您需要在應用程序前面安裝WAF，請注意Kubernetes或HAProxy使用的舊Ingress。
基於Envoy的產品具有最豐富的功能集（尤其是Istio）。這是一個復雜的解決方案，“幾乎可以做任何事。”順便說一句，這意味着需要更廣泛的相關經驗來配置/運行/操作它們。在某些其他情況下（Gloo），其許多功能可能僅在付費版本中提供。如果您的應用程序需要高級或經常更改的HTTP路由表，那么Skipper可能是一個很好的解決方案。
如果我們談論什么全球K8S社區選擇的發展趨勢，Istio和Traefik的優勢是顯而易見的 - 甚至是“官方” Kubernetes入口是明顯落后的時候，我們比較的GitHub星（25000+，幾乎對20000小於6000相應）。Kong Ingress和HAProxy Ingress位於相對數量最少的恆星（小於1000）。
其他要參考的文章/評論
如果您選擇Ingress解決方案，以下是一些其他文章可能會有用：
- 入口由kubedex -一個漂亮的表（用簡短的文字）比較NGINX入口，香港，Traefik，HAProxy的，航海家，輪廓，大使，Istio入口，GLOO獨奏（我們已經使用此表來選擇我們的比較選項） ;
- 按第5層划分的服務網格格局—通過眾多參數（包括受支持的協議，多集群和多租戶功能，Prometheus和跟蹤集成）比較了大量的服務網格（以表格形式顯示）（約有30個！）；
- 我的Kubernetes環境最適合的入口控制器是什么？（由TFiR 撰寫於19年5 月） -NGINX Ingress（來自社區和NGINX Inc），Envoy，Kong，Google Cloud和AWS解決方案，Citrix Ingress的文字比較；
- Cayent的Kubernetes頂級入口控制器比較（19年9月） – Kong，Traefik，HAProxy，Istio Ingress，Nginx和大使的簡短文本比較；
- Kubernetes入口控制器：如何選擇合適的控制器：ITNEXT的第1部分 -Nginx入口控制器與AWS ALB入口控制器的相當深入的文字比較。