怡红院亚洲,一级特一级特色生活片,亚欧一区

Kubernetes 中的服務(wù)可以通過(guò) Ingress 暴露出來(lái)，流量路由由 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ì)下的開(kāi)源項(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
	Headers
	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

功能差異通過(guò)下圖，可以粗略看到 APISIX Ingress 內(nèi)置的功能和特性相比 Ingress NGINX 更加豐富，其中包括服務(wù)發(fā)現(xiàn)、協(xié)議支持、認(rèn)證鑒權(quán)等等。

服務(wù)發(fā)現(xiàn)在微服務(wù)架構(gòu)中，應(yīng)用被拆分為很多微服務(wù)，無(wú)論是微服務(wù)故障，還是對(duì)應(yīng)用服務(wù)進(jìn)行擴(kuò)縮容，都需要盡快的通知到調(diào)用方，以免調(diào)用失敗。因此，在微服務(wù)架構(gòu)中，服務(wù)注冊(cè)和發(fā)現(xiàn)機(jī)制就顯得很重要了，通常這會(huì)通過(guò)注冊(cè)中心來(lái)完成。

Service Discovery	Ingress NGINX	Apache APISIX Ingress
Kubernetes
DNS
nacos
exureka
consul_kv

協(xié)議支持兩者都對(duì) HTTP/HTTPS 協(xié)議提供完整支持，APISIX Ingress 在協(xié)議支持上更豐富一些，能夠的使用 TLS 來(lái)加密 TCP 流量，還支持 MQTT，Dubbo、Kafka 等協(xié)議進(jìn)行代理。服務(wù)治理能力健康檢查在后端節(jié)點(diǎn)故障或者遷移時(shí)，不可避免會(huì)出現(xiàn)節(jié)點(diǎn)不可用的情況。如果大量請(qǐng)求訪問(wèn)到了這些不可用的節(jié)點(diǎn)時(shí)，將會(huì)造成流量損失，導(dǎo)致業(yè)務(wù)中斷。因此，需要對(duì)節(jié)點(diǎn)進(jìn)行健康檢查，通過(guò)探針的形式探測(cè)后端節(jié)點(diǎn)的可用性，將請(qǐng)求代理到健康的節(jié)點(diǎn)，從而減少或避免流量損失。健康檢查的能力在 Ingress NGINX 中尚未支持，而 APISIX Ingress 提供了該能力，其中包括：l主動(dòng)健康檢查：確保后端服務(wù)中的 Pod 處于可用的狀態(tài)。在應(yīng)用服務(wù)進(jìn)行滾動(dòng)更新時(shí)，會(huì)牽扯大量的節(jié)點(diǎn)進(jìn)行更新，不健康的節(jié)點(diǎn)將會(huì)被負(fù)載均衡器忽略，開(kāi)啟健康檢查能夠有效的挑選出可用的 Pod，避免流量損失。l被動(dòng)健康檢查：被動(dòng)的方式無(wú)需發(fā)起額外的探針，每個(gè)請(qǐng)求就是探針，若一個(gè)健康節(jié)點(diǎn)連續(xù) N 個(gè)請(qǐng)求都被判定為失敗（取決于如何配置），則該節(jié)點(diǎn)將被標(biāo)記為不健康。由于無(wú)法提前感知節(jié)點(diǎn)的狀態(tài)，可能會(huì)有一定量的失敗請(qǐng)求，在滾動(dòng)更新時(shí)這種情況會(huì)相對(duì)常見(jiàn)，可以通過(guò)服務(wù)降級(jí)來(lái)避免失敗的請(qǐng)求量。如下是 APISIX Ingress 為 httpbin 服務(wù)配置健康檢查示例：

apiVersion: apisix.apache.org/v2

kind: ApisixUpstream

metadata:

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 中則可以通過(guò) api-breaker熔斷插件來(lái)實(shí)現(xiàn)。具體使用配置示例如下：

apiVersion: apisix.apache.org/v2

kind: ApisixRoute

metadata:

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 主要通過(guò)Annotations 和 ConfigMap 等方式進(jìn)行配置，支持的插件功能比較有限。如果想要使用 JWT、HAMC 等鑒權(quán)方式，只能自行開(kāi)發(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:

spec:

authParameter:

hmacAuth:

value:

access_key: papa

secret_key: fatpa

algorithm: "hmac-sha256"

clock_skew: 0

---

apiVersion: apisix.apache.org/v2

kind: ApisixRoute

metadata:

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ǔ)功能無(wú)法滿足企業(yè)用戶的需求時(shí)，只能通過(guò)擴(kuò)展的方式進(jìn)行定制開(kāi)發(fā)。接下來(lái)將具體介紹 Ingress NGINX 和 APISIX Ingress 如何進(jìn)行功能擴(kuò)展。Ingress NGINX 如何進(jìn)行功能擴(kuò)展Ingress NGINX 在擴(kuò)展方式上比較單一，只能通過(guò)嵌入 Lua 程序的方式來(lái)擴(kuò)展功能。我們以 Ingress NGINX 插件開(kāi)發(fā)為例，大概需要以下步驟：1.編寫(xiě) 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:

namespace: ingress-nginx

data:

plugins: "example-plugin"APISIX Ingress 如何進(jìn)行功能擴(kuò)展APISIX Ingress 提供了多種擴(kuò)展方式，企業(yè)用戶可以根據(jù)自身情況自由選擇或組合，當(dāng)前支持如下拓展方式：l通過(guò) Lua 進(jìn)行插件開(kāi)發(fā)：這種方式相對(duì)簡(jiǎn)單，并且?guī)缀鯖](méi)有性能損耗；l通過(guò) plugin-runner 開(kāi)發(fā)：這種模式下支持 Java/Python/Go 等語(yǔ)言進(jìn)行開(kāi)發(fā)，這可以方便用戶利用一些現(xiàn)有的業(yè)務(wù)邏輯，并且無(wú)需學(xué)習(xí)新語(yǔ)言；l通過(guò) WASM 進(jìn)行插件插件：這種模式下，可以使用任何支持構(gòu)建出 WASM 的語(yǔ)言進(jìn)行插件開(kāi)發(fā)；此外還可以通過(guò) Serverless 插件來(lái)直接編寫(xiě) Lua 代碼，快速滿足業(yè)務(wù)需求。為什么 APISIX Ingress 選擇維護(hù) CRD目前 APISIX Ingress 支持三種聲明式配置：Ingress 、CRD 和 Gateway API。這里主要對(duì)比 Ingress 和 CRD，Gateway API 將在后續(xù)展開(kāi)。Ingress 比較適合從 Ingress NGINX 遷移的企業(yè)用戶，其轉(zhuǎn)換成本較低。但缺點(diǎn)也較明顯，比如語(yǔ)義化能力弱、沒(méi)有細(xì)致規(guī)范等，同時(shí)也只能通過(guò) Annotations 方式擴(kuò)展，且 Annotations 無(wú)法支撐復(fù)雜配置場(chǎng)景。相對(duì)的使用 CRD 主要有以下好處：l更契合數(shù)據(jù)面的設(shè)計(jì)語(yǔ)義，更加簡(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)配置帶來(lái)的問(wèn)題Ingress NGINX 主要基于 NGINX 配置文件的方式，盡管使用 NGINX + Lua 來(lái)實(shí)現(xiàn)功能擴(kuò)展，但沒(méi)有徹底解決靜態(tài)配置文件的問(wèn)題。在路由能力和加載模式上稍顯不足，并且存在一些明顯劣勢(shì)。比如添加、修改任何新的規(guī)則時(shí)，需要重新加載 NGINX 配置。隨著越來(lái)越多的路由規(guī)則和證書(shū)，在觸發(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)境帶來(lái)了極大的影響。小結(jié)Ingress NGINX 的架構(gòu)決定了它必須生成 NGINX 配置然后通過(guò) reload 方式完成配置更新，架構(gòu)不調(diào)整是無(wú)法解決這些已知問(wèn)題。比如路由的實(shí)現(xiàn)，APISIX Ingress 則不再依賴 NGINX 配置改為了純內(nèi)存結(jié)構(gòu)，通過(guò)熱更新方式實(shí)現(xiàn)動(dòng)態(tài)路由，不再需要重啟 NGINX。云原生新一代網(wǎng)關(guān)規(guī)范 Gateway APIGateway API 優(yōu)勢(shì)Gateway API 相比 Ingress 的功能性更強(qiáng)，旨在通過(guò)由許多供應(yīng)商實(shí)現(xiàn)并具有廣泛行業(yè)支持的富有表現(xiàn)力、可擴(kuò)展和面向角色的接口來(lái)發(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 中只能通過(guò)各實(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 來(lái)管理網(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)過(guò) APISIX Ingress 與 Ingress NGINX 的完整對(duì)比，我們可以看到兩者基礎(chǔ)功能差異不大，也都具備擴(kuò)展能力。但在微服務(wù)的架構(gòu)中，APISIX Ingress 對(duì)服務(wù)治理和服務(wù)發(fā)現(xiàn)的支持更具優(yōu)勢(shì)。總體來(lái)看，兩款開(kāi)源軟件均非常優(yōu)秀，Ingress NGINX 主要特點(diǎn)是簡(jiǎn)單、易接入，但缺點(diǎn)也十分明顯；APISIX Ingress 作為后來(lái)者解決了 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，沒(méi)有更多的功能需求，Ingress NGINX 也是一個(gè)比較好的選擇。

審核編輯：李倩

聲明：本文內(nèi)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題，請(qǐng)聯(lián)系本站處理。舉報(bào)投訴