Overview of Apache APISIX Ingress and Its Features
This article provides a comprehensive overview of Apache APISIX Ingress, explaining its architecture, comparison with Kubernetes Ingress Nginx, detailed feature set, custom resource definitions, practical deployment scenarios such as traffic splitting and authentication, and future roadmap within the cloud‑native ecosystem.
In the Kubernetes ecosystem, an Ingress resource defines traffic entry points, which require an Ingress Controller to interpret and route traffic. While the widely used Kubernetes Ingress Nginx implements this, Apache APISIX Ingress uses Apache APISIX as the data plane to handle actual business traffic.
APISIX Ingress consists of two parts: the APISIX Ingress Controller (control plane) that manages configuration distribution, and the APISIX Proxy Pod (data plane) that processes traffic, implemented via Custom Resource Definitions (CRDs). It supports both custom resources and native Kubernetes Ingress resources.
Compared with Kubernetes Ingress Nginx, APISIX Ingress offers richer configuration options (e.g., single-file gray deployment), a more extensive plugin ecosystem, and a separated control‑plane/data‑plane architecture that allows flexible deployment and easier scaling.
Key features of APISIX Ingress include CRD support, advanced routing rules, over 50 built‑in plugins, native Ingress compatibility, traffic splitting, gRPC and TCP proxying, automatic service discovery, and flexible load‑balancing with health checks.
The controller extends functionality through several custom resources:
APISIX Route : defines HTTP (layer‑7) or stream (layer‑4) routing, supporting match criteria, weights, and plugin extensions.
APISIX Upstream : maps to Kubernetes Services, configuring load‑balancing strategies, protocols (HTTP/gRPC), and health checks.
APISIX Consumer : provides authentication options such as BasicAuth and KeyAuth, with credentials stored securely.
APISIX TLS : manages certificates and supports mTLS client authentication.
APISIX Config : includes cluster‑wide settings (e.g., Prometheus, SkyWalking) and plugin configuration aggregation.
Practical deployment can be done via Helm charts, which install Apache APISIX, the Ingress controller, and etcd in a single command.
Example use cases:
Traffic splitting: configure an APISIX Upstream with weighted backends and an APISIX Route to direct 90% of traffic to version v1 and 10% to version v2.
Authentication: create an APISIX Consumer with BasicAuth credentials and attach it to a Route to enforce authentication.
Kubernetes resource extension: use native Ingress resources with the annotation kubernetes.io/ingress.class: apisix and rewrite target annotations to achieve path rewrites.
Future plans include full support for Kubernetes v1.22+ CRD v1, integration with Gateway API, a new architecture that removes the need for etcd, and expanding the community ecosystem.
Apache APISIX itself is a dynamic, high‑performance open‑source API gateway offering load balancing, dynamic upstreams, gray releases, circuit breaking, authentication, and observability, suitable for enterprises handling API and microservice traffic.
For more information, see the Apache APISIX GitHub repository, official website, and documentation.
High Availability Architecture
Official account for High Availability Architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.