Higress 開源一週年：新版本，新標準，新工具，新徵程

作者：Higress 團隊

歷程回顧

Higress 開源一年時間，一共發佈了 18 個 release 版本，收穫了 40 多位社區貢獻者和 1800+ star，上圖是這一年過來達成的一些關鍵的里程碑。

前面半年通過集成開源生態，打磨開源版本穩定性，並在發佈 1.0 GA 版本後，社區又馬不停蹄發佈了 1.1 和 1.2 兩個重要版本，實現了非 K8s 部署，Knative 適配等核心能力。

Higress 1.3 版本已經正式發佈，除了增加的新功能，已有能力也在大量社區用戶反饋的過程中不斷完善改進，這個版本同時標誌着 1.x 進入可以大規模生產使用的狀態。

新版本：功能速覽

自發布 1.2 版本過去了一個多月時間，1.3 版本正式發佈，帶來兩個全新能力：

新標準： 支持最新版本 Gateway API 標準，並且具備從 Ingress 平滑漸進演進，以及對接多種服務發現機制的能力。
新工具： 正式 release 了 hgctl (Higress Crontroller) 這個 "All in one" 的新工具，不僅可以替代 Helm 實現更簡易的安裝，還提供了 WASM 插件開發工具包，以及網關配置檢查等豐富功能。

除了這兩個核心功能外，還有一些實用功能：

提供了 Higress Admin Java SDK，可以統一對接 K8s 和非 K8s 環境，管理域名/路由等配置
提供了 OIDC 插件，支持對接 Keycloak/Okta 等第三方身份認證系統
Higress Console 的易用性和安全性提升，不再通過路由暴露，支持界面初始化/修改密碼

與此同時，Higress 開源社區已經開始準備踏上一段全新的開源征程...

新標準：支持最新版 Gateway API

Gateway API 在 11 月 1 日正式發佈了 1.0.0 版本，其中 GatewayClass, Gateway, HTTPRoute 這三個 API 正式宣佈 GA，發佈了 v1 版本：gateway.networking.k8s.io/v1。

目前 Higress 已經可以支持這些最新版本的 API 配置，只需在安裝/升級 Higress 時配置開啓 Gateway API：

使用 Helm ：通過參數 --set global.enableGatewayAPI=true
使用 hgctl ：通過命令行參數或者 install.yaml 中配置 global.enableGatewayAPI=true

首先創建 GatewayClass 資源：

  apiVersion: gateway.networking.k8s.io/v1
  kind: GatewayClass
  metadata:
    name: higress-gateway
  spec:
    controllerName: "higress.io/gateway-controller"

接着在安裝 Higress 的命名空間下，創建 Gateway 資源，通過 gatewayClassName 關聯上面創建的 GatewayClass 資源，指定由 Higress 來管理此 Gateway 配置，下面爲域名同時配置了 HTTP 和 HTTPS 入口，併爲 HTTPS 入口配置了證書：

  apiVersion: gateway.networking.k8s.io/v1
  kind: Gateway
  metadata:
    name: higress-gateway
    namespace: higress-system
  spec:
    gatewayClassName: higress-gateway
    listeners:
    - name: foobar
      hostname: "*.foobar.com"
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: All
    - name: foobar-https
      hostname: "*.foobar.com"
      port: 443
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: All
      tls:
        certificateRefs:
        - kind: Secret
          name: wildcard-foobar-com
        mode: Terminate

因爲上面 Gateway 通過 allowedRoutes 配置了允許所有命名空間的路由來關聯，所以這裏在 default 命名空間下創建 HTTPRoute，關聯上面創建的 Gateway，即可定義域名下的具體路由：

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: foobar
    namespace: default
  spec:
    parentRefs:
    - name: higress-gateway
      namespace: higress-system
    hostnames: ["www.foobar.com"]
    rules:
    - matches:
      - path:
          type: PathPrefix
          value: /foo
      backendRefs:
      - name: foo-service
        port: 5678

以上就是 Gateway API 的一個簡單用法示例，Gateway API 還有很多功能和玩法，後面 Higress 公衆號/博客會出一個系列進行系統分享和介紹。

歡迎結合官方 API 文檔，並使用 hgctl （獲取方式見下文）在自己電腦上安裝一個 local-k8s 模式的 Higress，來開啓對這一新標準的探索：

  # 一鍵安裝, 交互式命令選擇第一種安裝模式 local-k8s，將默認安裝 Gateway API CRD
  hgctl install

