APISIX Ingress VS Ingress NGINX詳細對比
Kubernetes 中的服務可以通過 Ingress 暴露出來，流量路由由 Ingress 資源上定義的規則控制，通常需要 Ingress controller 負責實現。本文將會對比兩個比較流行的 Ingress controller 實現，希望能對讀者進行 Ingress controller 選型中有所幫助。
Ingress NGINX 是 Kubernetes 社區實現的 Ingress controller，在社區中被廣泛使用。Apache APISIX Ingress 則是 Apache 軟件基金會下的開源項目，使用 APISIX 作為數據面的 Kubernetes Ingress controller。Ingress NGINX vs APISIX Ingress功能對比下列表格中，對比了 Ingress NGINX 和 APISIX Ingress 基本功能，包括協議支持、鑒權方式、上游探針/策略、負載均衡策略、Kubenertes 集成等。以下表格數據取自learnk8s.io。
|
Product/Project |
Ingress NGINX |
Apache APISIX Ingress |
|
|
1. General info |
|||
|
Based on |
nginx |
nginx |
|
|
2. Protocols |
|||
|
HTTP/HTTPS |
|
|
|
|
HTTP2 |
|
|
|
|
gRPC |
|
|
|
|
TCP |
Partial |
|
|
|
TCP+TLS |
? |
|
|
|
UDP |
Partial |
|
|
|
Websockets |
|
|
|
|
Proxy Protocol |
|
|
|
|
QUIC/HTTP3 |
Preview |
Preview |
|
|
3. Clients |
|||
|
Rate limiting (L7) |
|
|
|
|
WAF |
|
Partial |
|
|
Timeouts |
|
|
|
|
Safe-list/Block-list |
|
|
|
|
Authentication |
|
|
|
|
Authorisation |
? |
|
|
|
4. Traffic routing |
|||
|
Host |
|
|
|
|
Path |
|
|
|
|
|
|
||
|
Querystring |
|
|
|
|
Method |
|
|
|
|
ClientIP |
|
|
|
|
5. Upstream probes/resiliency |
|||
|
Healthchecks |
? |
|
|
|
Retries |
|
|
|
|
Circuit Breaker |
? |
|
|
|
6.Load balancer strategies |
|||
|
Round robin |
|
|
|
|
Sticky sessions |
|
|
|
|
Least connections |
? |
|
|
|
Ring hash |
|
|
|
|
Custom load balancing |
? |
|
|
|
7. Authentication |
|||
|
Basic auth |
|
|
|
|
External Auth |
|
|
|
|
Client certificate - mTLS |
|
|
|
|
OAuth |
|
|
|
|
OpenID |
? |
|
|
|
JWT |
? |
|
|
|
LDAP |
? |
|
|
|
HMAC |
? |
|
|
|
8. Observability |
|||
|
Logging |
|
|
|
|
Metrics |
|
|
|
|
Tracing |
|
|
|
|
9. Kubernetes Integration |
|||
|
State |
Kubernetes |
Kubernetes |
|
|
CRD |
? |
|
|
|
Scope |
Clusterwide namespace |
namespace |
|
|
Support for the Gateway API |
? |
Preview |
|
|
Integrates with service meshes |
|
|
|
|
10. Traffic shaping |
|||
|
Canary |
|
|
|
|
Session Affinity |
|
|
|
|
Traffic Mirroring |
|
|
|
|
11. Other |
|||
|
Hot reloading |
|
|
|
|
LetsEncrypt Integration |
|
|
|
|
Wildcard certificate support |
|
|
|
|
Configure hot reloading |
Preview |
|
|
|
Service Discovery |
|
|
服務發現在微服務架構中，應用被拆分為很多微服務，無論是微服務故障，還是對應用服務進行擴縮容，都需要盡快的通知到調用方，以免調用失敗。因此，在微服務架構中，服務注冊和發現機制就顯得很重要了，通常這會通過注冊中心來完成。|
Service Discovery |
Ingress NGINX |
Apache APISIX Ingress |
|
Kubernetes |
|
|
|
DNS |
|
|
|
nacos |
|
|
|
exureka |
|
|
|
consul_kv |
|
|
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
name: httpbin
spec:
healthCheck:
passive:
unhealthy:
httpCodes:
- 500
httpFailures: 3
active:
type: http
httpPath: /healthz
healthy:
successes: 3
interval: 2s
httpCodes:
- 200服務熔斷流量高峰時，網關作為流量入口向后端服務發起調用，后端服務有可能會產生調用失敗（超時或者異常），失敗時不能讓請求堆積在網關上，需要快速失敗并返回回去，這就需要在網關上進行熔斷。服務熔斷的功能在 Ingress NGINX 中尚未支持。在 APISIX Ingress 中則可以通過 api-breaker熔斷插件來實現。具體使用配置示例如下：apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: httpbin-route
spec:
http:
- name: rule1
match:
hosts:
- httpbin.org
paths:
- /status/*
backends:
- serviceName: httpbin
servicePort: 80
plugins:
- name: api-breaker
enable: true
config:
break_response_code: 502
unhealthy:
http_statuses:
- 505
failures: 2
healthy:
http_statuses:
- 200
successes: 2插件和鑒權方式目前 Ingress NGINX 主要通過Annotations 和 ConfigMap 等方式進行配置，支持的插件功能比較有限。如果想要使用 JWT、HAMC 等鑒權方式，只能自行開發。而 APISIX Ingress 得益于 APISIX 的豐富功能，原生支持 APISIX 內置的 80+ 插件，能夠覆蓋大部分使用場景，還支持 JWT、HMAC、wolf-rbac 等多種鑒權方式。以下僅展示 APISIX Ingress 使用 HMAC 認證并在路由上的應用示例：apiVersion: apisix.apache.org/v2
kind: ApisixConsumer
metadata:
name: hmac-value
spec:
authParameter:
hmacAuth:
value:
access_key: papa
secret_key: fatpa
algorithm: "hmac-sha256"
clock_skew: 0
---
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: httpbin-route
spec:
http:
- name: rule1
match:
hosts:
- httpbin.org
paths:
- /ip
backends:
- serviceName: httpbin
servicePort: 80
authentication:
enable: true
type: hmacAuthIngress NGINX 和 APISIX Ingress 擴展方式除了以上這些細節對比外，兩者對于額外功能的擴展也有所不同。當 Ingress controller 的基礎功能無法滿足企業用戶的需求時，只能通過擴展的方式進行定制開發。接下來將具體介紹 Ingress NGINX 和 APISIX Ingress 如何進行功能擴展。Ingress NGINX 如何進行功能擴展Ingress NGINX 在擴展方式上比較單一，只能通過嵌入 Lua 程序的方式來擴展功能。我們以 Ingress NGINX 插件開發為例，大概需要以下步驟：1.編寫 Lua 程序 example-plugin2.將插件安裝到 ingress-nginx pod 中的 /etc/nginx/lua/plugins/→ /etc/nginx/lua/plugins/example-plugin3.在 ConfigMap 中啟用 example-plugin 插件，需要在安裝 Ingress NGINX 時引用此 ConfigMap 對象apiVersion: v1
kind: ConfigMap
metadata:
name: ingress-nginx-controller
namespace: ingress-nginx
data:
plugins: "example-plugin"APISIX Ingress 如何進行功能擴展APISIX Ingress 提供了多種擴展方式，企業用戶可以根據自身情況自由選擇或組合，當前支持如下拓展方式：l通過 Lua 進行插件開發：這種方式相對簡單，并且幾乎沒有性能損耗；l通過 plugin-runner 開發：這種模式下支持 Java/Python/Go 等語言進行開發，這可以方便用戶利用一些現有的業務邏輯，并且無需學習新語言；l通過 WASM 進行插件插件：這種模式下，可以使用任何支持構建出 WASM 的語言進行插件開發；此外還可以通過 Serverless 插件來直接編寫 Lua 代碼，快速滿足業務需求。為什么 APISIX Ingress 選擇維護 CRD目前 APISIX Ingress 支持三種聲明式配置：Ingress 、CRD 和 Gateway API。這里主要對比 Ingress 和 CRD，Gateway API 將在后續展開。Ingress 比較適合從 Ingress NGINX 遷移的企業用戶，其轉換成本較低。但缺點也較明顯，比如語義化能力弱、沒有細致規范等，同時也只能通過 Annotations 方式擴展，且 Annotations 無法支撐復雜配置場景。相對的使用 CRD 主要有以下好處：l更契合數據面的設計語義，更加簡單易用；l一些重要配置能夠被復用，而不會存在冗余龐大的單個配置；l功能性和可擴展能力有了巨大提升；l數據面 APISIX 有著活躍的社區，更新和發布版本快，CRD 的方式能夠輕易支持數據面的更多能力；Ingress NGXIN 的痛點：不支持配置熱加載靜態配置帶來的問題Ingress NGINX 主要基于 NGINX 配置文件的方式，盡管使用 NGINX + Lua 來實現功能擴展，但沒有徹底解決靜態配置文件的問題。在路由能力和加載模式上稍顯不足，并且存在一些明顯劣勢。比如添加、修改任何新的規則時，需要重新加載 NGINX 配置。隨著越來越多的路由規則和證書，在觸發變更時，reload 操作將會更耗時，甚至需要幾秒到十幾秒的時間，對線上流量的影響將會非常大的，會導致流量短暫中斷、影響響應延遲、負載均衡質量（每次重新加載 NGINX 都會重置負載均衡狀態）等。觸發 NGINX 重新加載的情況以下這些情況，涵蓋了 Ingress controller 大量的使用場景：l創建新的 Inresss 資源；l將 TLS 部分添加到現有 Ingress；lIngress Annotations 的變化可能影響上游配置（例如 load-balance 注釋不需要重新加載）；l在 Ingress 中添加或刪除 path；lIngress、Service、Secret 資源被刪除；lSecret 發生更新；在上述場景下，具有頻繁部署應用程序的集群環境中，會不斷觸發 Ingress、Secret 等資源的操作（創建、更新、刪除等），導致 NGINX 重新加載次數劇增，給生產環境帶來了極大的影響。小結Ingress NGINX 的架構決定了它必須生成 NGINX 配置然后通過 reload 方式完成配置更新，架構不調整是無法解決這些已知問題。比如路由的實現，APISIX Ingress 則不再依賴 NGINX 配置改為了純內存結構，通過熱更新方式實現動態路由，不再需要重啟 NGINX。云原生新一代網關規范 Gateway APIGateway API 優勢Gateway API 相比 Ingress 的功能性更強，旨在通過由許多供應商實現并具有廣泛行業支持的富有表現力、可擴展和面向角色的接口來發展 Kubernetes 服務網絡。當下 Gateway API 具有如下的優勢：l面向角色：Gateway 是由一組 API 資源組成的。不同的 API 資源代表了使用與配置 Kubernetes 網絡資源的不同角色；l表現力強：Gateway API 的核心功能就包含諸如基于頭的匹配、流量加權以及其他在 Ingress 中只能通過各實現者自定義的非標準化 Annotations 等方式實現的功能；l可擴展：Gateway API 允許不同資源在不同層級一同使用。這使得能夠對 API 結構進行更精細化的控制。支持情況Gateway API 作為一種擴展 Kubernetes 服務網絡的標準，其 Gateway 資源能夠實現作為 Kubernetes API 來管理網關的生命周期，功能十分強大。目前許多 Ingress controller 都在積極支持它，包括 Istio、Kong、Traefik 等。在目前 Gateway API 實現情況中，很遺憾的是，Ingress NGXIN 尚未計劃支持 Gateway API 。而 APISIX Ingress 已經支持了 Gateway API 的大部分特性：包括 HTTPRoute、TCPRoute、TLSRoute、UDPRoute 等。總結經過 APISIX Ingress 與 Ingress NGINX 的完整對比，我們可以看到兩者基礎功能差異不大，也都具備擴展能力。但在微服務的架構中，APISIX Ingress 對服務治理和服務發現的支持更具優勢。總體來看，兩款開源軟件均非常優秀，Ingress NGINX 主要特點是簡單、易接入，但缺點也十分明顯；APISIX Ingress 作為后來者解決了 NGINX 不支持熱加載的痛點，在擴展能力和功能上相比 Ingress NGINX 也具有很大的優勢。從項目發展角度而言，支持 Gateway API 和 CRD 能夠擴展和豐富 Ingress controller 基礎能力。如果讀者正在進行 Ingress controller 選型，傾向于功能豐富和更強的擴展能力，推薦使用 APISIX Ingress 。如果只是剛接觸 Ingress controller，沒有更多的功能需求，Ingress NGINX 也是一個比較好的選擇。審核編輯 ：李倩
-
開源軟件
+關注
關注
0文章
210瀏覽量
15900 -
網關
+關注
關注
9文章
4451瀏覽量
51077
原文標題：APISIX Ingress VS Ingress NGINX，詳細對比讓你一目了然
文章出處：【微信號：OSC開源社區，微信公眾號：OSC開源社區】歡迎添加關注！文章轉載請注明出處。
發布評論請先 登錄
相關推薦
nginx+lua+redis實現灰度發布
Nginx日常運維方法Linux版
「服務器」Nginx Proxy Manager申請cloudflare泛域名
確保網站無縫運行：Keepalived高可用與Nginx集成實戰
nginx隱藏版本號與WEB服務器信息
nginx負載均衡配置介紹
nginx中的正則表達式和location路徑匹配指南
Jtti：美國VPS開啟nginx狀態監控，查看web服務器的并發連接數
nginx重啟命令linux步驟是什么？
nginx重啟命令linux步驟是什么？
Apache服務器和Nginx服務器
如何構建APISIX基于DeepFlow的統一可觀測性能力呢？
騰訊云和華為云的ingress路徑匹配規則把我繞暈了
工商網監
評論