关于kubernetes:Apache-APISIX-Ingress-v15rc1-发布

Apache APISIX Ingress Controller v1.5-rc1 版本正式公布。此版本历时 7 个月左右的工夫，由 36 位贡献者进行了 144 次提交。其中有 22 位新晋贡献者，感激大家对本我的项目的奉献与反对！

接下来就让咱们一起看下，在 APISIX Ingress v1.5 版本中有哪些重要更新。

在 APISIX Ingress 我的项目初始，只有多数的几个 CRD，并且每个资源都是各自进行 API Version 的保护。这就导致了后续有新资源引入或性能迭代的过程中，会呈现每个自定义资源应用的 API Version 都不一样的情况，从而减少用户学习老本。

所以从 v1.3 版本开始，咱们提出了对立所有资源 API Version 的 Proposal。通过两个版本的迭代，现已正式引入了 v2 API Version，同时将 v2beta3 标记为废除，直到 v1.7 版本时会齐全移除 v2beta3。

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 的预期保持一致。

在 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

关于kubernetes:Apache-APISIX-Ingress-v15rc1-发布

所有 CRD API Version 降级至 v2

根本反对 Gateway API

容许 Ingress 资源绑定任意插件

更多细节