Why Is APISIX Ingress a Better Choice than Emissary-ingress?

Background Information

Kubernetes Ingress is an API object that is used to define rules for routing external traffic to internal services in a cluster. An Ingress Controller is commonly used to implement the logic of the Ingress resource and manage these traffic rules centrally.

In practice, enterprise users usually need traffic management functions such as mTLS, retries, rate limiting, and authentication, which the semantics of the Ingress resource cannot fulfill. Therefore, Ingress Controller implementations usually extend functions by adding additional CRDs. The following will provide a detailed comparison of the differences between APISIX Ingress and Emissary-ingress implementations.

What Is Apache APISIX Ingress

Apache APISIX Ingress is an open-source project under the ASF (Apache Software Foundation). Its control plane configures and delivers resources in Kubernetes, while APISIX handles actual business traffic. To improve security, the entire deployment process uses a completely separated data plane and control plane architecture, effectively avoiding the risk of Kubernetes cluster permission leakage caused by attacks on the data plane.

What Is Emissary-ingress

Emissary-ingress is an incubating project of CNCF (Cloud Native Computing Foundation). As the control plane of Envoy proxy, it is responsible for parsing Kubernetes resources, and all traffic is directly processed by Envoy on the data plane. By packaging the control plane and data plane into one container, the whole is easier to access and deploy.

The Difference between APISIX Ingress and Emissary-ingress

In addition to supporting Ingress resources, both APISIX Ingress and Emissary-ingress could support configuration through CRDs and Gateway API to supplement the limitations of Ingress semantics.

The following sections will analyze the differences and advantages between the two from perspectives of basic functionalities, service discovery, and scalability.

Basic Functionalities

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	✓	✓

Common gateway functions include traffic management, load balancing, and authentication. However, it should be noted that Emissary-ingress has relatively limited support for authentication, which only contains Basic Auth and External Auth capabilities.

Service Discovery

In the microservices architecture, applications are usually broken down into multiple microservices that work together to accomplish specific business logic. Since the number of microservice instances constantly changes, a mechanism is needed to help services discover and locate each other.

Service discovery refers to the way microservices are located on the network by obtaining information about service discovery through the service name to determine which instance the request is routed to.

For traditional microservices frameworks, the selection of a registry is often based on specific business requirements. However, migrating an existing service registration and discovery component to a Kubernetes-based DNS service discovery mechanism can entail certain costs in terms of modifications.

On the other hand, if the gateway supports the current service registration and discovery components, there is no need for such modifications, which can result in better support for microservices frameworks.

Here are the support situations of the two for service discovery components:

Service Discovery	Apache APISIX Ingress	Emissary-ingress
Kubernetes	✓	✓
DNS	✓	✓
Nacos	✓	✕
Eureka	✓	✕
Consul	✓	✓

Regarding the service discovery ecosystem, APISIX Ingress has stronger support, and users can easily integrate it into their existing microservices framework through the Ingress controller.

Scalability

When the functionality of the Kubernetes Ingress controller does not meet specific requirements, users can extend its functionality through custom development. More personalized needs can be met by developing custom plugins or modifying existing code. Ingress controllers with robust scalability can make developing and customizing features easier, providing better support and solutions for specific scenarios.

Emissary-ingress

The extensibility of Emissary-ingress is relatively poor, as it does not support extension through the custom Envoy Filter. Since the data plane and control plane are integrated, it requires custom development of the entire system. The complexity of custom development for the data plane Envoy is high and significantly burdens developers.

In addition, if users need a more powerful Emissary-ingress, they need to upgrade it to Ambassador's commercial product Edge Stack. Some proprietary features require payments to obtain support.

APISIX Ingress

The data plane of APISIX mainly extends its functionality via plugins, which provide more than 80 out-of-the-box plugins. APISIX Ingress supports all plugins provided by APISIX, which could satisfy most daily use cases.

If customization is needed based on specific business scenarios, APISIX offers multiple extension options for users to choose and combine according to their situations freely. The currently supported extension methods are as follows:

1. Developing plugins using Lua language is relatively simple and almost without any performance loss. In addition, you can use the serverless plugin to write Lua code directly, which can quickly meet business requirements.
2. In addition to the native Lua language, you can also use Plugin Runner or WASM plugins for extension, which supports developing custom plugins in coding languages such as Java, Python, and Go. This enables users to utilize their existing business logic and select based on their company's technology stack or development preferences without requiring a new language.

APISIX Ingress fully supports the above extension methods without any additional developments.

Performance

As a Kubernetes ingress traffic proxy component, it manages all incoming platform traffic and uniformly manages various traffic rules, placing higher demands on the proxy's performance.

In this article, we will do performance tests on APISIX Ingress (APISIX: 3.1.0) and Emissary-ingress 3.4.0 in the same instance (4C 8G).

QPS

QPS (Queries-per-second) stands for the number of queries a service can handle per second. The higher the number, the better the performance.

• 5000 Ingress Resource QPS

Latency

Response latency: the time it takes for the server to respond. The smaller the delay, the better the performance.

The graph shows that APISIX Ingress maintains consistent performance across different resource scales, demonstrating a well-balanced performance.

On the other hand, Emissary-ingress significantly impacts QPS and latency when dealing with large resource scales and different routing matches, with performance decreasing as resource numbers increase. Therefore, as business volume grows in actual production environments, APISIX's high-performance becomes more prominent.

Conclusion

Emissary-ingress is characterized by simplicity and ease of integration, but more difficult for custom development. Moreover, additional feature requirements rely on the platform's related components for support.

In comparison, APISIX Ingress has advantages in scalability and service discovery integration, with strong extensibility and simple development. Additionally, APISIX Ingress performs exceptionally well, particularly in scenarios where the business scale continues to grow, showing significant advantages.