关于apisix:为什么-APISIX-Ingress-是比-Ingress-NGINX-更好的选择

作者容鑫，API7.ai 云原生技术工程师，Apache APISIX Committer。

本文将会比照两个比拟风行的 Ingress controller 实现，心愿能对读者进行 Ingress controller 选型中有所帮忙。

Ingress NGINX 是 Kubernetes 社区实现的 Ingress controller，在社区中被宽泛应用。Apache APISIX Ingress 则是 Apache 软件基金会下的开源我的项目，应用 APISIX 作为数据面的 Kubernetes Ingress controller。

Ingress NGINX vs APISIX Ingress

性能比照

下列表格中，比照了 Ingress NGINX 和 APISIX Ingress 基本功能，包含协定反对、鉴权形式、上游探针 / 策略、负载平衡策略、Kubenertes 集成等。以下表格数据取自 learnk8s.io。

性能差别

通过下图，能够粗略看到 APISIX Ingress 内置的性能和个性相比 Ingress NGINX 更加丰盛，其中包含服务发现、协定反对、认证鉴权等等。

服务发现

在微服务架构中，利用被拆分为很多微服务，无论是微服务故障，还是对应用服务进行扩缩容，都须要尽快的告诉到调用方，免得调用失败。因而，在微服务架构中，服务注册和发现机制就显得很重要了，通常这会通过注册核心来实现。

协定反对

两者都对 HTTP/HTTPS 协定提供残缺反对，APISIX Ingress 在协定反对上更丰盛一些，可能的应用 TLS 来加密 TCP 流量，还反对 MQTT，Dubbo、Kafka 等协定进行代理。

服务治理能力

健康检查

在后端节点故障或者迁徙时，不可避免会呈现节点不可用的状况。如果大量申请拜访到了这些不可用的节点时，将会造成流量损失，导致业务中断。因而，须要对节点进行健康检查，通过探针的模式探测后端节点的可用性，将申请代理到衰弱的节点，从而缩小或防止流量损失。

健康检查的能力在 Ingress NGINX 中尚未反对，而 APISIX Ingress 提供了该能力，其中包含：

• 被动健康检查 ：确保后端服务中的 Pod 处于可用的状态。在应用服务进行滚动更新时，会牵扯大量的节点进行更新，不衰弱的节点将会被负载均衡器疏忽，开启健康检查可能无效的挑选出可用的 Pod，防止流量损失。
• 被动健康检查 ：被动的形式无需发动额定的探针，每个申请就是探针，若一个衰弱节点间断 N 个申请都被断定为失败（取决于如何配置），则该节点将被标记为不衰弱。因为无奈提前感知节点的状态，可能会有一定量的失败申请，在滚动更新时这种状况会绝对常见，能够通过服务降级来防止失败的申请量。

如下是 APISIX Ingress 为 httpbin 服务配置健康检查示例：

apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
name: httpbin
spec:
healthCheck:
passive:
unhealthy:
httpCodes:
- 500
httpFailures: 3
active:
type: http
httpPath: /healthz
healthy:
successes: 3
interval: 2s
httpCodes:
- 200

服务熔断

流量顶峰时，网关作为流量入口向后端服务发动调用，后端服务有可能会产生调用失败（超时或者异样），失败时不能让申请沉积在网关上，须要疾速失败并返回回去，这就须要在网关上进行熔断。

服务熔断的性能在 Ingress NGINX 中尚未反对。在 APISIX Ingress 中则能够通过 api-breaker 熔断插件来实现。

