作者: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 版本正式发布,带来两个全新能力:
除了这两个核心功能外,还有一些实用功能:
与此同时,Higress 开源社区已经开始准备踏上一段全新的开源征程…
Gateway API 在 11 月 1 日正式发布了 1.0.0 版本,其中 GatewayClass, Gateway, HTTPRoute 这三个 API 正式宣布 GA,发布了 v1 版本:gateway.networking.k8s.io/v1。
目前 Higress 已经可以支持这些最新版本的 API 配置,只需在安装/升级 Higress 时配置开启 Gateway API:
首先创建 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 资源,这更符合传统微服务用户的习惯,即服务模型不需要提前创建,是通过服务节点注册自动生成。
有了 Gateway API,是否应该立即抛弃 Ingress API?
只有最合适的,没有最好的。Gateway API 虽然为更多网关能力做了标准化,但 CRD 的种类和复杂度也增加了,相比之下对于大部分简单用例场景,Ingress API 更加简单易用。
对于以下场景,采用 Gateway API 替代 Ingress API 会带来很大帮助:
Gateway API 的另一个好处是对于更多功能的标准化定义,我们建议遇到实际需要再转换到这个新的标准,而不必盲目跟随。
Higress 支持 Gateway API 和 Ingress API 混合使用,Gateway API 下的域名路由将比 Ingress API 优先匹配,和 Ingress 相同资源名称的 HTTPRoute 还会继承 WASM 插件配置,这样用户可以按需采用 Gateway API,平滑地完成从 Ingress API 向 Gateway API 的演进,无需焦虑 API 标准升级过程中产生业务损失。
在 K8s 下用 Helm 安装/升级组件很方便,但在 Higress 的场景下仍然存在一些问题:
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 安装模式,并统一了升级/运维操作:
直接执行 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 插件的开发/编译/测试/发布,Higress 提供了 hgctl plugin 这一子命令,使用方式为:
另外,若需要查看已安装的插件,则使用 hgctl plugin ls;若需要操作插件配置,则使用 hgctl plugin config。
通过这个工具,可以在构建 WASM 插件的同时,根据配置代码自动生成插件的配置说明文档,以及包含插件配置约束的元信息文件,这些内容都将和 WASM 文件一起放入 OCI 镜像制品中,通过镜像方式进行版本管理和分发。这一机制是后续 Higress 建设 WASM 插件市场的基石。
另外介绍两个实用的子命令:
$ 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
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
上面说了 Gateway API,接着我们聊聊 API Gateway ,API Gateway 有两层定义:
Higress 已经实现了狭义上的 API Gateway 能力,并且是基于 Gateway/Ingress API 这些通用路由标准来实现的。而与服务路由标准不同,业务功能接口的标准是 Swagger/OAS3/RPC IDL 等,做为 API Gateway 需要提供以下关键能力:
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 站在这两个软件的肩膀上演进能力,得以:
还要感谢参与 Higress 开源贡献的开发者们,这里重点感谢下为 1.3 版本做出核心贡献的开发者:
人如其名“艺全”,十八般武艺样样精通,不管是控制台 TS 前端,Java 后台,还是 Higress 的 GO 控制面,以及 Standalone 安装 Shell 脚本和各种 CICD 流程,通通手到擒来。
在 1.3 版本中主要负责了 Higress 支持 Gateway API 的能力,以及实现了 Higress Admin Java SDK 可以提供外部集成用于管理 Higress 配置,并改进了 Higress Console 的安全性和易用性。
除了开发贡献之外,他还对社区用户充满善意和热情,无论是在 GitHub 的 Issues/Discussions,或是社区交流微信/钉钉群,随处可见他帮助用户解决问题的身影。
两位都在多个 Higress 版本为社区做出了贡献,Jun 的主要贡献有:在多注册中心的服务发现支持,全局配置管理架构抽象;Xunzhuo 的主要贡献有:Higress E2E 测试流程的搭建,GitHub CI 流程的建设,hgctl 的整体架构设计。
在 1.3 版本中二位协作完成了 hgctl 的多样化能力建设,帮助 Higress 的易用性又上到了一个新的台阶。
两位同学作为 Approver 积极参与社区贡献 PR 的 Review,目前分别是 Higress Tools SIG 和 Higress GatewayAPI SIG 的领导者。
两位都是通过中科院开源之夏(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 规划如下: