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 资源:
接着在安装 Higress 的命名空间下,创建 Gateway 资源,通过 gatewayClassName 关联上面创建的 GatewayClass 资源,指定由 Higress 来管理此 Gateway 配置,下面为域名同时配置了 HTTP 和 HTTPS 入口,并为 HTTPS 入口配置了证书:
因为上面 Gateway 通过 allowedRoutes 配置了允许所有命名空间的路由来关联,所以这里在 default 命名空间下创建 HTTPRoute,关联上面创建的 Gateway,即可定义域名下的具体路由:
以上就是 Gateway API 的一个简单用法示例,Gateway API 还有很多功能和玩法,后面 Higress 公众号/博客会出一个系列进行系统分享和介绍。
欢迎结合官方 API 文档,并使用 hgctl (获取方式见下文)在自己电脑上安装一个 local-k8s 模式的 Higress,来开启对这一新标准的探索:
多种服务发现能力
在 Ingress API 标准下,Higress 对接多种服务发现能力是独树一帜的,在 Gateway API 标准下, Higress 仍就保持了这一能力优势:
首先通过 McpBridge 资源(https://higress.cn/zh-cn/docs/user/mcp-bridge),可以定义多种服务发现机制,例如 Nacos/Zookeper/Eureka/Consul 等。
下面创建一个 HTTPRoute 资源,可以同时对接 K8s 服务,和注册到 Nacos 的服务,并实现灰度路由能力:
和 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 集成了三种 Higress 安装模式,并统一了升级/运维操作:
本地 K8s 环境(例如 kind/k3s)模式
正式 K8s 环境模式
不依赖 K8s 的纯 Docker 环境模式
直接执行 hgctl install 命令即可选择任意模式进行安装
安装配置文件将存至 ~/.hgctl/profiles/install.yaml 目录下,查看该文件内容如下:
修改上面文件的内容后,执行 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 gateway-config:用于查看数据面的 envoy 配置,可以快速验证配置是否正确下发
新征程: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 规划如下:
版权声明: 本文为 InfoQ 作者【阿里巴巴云原生】的原创文章。
原文链接:【http://xie.infoq.cn/article/ef975f144d1fa6b258c55ba6c】。文章转载请联系作者。
评论