Ingress Controller
Compare API7 Ingress Controller and APISIX Ingress Controller, then find installation, how-to, troubleshooting, and reference documentation for routing traffic with Ingress, Gateway API, and APISIX CRDs.
Applies to:API7 Ingress Controller (drives API7 Gateway)APISIX Ingress Controller (drives Apache APISIX)
Quick links
Get started
Set Up Ingress Controller and Gateway, proxy requests to a service, Common Use Cases
Deploy and operate
Upgrade, High Availability, Gateway API Access Control, Cross-Namespace, OpenShift, GitOps, Canary Releases
Manage traffic and APIs
Traffic Management, Custom Plugins
Reference
Compatibility, Configuration File, Ingress and Gateway API Support, CRD Reference, Annotations, Helm Charts
Releases and support
Release Notes, Common Issues, Configuration Synchronization, Debug Mode, Admission Webhook
Which one am I using?
API7 Ingress Controller and APISIX Ingress Controller are two separately maintained, separately built controllers that share one set of custom resources and the same Gateway API version. Which one you run is decided by the gateway you run.
| API7 Ingress Controller | APISIX Ingress Controller | |
|---|---|---|
| Target gateway | API7 Gateway, configured through the API7 Control Plane (API7 Dashboard) | Apache APISIX, in standalone (API-driven) or traditional (etcd) mode |
| Source repository | github.com/api7/api7-ingress-controller | github.com/apache/apisix-ingress-controller |
| Container image | api7/api7-ingress-controller | apache/apisix-ingress-controller |
| Helm chart and repository | api7/api7-ingress-controller from https://charts.api7.ai | apisix/apisix-ingress-controller from https://apache.github.io/apisix-helm-chart, or embedded in the apisix/apisix chart |
provider.type | api7ee (the chart default) | apisix (the chart default) or apisix-standalone |
controller_name | apisix.apache.org/apisix-ingress-controller by default; the install examples in this section set api7.ai/api7-ingress-controller | apisix.apache.org/apisix-ingress-controller by default |
| Current release | 2.2.1, with chart 0.1.28 | 2.2.0, with chart 1.3.1 |
| Product-specific capabilities | Configures every plugin available in API7 Enterprise, including limit-count-advanced and graphql-limit-count; custom Wasm plugins are not supported | Configures every plugin available in Apache APISIX, including custom Wasm plugins and the filter_func matcher |
| Where to report a problem | support@api7.ai, or the issues of github.com/api7/api7-ingress-controller; the support tier is to be confirmed | The issues of github.com/apache/apisix-ingress-controller, an Apache Software Foundation project |
Both controllers translate Kubernetes resources such as Ingress, Gateway API, and APISIX custom resources into synchronized gateway configuration. This lets platform teams manage routing, upstreams, TLS, plugins, and other gateway behavior through declarative Kubernetes manifests. It is a good fit when the gateway runs in Kubernetes and routing and gateway policies should follow the same declarative workflow as the workloads they serve.
This documentation is intentionally shared by API7 Ingress Controller (API7 IC) and APISIX Ingress Controller (APISIX IC). Some shared Kubernetes resource identifiers retain APISIX naming, including the apisix.apache.org API group and the k8s.apisix.apache.org annotation prefix, and are supported by both controllers. Unless a page identifies a product-specific difference, its resource workflows apply to both controllers, and every page states which controllers it applies to under its description.
This maintained documentation version covers API7 Ingress Controller 2.2.1. It also covers APISIX Ingress Controller 2.2.0 while the corresponding APISIX patch release is pending. Fields whose release timing differs are identified where they appear. For the version, chart, image, and Kubernetes compatibility details, see Compatibility.
Supported resources
Both controllers support the following Kubernetes resources:
- Gateway API 1.6 is a modern, extensible Kubernetes-native API for traffic management. The controllers support multiple listeners, HTTP, gRPC, TCP, UDP, and TLS routes, downstream mTLS, and richer traffic policies. See Ingress and Gateway API Support for field-level support.
- Ingress is the legacy Kubernetes-native API for basic HTTP/S routing to backend services. It does not support all advanced configurations available in Gateway API or APISIX CRDs.
- APISIX CRDs provide fine-grained control over routing, plugins, upstreams, and other gateway features.
L4RoutePolicyattaches stream plugins to Gateway API TCP, UDP, and TLS routes.
Resources supported by the installed controller can coexist within the same Kubernetes cluster. Confirm that the installed product release supports a resource or field before applying its manifest. Some features are available only through specific resource types, so avoid configuration conflicts when using multiple resources together.
The diagram below illustrates how both controllers combine standard Gateway API resources with custom resources to define routing, traffic policies, and gateway behavior within a Kubernetes environment:
How the controllers process Kubernetes resources
Both controllers translate Ingress, Gateway API, and APISIX CRD resources into internal ADC (opens in Apache APISIX docs) YAML, then synchronize that configuration to the gateway. ADC is maintained by API7 and is run as a sidecar container by both controllers.
APISIX Ingress Controller vs API7 Ingress Controller
The two controllers are built from two separately maintained source repositories and are published as two separate container images and two separate Helm charts. They use the same Kubernetes resource APIs — the same apisix.apache.org custom resources and the same Gateway API version — and share many of the capabilities described in this documentation, so teams can reuse Gateway API, Ingress, and APISIX custom resource patterns across API7 Enterprise and APISIX deployments. Since 2.1.0 the two projects also publish aligned release numbers; a release number is not a shared build.
The installed controller release determines which resources and fields are available. Product-specific behavior and defaults, as well as deployment-specific values such as namespaces, upstream services, and GatewayProxy connection settings, may differ. The deployment architectures also differ in how each controller connects to its respective gateway.
Deployment architectures
The architectural diagrams below use a single-controller topology to illustrate the different deployment modes of API7 and APISIX Ingress Controller.
API7 Ingress Controller
API7 Ingress Controller supports a single deployment mode, in which the controller communicates directly with the API7 control plane (API7 Dashboard).
APISIX Ingress Controller
APISIX Ingress Controller supports two deployment modes: standalone and traditional.
Standalone mode
The standalone mode is recommended over the traditional mode (with etcd). It is designed to address the stability issues that can arise when running APISIX and etcd inside Kubernetes.
Traditional mode
In the traditional deployment mode, APISIX uses etcd as its configuration center.
