为什么 APISIX Ingress 是比 Emissary-ingress 更好的选择?

更新时间 2/24/2023

背景

Kubernetes Ingress 是一种 API 对象,用于定义集群外部流量如何路由到集群内部服务的规则。Ingress Controller 通常用于实现 Ingress 资源的相关逻辑,并统一管理这些流量规则。

Ingress

在实践中,企业用户往往需要 mTLS、重试、限流和鉴权等流量管理功能,但 Ingress 资源语义无法满足需要。因此,Ingress Controller 实现往往使用新增 CRD 等方式对功能进行扩展。接下来将详细介绍和对比 APISIX Ingresss 和 Emissary-ingress 两种实现的差异。

什么是 APISIX Ingress

Apache APISIX Ingress 是 Apache 软件基金会旗下的开源项目,其控制平面负责对 Kubernetes 中资源进行配置转换并进行交付,实际的业务流量则由 APISIX 承载。为了提高安全性,整个部署过程采用了数据面和控制面完全分离的架构,从而有效避免了数据面被攻击导致 Kubernetes 集群权限泄露的风险。

apisix-ingress-controller

什么是 Emissary-ingress

Emissary-ingress 是 CNCF 的孵化项目,作为 Envoy proxy 的控制平面,它负责解析 Kubernetes 资源,所有流量都直接由数据面 Envoy 来处理。通过将控制面和数据面打包为一个容器,使整体更易接入和部署。

emissary-ingress

APISIX Ingress 和 Emissary-ingress 的区别

除了对 Ingress 资源的支持外,两者都支持了 CRDs、Gateway API 的配置方式,以弥补 Ingress 语义的不足。

下文将从基本能力、服务发现、可扩展性等方面分析两者之间的区别和优势。

基本功能

Feature APISIX Ingress Emissary-ingress
Protocols HTTP/HTTPS
gRPC
TCP
UDP
Websockets
Load balance Round Robin
Ring Hash
Least Connections
Maglev
Authentication External Auth
Basic
JWT
OAuth
OpenID
Traffic Management Circuit Breaker
Rate Limiting
Canary
Fault Injection
Health Checks

常见的网关功能,包括流量管理、负载均衡、鉴权等。值得注意的是,Emissary-ingress 在鉴权方面的支持相对较少,只包含了最基本的 Basic Auth 和 External Auth 能力。

服务发现

在微服务架构中,应用通常被拆分为多个微服务,它们相互协作以完成具体的业务逻辑。由于微服务实例的数量不断变化,这就需要一种机制来帮助服务之间相互发现和定位。

服务发现是指微服务在网络上的定位方式,通过服务名获取服务发现的信息以确定请求路由到哪个实例。对于传统的微服务框架,注册中心的选型往往是结合业务自身需求,如果将已存在的服务注册和发现组件迁移到基于 Kubernetes 的 DNS 服务发现机制,这需要一定的改造成本。如果网关支持现有的服务注册和发现组件,就不需要进行这些改造,从而更好地支持微服务框架。

以下是两者对服务发现组件的支持情况:

Service DiscoveryApache APISIX IngressEmissary-ingress
Kubernetes
DNS
Nacos
Eureka
Consul

在服务发现生态方面,APISIX Ingress 拥有着更高支持力度,用户可以非常方便的通过 Ingress Controller 集成到用户现有的微服务框架中。

可扩展性

当 Kubernetes Ingress Controller 的功能无法满足特定的需求时,用户可以通过二次开发的方式来扩展其功能。通过开发自定义插件或者修改现有的代码,可以满足更加个性化的需求。扩展性强的 Ingress Controller 可以更加方便地开发和定制化功能,为特定场景提供更好的支持和解决方案。

Emissary-ingress

Emissary-ingress 可扩展性是比较差的,不支持通过自定义 Envoy Filter 的方式进行拓展。由于数据面和控制面作为一个整体,这就需要对整体进行二次开发,数据面 Envoy 的二开复杂度高,这给开发者带来了很大的负担。

除此之外,如果用户需要更强大的 Emissary-ingress,需要将其升级为 Ambassador 的商业产品 Edge Stack,一些专有功能需要付费以获取支持

APISIX Ingress

数据面 APISIX 主要通过插件的方式进行功能扩展,提供了 80+ 开箱即用的插件。APISIX Ingress 支持了 APISIX 提供的所有插件,可满足大多数日常使用场景。

如果需要根据自身的业务场景进行功能定制,APISIX 提供了多种扩展方式,可以根据自身情况自由选择、组合。 目前支持的扩展方式如下:

  1. 使用 Lua 语言进行插件开发,这种方式相对简单,并且几乎没有性能损耗。此外还可以通过 serverless 插件来直接编写 Lua 代码,快速的满足业务需求。
  2. 除了内置原生的 Lua 语言,还可以通过 Plugin Runner 或 WASM 插件来进行扩展,这种模式下支持 Java/Python/Go 等语言开发自定义插件。使用户能够利用一些现有的业务逻辑,还可以根据公司已有技术栈或研发喜好自行选择,而无需学习新语言。

以上扩展方式,APISIX Ingress 都能够完整的支持,无需进行额外的开发。

性能

作为 Kubernetes 入口流量代理组件,接管了平台所有的入口流量,统一管理多种流量规则,这对代理的性能也有了更高的要求。

本文将在相同的实例(4C 8G)中,分别对 APISIX Ingress(APISIX:3.1.0) 和 Emissary-ingress 3.4.0 进行性能测试。

QPS

QPS(Queries-per-second),每秒查询率:服务每秒处理的请求数量,数值越大性能越好。

  • 单个 Ingress 资源 QPS

1-ingress-qps

  • 5000 Ingress 资源 QPS

5000-ingress-qps

Latency

响应延迟:服务器响应时间,延迟越小,性能越好

latency

小结

从图中可以发现,在面对不同的资源规模时,APISIX Ingress 的性能不会受到影响,表现十分均衡。而 Emissary-ingress 在资源规模较大时,匹配不同的路由对 QPS 和延时产生了严重的影响,其性能随着资源数量的增加而不断下降。由此可见,在实际生产环境中,随着业务体量的不断增长,APISIX 的高性能优势更加凸显。

总结

Emissary-ingress 的特点在于使用简单易于接入,但是二次开发的难度较高。对于更多的功能需求,需要通过接入平台的相关组件来获取支持。

相比之下,APISIX Ingress 在可扩展性和服务发现集成方面具有优势,扩展性强且开发简单。此外,APISIX Ingress 的性能表现出色,特别是在业务规模不断增长的场景中具有明显优势。

微信咨询

获取方案