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