亚洲寂寞少妇,九九九午夜福利电影,女子裸体喷出奶水gif动态图

Kubernetes 中的服務(wù)可以通過 Ingress 暴露出來，流量路由由 Ingress 資源上定義的規(guī)則控制，通常需要 Ingress controller 負責(zé)實現(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é)議支持、鑒權(quán)方式、上游探針/策略、負載均衡策略、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

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

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

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

協(xié)議支持兩者都對 HTTP/HTTPS 協(xié)議提供完整支持，APISIX Ingress 在協(xié)議支持上更豐富一些，能夠的使用 TLS 來加密 TCP 流量，還支持 MQTT，Dubbo、Kafka 等協(xié)議進行代理。服務(wù)治理能力健康檢查在后端節(jié)點故障或者遷移時，不可避免會出現(xiàn)節(jié)點不可用的情況。如果大量請求訪問到了這些不可用的節(jié)點時，將會造成流量損失，導(dǎo)致業(yè)務(wù)中斷。因此，需要對節(jié)點進行健康檢查，通過探針的形式探測后端節(jié)點的可用性，將請求代理到健康的節(jié)點，從而減少或避免流量損失。健康檢查的能力在 Ingress NGINX 中尚未支持，而 APISIX Ingress 提供了該能力，其中包括：l主動健康檢查：確保后端服務(wù)中的 Pod 處于可用的狀態(tài)。在應(yīng)用服務(wù)進行滾動更新時，會牽扯大量的節(jié)點進行更新，不健康的節(jié)點將會被負載均衡器忽略，開啟健康檢查能夠有效的挑選出可用的 Pod，避免流量損失。l被動健康檢查：被動的方式無需發(fā)起額外的探針，每個請求就是探針，若一個健康節(jié)點連續(xù) N 個請求都被判定為失敗（取決于如何配置），則該節(jié)點將被標(biāo)記為不健康。由于無法提前感知節(jié)點的狀態(tài)，可能會有一定量的失敗請求，在滾動更新時這種情況會相對常見，可以通過服務(wù)降級來避免失敗的請求量。如下是 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ù)熔斷流量高峰時，網(wǎng)關(guān)作為流量入口向后端服務(wù)發(fā)起調(diào)用，后端服務(wù)有可能會產(chǎn)生調(diào)用失?。ǔ瑫r或者異常），失敗時不能讓請求堆積在網(wǎng)關(guān)上，需要快速失敗并返回回去，這就需要在網(wǎng)關(guān)上進行熔斷。服務(wù)熔斷的功能在 Ingress NGINX 中尚未支持。在 APISIX Ingress 中則可以通過 api-breaker熔斷插件來實現(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 主要通過Annotations 和 ConfigMap 等方式進行配置，支持的插件功能比較有限。如果想要使用 JWT、HAMC 等鑒權(quán)方式，只能自行開發(fā)。而 APISIX Ingress 得益于 APISIX 的豐富功能，原生支持 APISIX 內(nèi)置的 80+ 插件，能夠覆蓋大部分使用場景，還支持 JWT、HMAC、wolf-rbac 等多種鑒權(quán)方式。以下僅展示 APISIX Ingress 使用 HMAC 認證并在路由上的應(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 擴展方式除了以上這些細節(jié)對比外，兩者對于額外功能的擴展也有所不同。當(dāng) Ingress controller 的基礎(chǔ)功能無法滿足企業(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:

namespace: ingress-nginx

data:

plugins: "example-plugin"APISIX Ingress 如何進行功能擴展APISIX Ingress 提供了多種擴展方式，企業(yè)用戶可以根據(jù)自身情況自由選擇或組合，當(dāng)前支持如下拓展方式：l通過 Lua 進行插件開發(fā)：這種方式相對簡單，并且?guī)缀鯖]有性能損耗；l通過 plugin-runner 開發(fā)：這種模式下支持 Java/Python/Go 等語言進行開發(fā)，這可以方便用戶利用一些現(xiàn)有的業(yè)務(wù)邏輯，并且無需學(xué)習(xí)新語言；l通過 WASM 進行插件插件：這種模式下，可以使用任何支持構(gòu)建出 WASM 的語言進行插件開發(fā)；此外還可以通過 Serverless 插件來直接編寫 Lua 代碼，快速滿足業(yè)務(wù)需求。為什么 APISIX Ingress 選擇維護 CRD目前 APISIX Ingress 支持三種聲明式配置：Ingress 、CRD 和 Gateway API。這里主要對比 Ingress 和 CRD，Gateway API 將在后續(xù)展開。Ingress 比較適合從 Ingress NGINX 遷移的企業(yè)用戶，其轉(zhuǎn)換成本較低。但缺點也較明顯，比如語義化能力弱、沒有細致規(guī)范等，同時也只能通過 Annotations 方式擴展，且 Annotations 無法支撐復(fù)雜配置場景。相對的使用 CRD 主要有以下好處：l更契合數(shù)據(jù)面的設(shè)計語義，更加簡單易用；l一些重要配置能夠被復(fù)用，而不會存在冗余龐大的單個配置；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 操作將會更耗時，甚至需要幾秒到十幾秒的時間，對線上流量的影響將會非常大的，會導(dǎo)致流量短暫中斷、影響響應(yīng)延遲、負載均衡質(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ā)生更新；在上述場景下，具有頻繁部署應(yīng)用程序的集群環(huán)境中，會不斷觸發(fā) Ingress、Secret 等資源的操作（創(chuàng)建、更新、刪除等），導(dǎo)致 NGINX 重新加載次數(shù)劇增，給生產(chǎn)環(huán)境帶來了極大的影響。小結(jié)Ingress NGINX 的架構(gòu)決定了它必須生成 NGINX 配置然后通過 reload 方式完成配置更新，架構(gòu)不調(diào)整是無法解決這些已知問題。比如路由的實現(xiàn)，APISIX Ingress 則不再依賴 NGINX 配置改為了純內(nèi)存結(jié)構(gòu)，通過熱更新方式實現(xiàn)動態(tài)路由，不再需要重啟 NGINX。云原生新一代網(wǎng)關(guān)規(guī)范 Gateway APIGateway API 優(yōu)勢Gateway API 相比 Ingress 的功能性更強，旨在通過由許多供應(yīng)商實現(xiàn)并具有廣泛行業(yè)支持的富有表現(xiàn)力、可擴展和面向角色的接口來發(fā)展 Kubernetes 服務(wù)網(wǎng)絡(luò)。當(dāng)下 Gateway API 具有如下的優(yōu)勢：l面向角色：Gateway 是由一組 API 資源組成的。不同的 API 資源代表了使用與配置 Kubernetes 網(wǎng)絡(luò)資源的不同角色；l表現(xiàn)力強：Gateway API 的核心功能就包含諸如基于頭的匹配、流量加權(quán)以及其他在 Ingress 中只能通過各實現(xiàn)者自定義的非標(biāo)準(zhǔn)化 Annotations 等方式實現(xiàn)的功能；l可擴展：Gateway API 允許不同資源在不同層級一同使用。這使得能夠?qū)?API 結(jié)構(gòu)進行更精細化的控制。支持情況Gateway API 作為一種擴展 Kubernetes 服務(wù)網(wǎng)絡(luò)的標(biāo)準(zhǔn)，其 Gateway 資源能夠?qū)崿F(xiàn)作為 Kubernetes API 來管理網(wǎng)關(guān)的生命周期，功能十分強大。目前許多 Ingress controller 都在積極支持它，包括 Istio、Kong、Traefik 等。在目前 Gateway API 實現(xiàn)情況中，很遺憾的是，Ingress NGXIN 尚未計劃支持 Gateway API 。而 APISIX Ingress 已經(jīng)支持了 Gateway API 的大部分特性：包括 HTTPRoute、TCPRoute、TLSRoute、UDPRoute 等。總結(jié)經(jīng)過 APISIX Ingress 與 Ingress NGINX 的完整對比，我們可以看到兩者基礎(chǔ)功能差異不大，也都具備擴展能力。但在微服務(wù)的架構(gòu)中，APISIX Ingress 對服務(wù)治理和服務(wù)發(fā)現(xiàn)的支持更具優(yōu)勢。總體來看，兩款開源軟件均非常優(yōu)秀，Ingress NGINX 主要特點是簡單、易接入，但缺點也十分明顯；APISIX Ingress 作為后來者解決了 NGINX 不支持熱加載的痛點，在擴展能力和功能上相比 Ingress NGINX 也具有很大的優(yōu)勢。從項目發(fā)展角度而言，支持 Gateway API 和 CRD 能夠擴展和豐富 Ingress controller 基礎(chǔ)能力。如果讀者正在進行 Ingress controller 選型，傾向于功能豐富和更強的擴展能力，推薦使用 APISIX Ingress 。如果只是剛接觸 Ingress controller，沒有更多的功能需求，Ingress NGINX 也是一個比較好的選擇。

審核編輯：李倩

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