共计 2865 个字符，预计需要花费 8 分钟才能阅读完成。
间隔上一个版本 v1.5 公布，曾经过了 3 个月，咱们很快乐地发表 Apache APISIX Ingress v1.6 正式公布！
在该版本中，共有 29 位贡献者 参加代码提交，其中 17 位是新晋贡献者 ，感激大家的反对和参加！
本次公布的 Apache APISIX Ingress v1.6 版本带来了泛滥新个性，次要集中在对 Gateway API 的反对，同时也在扩大 APISIX Ingress 的应用场景和易用性方面的晋升。以下是一些重点个性的介绍。
扩大对 Gateway API 的反对
Gateway API 是 Kubernetes 中下一代的 Ingress 标准，致力于提供富裕表现力，可扩大和面向角色的接口来倒退 Kubernetes 的网络，各个 Ingress controller 我的项目都在踊跃推动对该标准的反对。Apache APISIX Ingress 我的项目自 2021 年开始就在踊跃地紧跟上游社区的倒退，并踊跃推动 Gateway API 在 APISIX Ingress 我的项目中的实现。
以后，Apache APISIX Ingress 我的项目中通过 Gateway API 进行配置的个性尚处于 beta 阶段，欢送大家在测试环境中踊跃进行测试，并提供反馈，咱们将继续的对此个性进行优化和改良，尽早实现此个性的 GA。
在 APISIX Ingress v1.6 版本中，咱们增加了对 Gateway API 中的 TCPRoute 和 UDPRoute 这两种资源的反对。同时，扩大了对 HTTPRoute 资源中 Filters 的反对，这样用户在应用 HTTPRoute 资源时，就能够在该资源中利用一些重定向、Header 改写等能力了。
例如能够应用如下配置：
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
name: http-route
spec:
hostnames: ["httpbin.org"]
rules:
- matches:
- path:
type: PathPrefix
value: /headers
filters:
- type: RequestHeaderModifier
requestHeaderModifier:
add:
- name: X-Api-Version
value: v1
- name: X-api-key
value: api-value
set:
- name: X-Auth
value: filter
remove:
- Remove-header
backendRefs:
- name: httpbin
port: 80 通过应用此配置，客户端在对 httpbin.org 进行申请时，将会增加 "X-Api-Version": "v1" 和 "X-Api-Key": "api-value" 的申请头，并将 "X-Auth" 申请头的值设置为 filter，同时将移除 "Remove-Header" 这个申请头。
反对与服务发现组件的集成
Kubernetes 中默认是应用基于 DNS 的服务发现机制，然而利用在迁徙和革新的过程中，并非所有的业务都会抉择革新成基于 DNS 的这种服务发现机制，依然有大量微服务架构的利用会持续应用原有的服务注册发现组件，比方 Consul，Nacos，Eureka 等。
为了将 APISIX Ingress 打造成一款更加好用的 Ingress controller，咱们在 v1.6 版本中新增了与服务发现组件集成的能力，用户能够将注册在 Consul/Nacos/Eureka/DNS 中的服务，通过 APISIX Ingress 裸露进去，无论是南北向还是东西向流量的场景均可应用。
例如通过如下配置，申明要代理的服务是通过 Nacos 注册的名为 httpbin 的服务。
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
name: httpbin-upstream
spec:
discovery:
type: nacos
serviceName: httpbin而后在 ApisixRoute 资源中对其进行援用即可：
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: httpbin-route
spec:
http:
- name: rule1
match:
hosts:
- local.httpbin.org
paths:
- /*
upstreams:
- name: httpbin-upstream这样客户端在拜访时，就会被 APISIX 代理到 Nacos 中注册的服务了。更多内容可参考文档。
反对代理内部服务
与上述性能相似，Apache APISIX Ingress v1.6 版本中还增加了对外部服务代理的能力。次要是为了便于用户对一些没有部署在 Kubernetes 中的内部服务进行代理。
最典型的场景比如说音讯推送。业务为了保障服务的高可用，通常会抉择多家供应商提供服务，但供应商也可能会呈现一些异样的状况。这种时候就能够通过这个性能，在多个供应商提供的服务中进行动静调度了。
比方通过如下配置设置两个供应商的域名作为后端：
apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
name: notify-api
spec:
externalNodes:
- type: Domain
name: foo.com
- type: Domain
name: bar.com
healthCheck:
passive:
unhealthy:
httpCodes:
- 500
- 502
- 503
- 504
httpFailures: 3
timeout: 5s
active:
type: http
httpPath: /healthz
timeout: 5s
healthy:
successes: 3
interval: 2s
httpCodes:
- 200而后在 ApisixRoute 资源中进行援用：
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: notify-route
spec:
http:
- name: rule1
match:
hosts:
- local.notify.app
paths:
- /*
upstreams:
- name: notify-api这样，如果某个供应商的服务出现异常，则会依据健康检查的规定主动地代理到备用的服务上，从而保障业务的可用性。
同样的，如果业务中存在须要代理 ExternalName Service 的场景也能够应用这种形式进行代理。更多内容可参考文档。
其余
除了上述的这些性能外，在此版本中还增加了很多其余性能，包含：
- 反对 Ingress 资源中代理不同 namespace 中的后端服务；
- 原生的 MQTT 协定的代理反对；
- 容许为 4 层代理增加插件反对；
- 容许在 ApisixRoute 资源中应用 vars 进行条件匹配；
- 日志轮转反对；
更多具体的变更请查看 Release Note：https://github.com/apache/api…
