距離上一個版本 v1.5 釋出,已經過了 3 個月,我們很高興地宣佈 Apache APISIX Ingress v1.6 正式釋出!
在該版本中,共有 29 位貢獻者 參與程式碼提交,其中 17 位是新晉貢獻者 ,感謝大家的支援和參與!
本次釋出的 Apache APISIX Ingress v1.6 版本帶來了眾多新特性,主要集中在對 Gateway API 的支援,同時也在擴充套件 APISIX Ingress 的使用場景和易用性方面的提升。以下是一些重點特性的介紹。
擴充套件對 Gateway API 的支援
Gateway API 是 Kubernetes 中下一代的 Ingress 規範,致力於提供富有表現力,可擴充套件和麵向角色的介面來發展 Kubernetes 的網路,各個 Ingress controller 專案都在積極推進對該規範的支援。Apache APISIX Ingress 專案自 2021 年開始就在積極地緊跟上游社群的發展,並積極推進 Gateway API 在 APISIX Ingress 專案中的實現。
當前,Apache APISIX Ingress 專案中透過 Gateway API 進行配置的特性尚處於 beta 階段,歡迎大家在測試環境中積極進行測試,並提供反饋,我們將持續的對此特性進行最佳化和改進,儘早完成此特性的 GA。
在 APISIX Ingress v1.6 版本中,我們新增了對 Gateway API 中的 TCPRoute
和 UDPRoute
這兩種資源的支援。同時,擴充套件了對 HTTPRoute
資源中 Filters
的支援,這樣使用者在使用 HTTPRoute
資源時,就可以在該資源中應用一些重定向、Header 改寫等能力了。
例如可以使用如下配置:
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
name: http-route
spec:
hostnames: ["httpbin.org"]
rules:
- matches:
- path:
type: PathPrefix
value: /headers
filters:
- type: RequestHeaderModifier
requestHeaderModifier:
add:
- name: X-Api-Version
value: v1
- name: X-api-key
value: api-value
set:
- name: X-Auth
value: filter
remove:
- Remove-header
backendRefs:
- name: httpbin
port: 80
透過使用此配置,客戶端在對 httpbin.org 進行請求時,將會新增 "X-Api-Version": "v1"
和 "X-Api-Key": "api-value"
的請求頭,並將 "X-Auth"
請求頭的值設定為 filter
,同時將移除 "Remove-Header"
這個請求頭。
支援與服務發現元件的整合
Kubernetes 中預設是使用基於 DNS 的服務發現機制,但是應用在遷移和改造的過程中,並非所有的業務都會選擇改造成基於 DNS 的這種服務發現機制,仍然有大量微服務架構的應用會繼續使用原有的服務註冊發現元件,比如 Consul,Nacos,Eureka 等。
為了將 APISIX Ingress 打造成一款更加好用的 Ingress controller,我們在 v1.6 版本中新增了與服務發現元件整合的能力,使用者可以將註冊在 Consul/Nacos/Eureka/DNS 中的服務,透過 APISIX Ingress 暴露出來,無論是南北向還是東西向流量的場景均可使用。
例如透過如下配置,宣告要代理的服務是透過 Nacos 註冊的名為 httpbin
的服務。
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
name: httpbin-upstream
spec:
discovery:
type: nacos
serviceName: httpbin
然後在 ApisixRoute 資源中對其進行引用即可:
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: httpbin-route
spec:
http:
- name: rule1
match:
hosts:
- local.httpbin.org
paths:
- /*
upstreams:
- name: httpbin-upstream
這樣客戶端在訪問時,就會被 APISIX 代理到 Nacos 中註冊的服務了。更多內容可參考文件。
支援代理外部服務
與上述功能類似,Apache APISIX Ingress v1.6 版本中還新增了對外部服務代理的能力。主要是為了便於使用者對一些沒有部署在 Kubernetes 中的外部服務進行代理。
最典型的場景比如說訊息推送。業務為了保障服務的高可用,通常會選擇多家供應商提供服務,但供應商也可能會出現一些異常的情況。這種時候就可以透過這個功能,在多個供應商提供的服務中進行動態排程了。
比如透過如下配置設定兩個供應商的域名作為後端:
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
name: notify-api
spec:
externalNodes:
- type: Domain
name: foo.com
- type: Domain
name: bar.com
healthCheck:
passive:
unhealthy:
httpCodes:
- 500
- 502
- 503
- 504
httpFailures: 3
timeout: 5s
active:
type: http
httpPath: /healthz
timeout: 5s
healthy:
successes: 3
interval: 2s
httpCodes:
- 200
然後在 ApisixRoute 資源中進行引用:
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: notify-route
spec:
http:
- name: rule1
match:
hosts:
- local.notify.app
paths:
- /*
upstreams:
- name: notify-api
這樣,如果某個供應商的服務出現異常,則會根據健康檢查的規則自動地代理到備用的服務上,從而保障業務的可用性。
同樣的,如果業務中存在需要代理 ExternalName Service 的場景也可以使用這種方式進行代理。更多內容可參考文件。
其他
除了上述的這些功能外,在此版本中還新增了很多其他功能,包括:
- 支援 Ingress 資源中代理不同 namespace 中的後端服務;
- 原生的 MQTT 協議的代理支援;
- 允許為 4 層代理新增外掛支援;
- 允許在 ApisixRoute 資源中使用 vars 進行條件匹配;
- 日誌輪轉支援;
更多詳細的變更請檢視 Release Note:https://github.com/apache/api...