具体应用配置示例如下：

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: httpbin-route
spec:
http:
- name: rule1
match:
hosts:
- httpbin.org
paths:
- /status/*
backends:
- serviceName: httpbin
servicePort: 80
plugins:
- name: api-breaker
enable: true
config:
break_response_code: 502
unhealthy:
http_statuses:
- 505
failures: 2
healthy:
http_statuses:
- 200
successes: 2

插件和鉴权形式

目前 Ingress NGINX 次要通过 Annotations 和 ConfigMap 等形式进行配置，反对的插件性能比拟无限。如果想要应用 JWT、HAMC 等鉴权形式，只能自行开发。

而 APISIX Ingress 得益于 APISIX 的丰盛性能，原生反对 APISIX 内置的 80+ 插件，可能笼罩大部分应用场景，还反对 JWT、HMAC、wolf-rbac 等多种鉴权形式。以下仅展现 APISIX Ingress 应用 HMAC 认证并在路由上的利用示例：

apiVersion: apisix.apache.org/v2
kind: ApisixConsumer
metadata:
name: hmac-value
spec:
authParameter:
hmacAuth:
value:
access_key: papa
secret_key: fatpa
algorithm: "hmac-sha256"
clock_skew: 0
 
---
 
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
name: httpbin-route
spec:
http:
- name: rule1
match:
hosts:
- httpbin.org
paths:
- /ip
backends:
- serviceName: httpbin
servicePort: 80
authentication:
enable: true
type: hmacAuth

Ingress NGINX 和 APISIX Ingress 的扩大形式

除了以上这些细节比照外，两者对于额定性能的扩大也有所不同。当 Ingress controller 的根底性能无奈满足企业用户的需要时，只能通过扩大的形式进行定制开发。接下来将具体介绍 Ingress NGINX 和 APISIX Ingress 如何进行性能扩大。

Ingress NGINX 如何进行性能扩大

Ingress NGINX 在扩大形式上比拟繁多，只能通过嵌入 Lua 程序的形式来扩大性能。咱们以 Ingress NGINX 插件开发为例，大略须要以下步骤：

1. 编写 Lua 程序 example-plugin
2. 将插件装置到 ingress-nginx pod 中的 /etc/nginx/lua/plugins/<your plugin name> → /etc/nginx/lua/plugins/example-plugin
3. 在 ConfigMap 中启用 example-plugin 插件，须要在装置 Ingress NGINX 时援用此 ConfigMap 对象

apiVersion: v1
kind: ConfigMap
metadata:
name: ingress-nginx-controller
namespace: ingress-nginx
data:
plugins: "example-plugin"

APISIX Ingress 如何进行性能扩大

APISIX Ingress 提供了多种扩大形式，企业用户能够依据本身状况自由选择或组合，以后反对如下拓展形式：

• 通过 Lua 进行插件开发：这种形式绝对简略，并且简直没有性能损耗；
• 通过 plugin-runner 开发：这种模式下反对 Java/Python/Go 等语言进行开发，这能够不便用户利用一些现有的业务逻辑，并且无需学习新语言；
• 通过 WASM 进行插件插件：这种模式下，能够应用任何反对构建出 WASM 的语言进行插件开发；

此外还能够通过 Serverless 插件来间接编写 Lua 代码，疾速满足业务需要。

为什么 APISIX Ingress 抉择保护 CRD

目前 APISIX Ingress 反对三种申明式配置：Ingress、CRD 和 Gateway API。这里次要比照 Ingress 和 CRD，Gateway API 将在后续开展。

Ingress 比拟适宜从 Ingress NGINX 迁徙的企业用户，其转换老本较低。但毛病也较显著，比方语义化能力弱、没有粗疏标准等，同时也只能通过 Annotations 形式扩大，且 Annotations 无奈撑持简单配置场景。绝对的应用 CRD 次要有以下益处：

• 更符合数据面的设计语义，更加简略易用；
• 一些重要配置可能被复用，而不会存在冗余宏大的单个配置；
• 功能性和可扩大能力有了微小晋升；
• 数据面 APISIX 有着沉闷的社区，更新和公布版本快，CRD 的形式可能轻易反对数据面的更多能力；

Ingress NGXIN 的痛点：不反对配置热加载

动态配置带来的问题

Ingress NGINX 次要基于 NGINX 配置文件的形式，只管应用 NGINX + Lua 来实现性能扩大，但没有彻底解决动态配置文件的问题。在路由能力和加载模式上稍显有余，并且存在一些显著劣势。

比方增加、批改任何新的规定时，须要从新加载 NGINX 配置。随着越来越多的路由规定和证书，在触发变更时，reload 操作将会更耗时，甚至须要几秒到十几秒的工夫，对线上流量的影响将会十分大的，会导致流量短暂中断、影响响应提早、负载平衡品质（每次从新加载 NGINX 都会重置负载平衡状态）等。

触发 NGINX 从新加载的状况

以下这些状况，涵盖了 Ingress controller 大量的应用场景：

• 创立新的 Inresss 资源；
• 将 TLS 局部增加到现有 Ingress；
• Ingress Annotations 的变动可能影响上游配置（例如 load-balance 正文不须要从新加载）；
• 在 Ingress 中增加或删除 path；
• Ingress、Service、Secret 资源被删除；
• Secret 产生更新；

在上述场景下，具备频繁部署应用程序的集群环境中，会一直触发 Ingress、Secret 等资源的操作（创立、更新、删除等），导致 NGINX 从新加载次数剧增，给生产环境带来了极大的影响。

小结

Ingress NGINX 的架构决定了它必须生成 NGINX 配置而后通过 reload 形式实现配置更新，架构不调整是无奈解决这些已知问题。比方路由的实现，APISIX Ingress 则不再依赖 NGINX 配置改为了纯内存构造，通过热更新形式实现动静路由，不再须要重启 NGINX。

云原生新一代网关标准 Gateway API

Gateway API 劣势

Gateway API 相比 Ingress 的功能性更强，旨在通过由许多供应商实现并具备宽泛行业反对的富裕表现力、可扩大和面向角色的接口来倒退 Kubernetes 服务网络。当下 Gateway API 具备如下的劣势：

• 面向角色：Gateway 是由一组 API 资源组成的。不同的 API 资源代表了应用与配置 Kubernetes 网络资源的不同角色；
• 表现力强：Gateway API 的外围性能就蕴含诸如基于头的匹配、流量加权以及其余在 Ingress 中只能通过各实现者自定义的非标准化 Annotations 等形式实现的性能；
• 可扩大：Gateway API 容许不同资源在不同层级一起应用。这使得可能对 API 构造进行更精细化的管制。

反对状况

Gateway API 作为一种扩大 Kubernetes 服务网络的规范，其 Gateway 资源可能实现作为 Kubernetes API 来治理网关的生命周期，性能非常弱小。目前许多 Ingress controller 都在积极支持它，包含 Istio、Kong、Traefik 等。在目前 Gateway API 实现状况中，很遗憾的是，Ingress NGXIN 尚未打算反对 Gateway API。而 APISIX Ingress 曾经反对了 Gateway API 的大部分个性：包含 HTTPRoute、TCPRoute、TLSRoute、UDPRoute 等。

总结

通过 APISIX Ingress 与 Ingress NGINX 的残缺比照，咱们能够看到两者根底性能差别不大，也都具备扩大能力。但在微服务的架构中，APISIX Ingress 对服务治理和服务发现的反对更具劣势。

总体来看，两款开源软件均十分优良，Ingress NGINX 次要特点是简略、易接入，但毛病也非常显著；APISIX Ingress 作为后来者解决了 NGINX 不反对热加载的痛点，在扩大能力和性能上相比 Ingress NGINX 也具备很大的劣势。从我的项目倒退角度而言，反对 Gateway API 和 CRD 可能扩大和丰盛 Ingress controller 根底能力。

如果读者正在进行 Ingress controller 选型，偏向于功能丰富和更强的扩大能力，举荐应用 APISIX Ingress。如果只是刚接触 Ingress controller，没有更多的性能需要，Ingress NGINX 也是一个比拟好的抉择。