Apache APISIX Ingress 1.6 正式釋出!

Apache_APISIX發表於2023-01-10

距離上一個版本 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 專案中的實現。

Gateway API

當前,Apache APISIX Ingress 專案中透過 Gateway API 進行配置的特性尚處於 beta 階段,歡迎大家在測試環境中積極進行測試,並提供反饋,我們將持續的對此特性進行最佳化和改進,儘早完成此特性的 GA。

在 APISIX Ingress v1.6 版本中,我們新增了對 Gateway API 中的 TCPRouteUDPRoute 這兩種資源的支援。同時,擴充套件了對 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...

相關文章