APISIX Ingress VS Ingress NGINX詳細對比
Kubernetes 中的服務可以通過 Ingress 暴露出來，流量路由由 Ingress 資源上定義的規(guī)則控制，通常需要 Ingress controller 負責實現(xiàn)。本文將會對比兩個比較流行的 Ingress controller 實現(xiàn)，希望能對讀者進行 Ingress controller 選型中有所幫助。
Ingress NGINX 是 Kubernetes 社區(qū)實現(xiàn)的 Ingress controller，在社區(qū)中被廣泛使用。Apache APISIX Ingress 則是 Apache 軟件基金會下的開源項目，使用 APISIX 作為數(shù)據(jù)面的 Kubernetes Ingress controller。Ingress NGINX vs APISIX Ingress功能對比下列表格中，對比了 Ingress NGINX 和 APISIX Ingress 基本功能，包括協(xié)議支持、鑒權方式、上游探針/策略、負載均衡策略、Kubenertes 集成等。以下表格數(shù)據(jù)取自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 |
|
|
服務發(fā)現(xiàn)在微服務架構中，應用被拆分為很多微服務，無論是微服務故障，還是對應用服務進行擴縮容，都需要盡快的通知到調(diào)用方，以免調(diào)用失敗。因此，在微服務架構中，服務注冊和發(fā)現(xiàn)機制就顯得很重要了，通常這會通過注冊中心來完成。|
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服務熔斷流量高峰時，網(wǎng)關作為流量入口向后端服務發(fā)起調(diào)用，后端服務有可能會產(chǎn)生調(diào)用失?。ǔ瑫r或者異常），失敗時不能讓請求堆積在網(wǎng)關上，需要快速失敗并返回回去，這就需要在網(wǎng)關上進行熔斷。服務熔斷的功能在 Ingress NGINX 中尚未支持。在 APISIX Ingress 中則可以通過 api-breaker熔斷插件來實現(xiàn)。具體使用配置示例如下：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 等鑒權方式，只能自行開發(fā)。而 APISIX Ingress 得益于 APISIX 的豐富功能，原生支持 APISIX 內(nèi)置的 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 擴展方式除了以上這些細節(jié)對比外，兩者對于額外功能的擴展也有所不同。當 Ingress controller 的基礎功能無法滿足企業(yè)用戶的需求時，只能通過擴展的方式進行定制開發(fā)。接下來將具體介紹 Ingress NGINX 和 APISIX Ingress 如何進行功能擴展。Ingress NGINX 如何進行功能擴展Ingress NGINX 在擴展方式上比較單一，只能通過嵌入 Lua 程序的方式來擴展功能。我們以 Ingress NGINX 插件開發(fā)為例，大概需要以下步驟：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 提供了多種擴展方式，企業(yè)用戶可以根據(jù)自身情況自由選擇或組合，當前支持如下拓展方式：l通過 Lua 進行插件開發(fā)：這種方式相對簡單，并且?guī)缀鯖]有性能損耗；l通過 plugin-runner 開發(fā)：這種模式下支持 Java/Python/Go 等語言進行開發(fā)，這可以方便用戶利用一些現(xiàn)有的業(yè)務邏輯，并且無需學習新語言；l通過 WASM 進行插件插件：這種模式下，可以使用任何支持構建出 WASM 的語言進行插件開發(fā)；此外還可以通過 Serverless 插件來直接編寫 Lua 代碼，快速滿足業(yè)務需求。為什么 APISIX Ingress 選擇維護 CRD目前 APISIX Ingress 支持三種聲明式配置：Ingress 、CRD 和 Gateway API。這里主要對比 Ingress 和 CRD，Gateway API 將在后續(xù)展開。Ingress 比較適合從 Ingress NGINX 遷移的企業(yè)用戶，其轉換成本較低。但缺點也較明顯，比如語義化能力弱、沒有細致規(guī)范等，同時也只能通過 Annotations 方式擴展，且 Annotations 無法支撐復雜配置場景。相對的使用 CRD 主要有以下好處：l更契合數(shù)據(jù)面的設計語義，更加簡單易用；l一些重要配置能夠被復用，而不會存在冗余龐大的單個配置；l功能性和可擴展能力有了巨大提升；l數(shù)據(jù)面 APISIX 有著活躍的社區(qū)，更新和發(fā)布版本快，CRD 的方式能夠輕易支持數(shù)據(jù)面的更多能力；Ingress NGXIN 的痛點：不支持配置熱加載靜態(tài)配置帶來的問題Ingress NGINX 主要基于 NGINX 配置文件的方式，盡管使用 NGINX + Lua 來實現(xiàn)功能擴展，但沒有徹底解決靜態(tài)配置文件的問題。在路由能力和加載模式上稍顯不足，并且存在一些明顯劣勢。比如添加、修改任何新的規(guī)則時，需要重新加載 NGINX 配置。隨著越來越多的路由規(guī)則和證書，在觸發(fā)變更時，reload 操作將會更耗時，甚至需要幾秒到十幾秒的時間，對線上流量的影響將會非常大的，會導致流量短暫中斷、影響響應延遲、負載均衡質(zhì)量（每次重新加載 NGINX 都會重置負載均衡狀態(tài)）等。觸發(fā) NGINX 重新加載的情況以下這些情況，涵蓋了 Ingress controller 大量的使用場景：l創(chuàng)建新的 Inresss 資源；l將 TLS 部分添加到現(xiàn)有 Ingress；lIngress Annotations 的變化可能影響上游配置（例如 load-balance 注釋不需要重新加載）；l在 Ingress 中添加或刪除 path；lIngress、Service、Secret 資源被刪除；lSecret 發(fā)生更新；在上述場景下，具有頻繁部署應用程序的集群環(huán)境中，會不斷觸發(fā) Ingress、Secret 等資源的操作（創(chuàng)建、更新、刪除等），導致 NGINX 重新加載次數(shù)劇增，給生產(chǎn)環(huán)境帶來了極大的影響。小結Ingress NGINX 的架構決定了它必須生成 NGINX 配置然后通過 reload 方式完成配置更新，架構不調(diào)整是無法解決這些已知問題。比如路由的實現(xiàn)，APISIX Ingress 則不再依賴 NGINX 配置改為了純內(nèi)存結構，通過熱更新方式實現(xiàn)動態(tài)路由，不再需要重啟 NGINX。云原生新一代網(wǎng)關規(guī)范 Gateway APIGateway API 優(yōu)勢Gateway API 相比 Ingress 的功能性更強，旨在通過由許多供應商實現(xiàn)并具有廣泛行業(yè)支持的富有表現(xiàn)力、可擴展和面向角色的接口來發(fā)展 Kubernetes 服務網(wǎng)絡。當下 Gateway API 具有如下的優(yōu)勢：l面向角色：Gateway 是由一組 API 資源組成的。不同的 API 資源代表了使用與配置 Kubernetes 網(wǎng)絡資源的不同角色；l表現(xiàn)力強：Gateway API 的核心功能就包含諸如基于頭的匹配、流量加權以及其他在 Ingress 中只能通過各實現(xiàn)者自定義的非標準化 Annotations 等方式實現(xiàn)的功能；l可擴展：Gateway API 允許不同資源在不同層級一同使用。這使得能夠對 API 結構進行更精細化的控制。支持情況Gateway API 作為一種擴展 Kubernetes 服務網(wǎng)絡的標準，其 Gateway 資源能夠實現(xiàn)作為 Kubernetes API 來管理網(wǎng)關的生命周期，功能十分強大。目前許多 Ingress controller 都在積極支持它，包括 Istio、Kong、Traefik 等。在目前 Gateway API 實現(xiàn)情況中，很遺憾的是，Ingress NGXIN 尚未計劃支持 Gateway API 。而 APISIX Ingress 已經(jīng)支持了 Gateway API 的大部分特性：包括 HTTPRoute、TCPRoute、TLSRoute、UDPRoute 等。總結經(jīng)過 APISIX Ingress 與 Ingress NGINX 的完整對比，我們可以看到兩者基礎功能差異不大，也都具備擴展能力。但在微服務的架構中，APISIX Ingress 對服務治理和服務發(fā)現(xiàn)的支持更具優(yōu)勢。總體來看，兩款開源軟件均非常優(yōu)秀，Ingress NGINX 主要特點是簡單、易接入，但缺點也十分明顯；APISIX Ingress 作為后來者解決了 NGINX 不支持熱加載的痛點，在擴展能力和功能上相比 Ingress NGINX 也具有很大的優(yōu)勢。從項目發(fā)展角度而言，支持 Gateway API 和 CRD 能夠擴展和豐富 Ingress controller 基礎能力。如果讀者正在進行 Ingress controller 選型，傾向于功能豐富和更強的擴展能力，推薦使用 APISIX Ingress 。如果只是剛接觸 Ingress controller，沒有更多的功能需求，Ingress NGINX 也是一個比較好的選擇。審核編輯 ：李倩
-
開源軟件
+關注
關注
0文章
216瀏覽量
16644 -
網(wǎng)關
+關注
關注
9文章
6959瀏覽量
56593
原文標題：APISIX Ingress VS Ingress NGINX，詳細對比讓你一目了然
文章出處：【微信號：OSC開源社區(qū)，微信公眾號：OSC開源社區(qū)】歡迎添加關注！文章轉載請注明出處。
發(fā)布評論請先 登錄
Nginx的限流機制深度解析
Kubernetes Ingress Controller對比解析
Nginx中Master與Worker進程的工作機制
企業(yè)級應用模板化部署與Helm包管理實戰(zhàn)
K8s部署vLLM推理服務詳細步驟
Nginx常見故障排查手冊
Nginx高性能配置詳細步驟
Ingress Nginx性能調(diào)優(yōu)配置方案
Nginx高并發(fā)優(yōu)化方案
Nginx在企業(yè)環(huán)境中的調(diào)優(yōu)策略
Nginx配置終極指南
Nginx性能優(yōu)化終極指南
評論