多種服務發現能力

在 Ingress API 標準下，Higress 對接多種服務發現能力是獨樹一幟的，在 Gateway API 標準下， Higress 仍就保持了這一能力優勢：

首先通過 McpBridge 資源(https://higress.cn/zh-cn/docs/user/mcp-bridge)，可以定義多種服務發現機制，例如 Nacos/Zookeper/Eureka/Consul 等。

下面創建一個 HTTPRoute 資源，可以同時對接 K8s 服務，和註冊到 Nacos 的服務，並實現灰度路由能力：

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: http
    namespace: default
  spec:
    parentRefs:
    - name: higress-gateway
      namespace: higress-system
    rules:
    - matches:
      - path:
          type: PathPrefix
          value: /
      backendRefs:
      - name: service-provider.DEFAULT-GROUP.public.nacos
        group: networking.higress.io
        port: 8080
        weight: 90
      - name: foo-service
        port: 5678
        weight: 10

和 K8s 服務不同的是，這裏 group 爲 networking.higress.io 的服務並不需要提前創建 CRD 資源，這更符合傳統微服務用戶的習慣，即服務模型不需要提前創建，是通過服務節點註冊自動生成。

Ingress API 和 Gateway API 之間如何選擇

有了 Gateway API，是否應該立即拋棄 Ingress API？

只有最合適的，沒有最好的。Gateway API 雖然爲更多網關能力做了標準化，但 CRD 的種類和複雜度也增加了，相比之下對於大部分簡單用例場景，Ingress API 更加簡單易用。

對於以下場景，採用 Gateway API 替代 Ingress API 會帶來很大幫助：

大型團隊劃分了 SRE 角色和業務研發角色，由 SRE 通過 Gateway 資源統一管理站點域名和證書，由業務研發通過 HTTPRoute 資源管理業務路由，實現職責劃分，權限收斂
創建的路由和 Service 有不在一個命名空間的需求，可以藉助 ReferenceGrant 資源實現
有大量證書需要集中式管理，不希望將證書 Secret 同步到 Ingress 所在命名空間，帶來安全風險

Gateway API 的另一個好處是對於更多功能的標準化定義，我們建議遇到實際需要再轉換到這個新的標準，而不必盲目跟隨。

Higress 支持 Gateway API 和 Ingress API 混合使用，Gateway API 下的域名路由將比 Ingress API 優先匹配，和 Ingress 相同資源名稱的 HTTPRoute 還會繼承 WASM 插件配置，這樣用戶可以按需採用 Gateway API，平滑地完成從 Ingress API 向 Gateway API 的演進，無需焦慮 API 標準升級過程中產生業務損失。

新工具：AII in one 的 hgctl

替代 Helm 用於安裝/升級

在 K8s 下用 Helm 安裝/升級組件很方便，但在 Higress 的場景下仍然存在一些問題：

無法支持非 K8s 場景下的安裝/升級
Higress 有很多安裝參數，進行升級等操作時不好維護，使用 reuse-values 有一些副作用，且容易誤操作
無法管理 CRD 跟隨版本更新，需要手動更新

Higress 借鑑了 istio 的 istioctl，提供了 hgctl 這個命令行工具解決了上述問題，通過以下命令即可安裝 hgctl。

  # 下載最新版 Hgctl：
  curl -Ls https://raw.githubusercontent.com/alibaba/higress/main/tools/hack/get-hgctl.sh | VERSION=latest bash

hgctl 集成了三種 Higress 安裝模式，並統一了升級/運維操作：

本地 K8s 環境（例如 kind/k3s）模式
正式 K8s 環境模式
不依賴 K8s 的純 Docker 環境模式

直接執行 hgctl install 命令即可選擇任意模式進行安裝

安裝配置文件將存至 ~/.hgctl/profiles/install.yaml 目錄下，查看該文件內容如下：‍‍

  charts:
    higress:
      name: higress
      # 安裝文件的 helm repo 地址
      url: https://higress.io/helm-charts
      # 執行 hgctl upgrade 時將自動更新至最新版本
      version: latest
  console:
    # 開啓可觀測組件
    o11YEnabled: true
    # 控制檯實例數
    replicas: 1
  controller:
    # 控制面組件實例數
    replicas: 1
  gateway:
    # 數據面組件實例數
    replicas: 1
  global:
    # 開啓 Gateway API
    enableGatewayAPI: true
    # 開啓 Istio API
    enableIstioAPI: true
    # 設置監聽的 ingress class
    ingressClass: higress
    # 安裝模式
    install: local-k8s
    # 安裝命名空間
    namespace: higress-system
  # 配置傳遞給 helm 的 values 參數 
  values: {}
  profile: local-k8s

修改上面文件的內容後，執行 hgctl upgarde 即可實現參數變更生效，如果只想修改參數，不想觸發版本升級，可以將 version 參數固定爲當前版本。

WASM 插件開發工具包

爲了標準化並簡化 WASM 插件的開發/編譯/測試/發佈，Higress 提供了 hgctl plugin 這一子命令，使用方式爲：

hgctl plugin init: 初始化 Golang WASM 插件項目，包括三個文件；
用戶編寫 WASM 插件邏輯；
hgctl plugin build --output-type files: 構建 WASM 插件，在本地輸出構建產物；
hgctl plugin test: 使用 docker compose 在本地測試 WASM 插件，如需修改插件邏輯，則返回第 2 步；
hgctl plugin build --output-type image: 構建 WASM 插件作爲 OCI 鏡像上傳至鏡像倉庫；
hgctl plugin install: 安裝 WASM 插件，可以通過本地的 yaml 文件或插件項目進行安裝。

另外，若需要查看已安裝的插件，則使用 hgctl plugin ls；若需要操作插件配置，則使用 hgctl plugin config。

通過這個工具，可以在構建 WASM 插件的同時，根據配置代碼自動生成插件的配置說明文檔，以及包含插件配置約束的元信息文件，這些內容都將和 WASM 文件一起放入 OCI 鏡像製品中，通過鏡像方式進行版本管理和分發。這一機制是後續 Higress 建設 WASM 插件市場的基石。

其他功能

另外介紹兩個實用的子命令：

hgctl dashboard：用於呼出 UI 界面，例如 Higress 控制檯，直接通過 hgctl dashboard console 即可打開

  $ hgctl dashboard
  Access to Higress web UIs
  
  Usage:
    hgctl dashboard [flags]
    hgctl dashboard [command]
  
  Aliases:
    dashboard, dash, d
  
  Available Commands:
    console     Open Console web UI
    controller  Open Controller debug web UI
    envoy       Open Envoy admin web UI
    grafana     Open Grafana web UI
    prometheus  Open Prometheus web UI

hgctl gateway-config：用於查看數據面的 envoy 配置，可以快速驗證配置是否正確下發

  $ hgctl gateway-config
  Retrieve information about Higress Gateway Configuration.
  
  Usage:
    hgctl gateway-config [command]
  
  Aliases:
    gateway-config, gc
  
  Available Commands:
    all         Retrieves all Envoy xDS resources from the specified Higress Gateway
    bootstrap   Retrieves bootstrap Envoy xDS resources from the specified Higress Gateway
    cluster     Retrieves cluster Envoy xDS resources from the specified Higress Gateway
    endpoint    Retrieves endpoint Envoy xDS resources from the specified Higress Gateway
    listener    Retrieves listener Envoy xDS resources from the specified Higress Gateway
    route       Retrieves route Envoy xDS resources from the specified Higress Gateway

新徵程：API Gateway

上面說了 Gateway API，接着我們聊聊 API Gateway 😄，API Gateway 有兩層定義：

狹義上： 滿足統一接入，將路由轉發到不同服務的運維需求，即可稱爲 API Gateway；這裏 API 的定義是服務的路由
廣義上： 在實現服務轉發的基礎上，需要識別帶業務語義的接口，將業務能力 API 化管理，統一對外提供服務；這裏 API 的定義是業務功能接口

Higress 已經實現了狹義上的 API Gateway 能力，並且是基於 Gateway/Ingress API 這些通用路由標準來實現的。而與服務路由標準不同，業務功能接口的標準是 Swagger/OAS3/RPC IDL 等，做爲 API Gateway 需要提供以下關鍵能力：

支持通過上傳 Swagger 等接口定義文件的方式導入 API
對 API 實現精細化策略管理，例如根據出入參定義實現參數映射/轉換
實現以 API 方式開放能力時的認證/鑑權，調用量控制/審計能力

Higress 新的開源征程將向具備業務 API 管理能力的 API Gateway 形態進發。在實現方式上，我們將基於 WASM 插件去擴展這一部分能力，這可以降低我們對上游 Envoy 社區的侵入性改造，同時讓對 API 的精細化策略管理具備自定義擴展能力。目前社區已經有一些 Proposal ，歡迎瞭解：

https://github.com/alibaba/higress/issues/535

https://github.com/alibaba/higress/issues/601

歡迎有更多小夥伴加入，和我們一起踏上新的征程，有興趣的小夥伴可以聯繫我(微信：nomadao)，加入 API Gateway 的 SIG（興趣小組）。

社區致謝

首先要感謝 Envoy 和 Istio 社區，Higress 站在這兩個軟件的肩膀上演進能力，得以：

通過 WASM 機制擴展 Envoy 數據面能力，持續不斷地擴大網關插件生態
通過專注在網關領域，在 Istio 優秀的控制面基礎上，進一步做抽象和簡化，降低上手和運維門檻

還要感謝參與 Higress 開源貢獻的開發者們，這裏重點感謝下爲 1.3 版本做出核心貢獻的開發者：

Maintainer：董藝荃(CH3CHO)

人如其名“藝全”，十八般武藝樣樣精通，不管是控制檯 TS 前端，Java 後臺，還是 Higress 的 GO 控制面，以及 Standalone 安裝 Shell 腳本和各種 CICD 流程，通通手到擒來。

在 1.3 版本中主要負責了 Higress 支持 Gateway API 的能力，以及實現了 Higress Admin Java SDK 可以提供外部集成用於管理 Higress 配置，並改進了 Higress Console 的安全性和易用性。

除了開發貢獻之外，他還對社區用戶充滿善意和熱情，無論是在 GitHub 的 Issues/Discussions，或是社區交流微信/釘釘羣，隨處可見他幫助用戶解決問題的身影。

Approver：吳新軍(Jun)，劉訓灼(Xunzhuo)

兩位都在多個 Higress 版本爲社區做出了貢獻，Jun 的主要貢獻有：在多註冊中心的服務發現支持，全局配置管理架構抽象；Xunzhuo 的主要貢獻有：Higress E2E 測試流程的搭建，GitHub CI 流程的建設，hgctl 的整體架構設計。

在 1.3 版本中二位協作完成了 hgctl 的多樣化能力建設，幫助 Higress 的易用性又上到了一個新的臺階。

兩位同學作爲 Approver 積極參與社區貢獻 PR 的 Review，目前分別是 Higress Tools SIG 和 Higress GatewayAPI SIG 的領導者。

Member：韋鑫(WeixinX)，封宇騰(Fkbqf)

兩位都是通過中科院開源之夏（OSPP 2023）項目開始參與 Higress 貢獻，WeixinX 是一名研二的學生，Fkbqf 是一名大三的學生。

在 1.3 版本中，WeixinX 實現了 hgctl plugin 子命令的能力，同時貢獻了 Go 實現的 Basic Auth 插件，以及對標 Spring Cloud Gateway 請求響應轉換能力的 Transformer 插件；Fkbqf 則實現了更爲複雜的 OIDC 插件，具備比 Envoy 自帶 OAuth2 Filter 更強大的功能，並且具備良好的擴展性。

兩位同學除了開發貢獻以外，用課餘時間積極參與 Higress 社區週會，一起探討和學習技術，不亦樂乎。能夠成爲你們人生學業進階路上的階梯，

Higress 榮幸之至。Higress 社區後續整體的 Roadmap 規劃如下：

Higress 開源一週年：新版本，新標準，新工具，新徵程

歷程回顧

新版本：功能速覽

新標準：支持最新版 Gateway API

多種服務發現能力

Ingress API 和 Gateway API 之間如何選擇

新工具：AII in one 的 hgctl

替代 Helm 用於安裝/升級

WASM 插件開發工具包

其他功能

新徵程：API Gateway

社區致謝

Maintainer：董藝荃(CH3CHO)

Approver：吳新軍(Jun)，劉訓灼(Xunzhuo)

Member：韋鑫(WeixinX)，封宇騰(Fkbqf)

Python 潮流週刊#50：我最喜歡的 Python 3.13 新特性！

iLogtail 社區開源之夏活動來了！

通義靈碼入職阿里雲後，同事們的工作發生了哪些改變？

全景剖析阿里雲容器網絡數據鏈路（七）：Terway DataPath V2（Terway≥1.8.0）

通義靈碼牽手阿里雲函數計算 FC ，打造智能編碼新體驗

Serverless 成本再優化：Knative 支持搶佔式實例

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結