共计 1638 个字符,预计需要花费 5 分钟才能阅读完成。
Apache APISIX Ingress Controller v1.5-rc1 版本正式公布。此版本历时 7 个月左右的工夫,由 36 位贡献者进行了 144 次提交。其中有 22 位新晋贡献者,感激大家对本我的项目的奉献与反对!
接下来就让咱们一起看下,在 APISIX Ingress v1.5 版本中有哪些重要更新。
所有 CRD API Version 降级至 v2
在 APISIX Ingress 我的项目初始,只有多数的几个 CRD,并且每个资源都是各自进行 API Version 的保护。这就导致了后续有新资源引入或性能迭代的过程中,会呈现每个自定义资源应用的 API Version 都不一样的情况,从而减少用户学习老本。
所以从 v1.3 版本开始,咱们提出了对立所有资源 API Version 的 Proposal。通过两个版本的迭代,现已正式引入了 v2 API Version,同时将 v2beta3 标记为废除,直到 v1.7 版本时会齐全移除 v2beta3。
根本反对 Gateway API
Gateway API 能够说是下一代的 Ingress 定义,具备更加丰盛的体现能力。咱们曾经在 APISIX Ingress 中实现其中大多数资源的反对(留神,此个性目前还在试验性质,默认不启用)。
如果想要在 APISIX Ingress 中应用 Gateway API,能够在 controller 的配置文件中传递 enable_gateway_api: true
配置项来开启此性能。
在装置完 Gateway API 的 CRD 后,即可通过创立 HTTPRoute
资源来实现 7 层代理的配置。如下所示:
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
name: httpbin-route
spec:
hostnames: ["httpbin.local"]
rules:
- matches:
- path:
type: PathPrefix
value: /ip
backendRefs:
- name: httpbin
port: 80
该配置失效后,客户端将能够通过 httpbin.local/ip
拜访到后端 httpbin 的 80 端口。
此外,咱们打算在 v1.6 版本中实现 Gateway API 残余 TCPRoute
和 UDPRoute
这两种资源的反对,并打算引入 Gateway API 的一致性测试,以确保咱们的实现与 Gateway API 的预期保持一致。
容许 Ingress 资源绑定任意插件
在 Apache APISIX Ingress Controller 我的项目中,反对应用 Kubernetes 原生的 Ingress 资源进行代理配置,但如果想要在 Ingress 资源中应用 APISIX 丰盛的插件能力,就必须通过减少 Annotation 来实现,并且须要实现对应 Annotation 的逻辑。
这种形式限度了 Ingress 资源的插件能力,而且为每个插件独自开发 Annotaion 是一个绝对高老本的事件。
在 v1.5 版本中,咱们通过为 Ingress 资源减少了一个新的 Annotaion k8s.apisix.apache.org/plugin-config-name
,这容许援用任意的 ApisixPluginConfig
资源,从而实现了让 Ingress 资源能够随便应用任意 APISIX 插件的能力。这将大大增加 APISIX Ingress Controller 的易用性,也将升高用户从其余 Ingress controller 向 APISIX Ingress Controller 迁徙时的老本。
更多细节
除以上这些个性外,该版本中还退出了很多其余个性。比方:
- 定时 Kubernetes 集群往 APISIX 集群中同步数据的机制,保障 APISIX 集群中数据与在 Kubernetes 集群中配置的一致性;
- 为 ApisixConsumer 资源减少了更多的认证形式;
- 与 APISIX v2.15 版的兼容;
- 将所有依赖更新到最新版本,以便缩小安全隐患;
更多具体发版细节,请参考 1.5-rc1 的 Changelog