By Ru Man
In November 2025, the Kubernetes community announced that as the most mainstream Ingress controller, Ingress Nginx will officially stop maintenance in March 2026. For users currently using Ingress Nginx, it is time to consider the next step.
The Kubernetes Official gave two suggestions:
Cloud Native API Gateway (APIG) covers both paths: it provides a complete Ingress migration solution and long-term support, and fully supports the Gateway API standard. This article focuses on Gateway API—what it is, why it is worth attention, and how to get started quickly on Cloud Native API Gateway.
Let's review the background first. As the earliest traffic ingress specification for Kubernetes, Ingress has accompanied the community for nearly ten years. Its advantages are obvious: simple concept, mature ecosystem, and supported by almost all gateway products.
But as enterprise containerization deepens, the limitations of Ingress are becoming more and more obvious:
Simply put, Ingress does a good job of being "good enough," but it is no longer capable of dealing with increasingly complex traffic governance needs.
The Gateway API was born precisely to solve these pain points. It is designed under the leadership of the Kubernetes SIG-Network, made its official GA in late 2023, and has become the community-recognized successor to Ingress.
The Gateway API splits the responsibilities originally undertaken by one Ingress resource into three layers:
| Resource | Responsibility | Responsible Role |
|---|---|---|
| GatewayClass | Define gateway implementation type | Platform Administrator |
| Gateway | Declare gateway instances, listening ports, and domain names | Cluster Operator |
| HTTPRoute | Define specific routing rules and traffic policies | Application Developer |
This layered design naturally supports collaboration among multiple roles—operations team manages the gateway, development team manages routing, without nose-poking into each other's domain.
Compared to Ingress, Gateway API natively supports the following capabilities, without any custom annotations:
Gateway API, through Policy Attachment and CRD extension mechanisms, endows the protocol itself with flexible extensibility—while the core routing standards remain unchanged, new resources and capabilities can be freely extended according to scenarios.
A classic example is Gateway API Inference Extension (GIE). As massive LLM inference services are deployed into Kubernetes clusters, the community extended this set of protocols based on Gateway API, specifically to solve smart routing problems under inference scenarios. It introduces new resources like InferencePool, enabling the gateway to sense the running status of inference nodes—including indicators like request queue depth, KV Cache hit rate, and so on—thereby achieving smart scheduling and load balancing among multiple inference nodes. It can be foreseen that more vertical scenarios will grow their own extension standards based on Gateway API in the future.
Cloud Native API Gateway has started supporting Gateway API since version 2.1.16, currently supporting up to version v1.3.0, and will keep up with subsequent adaptations to newer versions. For services deployed on Alibaba Cloud ACK, you can directly use the Gateway API approach to let Cloud Native API Gateway serve as the traffic ingress of the cluster, replacing Ingress Nginx to bear the responsibility of north-south routing.
In addition to supporting Gateway API itself, the advantages of Cloud Native API Gateway also lie in:
1. Dual-mode parallel, smooth transition
Cloud Native API Gateway supports the coexistence of dual stacks of Ingress and Gateway API, incremental business can continue using Ingress, while new business can directly use Gateway API, without interfering with each other and progressing as needed.
2. Perfect Ingress Migration Tools
For users migrating out from Ingress Nginx, Cloud Native API Gateway provides a complete migration solution, compatible with mainstream Nginx Ingress annotations, supporting canary traffic switching and one-key rollback, to ensure safe and controllable migration.
3. Console Visualization + Declarative Management on Container Side
Gateway API resources are declaratively managed through kubectl on the container side, while visible on the gateway console in real-time. The operations team can view the global routing status on the console at a single glance, and the development team can independently manage routing rules in YAML, each gets what they need.
4. Based on Higress Open Source Ecosystem
Cloud Native API Gateway is built on the CNCF open-source project Higress, whose core capabilities have been validated in large-scale production, backed by an active open-source community that continuously evolves.
Next, through a complete hands-on example, we will demonstrate step-by-step how to expose services using Gateway API on Cloud Native API Gateway.
If using Alibaba Cloud ACK, it is recommended to directly install Gateway API CRD with one-key through Component Management, saving manual operations.
1. Log in to the Cloud Native API Gateway Console and enter the target gateway instance
2. Click Create API on the API page, and select Import Gateway API
3. Fill in the API name, select the ACK source cluster, and configure the listening namespace and GatewayClass as needed
4. Click OK, the API of Gateway API type will be created, and Gateway API listening is enabled at the same time. You can click and enter the corresponding API to view specific routing details.
Deploy a simple httpbin application in the ACK cluster as a backend service:
apiVersion: apps/v1
kind: Deployment
metadata:
name: httpbin
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: httpbin
template:
metadata:
labels:
app: httpbin
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/mse-ingress/go-httpbin
args: ["--port=8080", "--version=v1"]
name: httpbin
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: httpbin
namespace: default
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 8080
selector:
app: httpbinkubectl apply -f httpbin.yamlapiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: apig
spec:
controllerName: higress.io/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: apig-gateway
namespace: default
spec:
gatewayClassName: apig
listeners:
- name: http
protocol: HTTP
port: 80
hostname: "*.example.com"
allowedRoutes:
namespaces:
from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: httpbin-route
namespace: default
spec:
parentRefs:
- name: apig-gateway
hostnames:
- "demo.example.com"
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- kind: Service
name: httpbin
port: 80kubectl apply -f gateway.yamlWait for about 2 minutes, and confirm the Gateway is ready:
kubectl get gateway apig-gateway
# NAME CLASS ADDRESS PROGRAMMED AGE
# apig-gateway apig nlb-xxxx True 2mThe PROGRAMMED status is True, indicating the Gateway has been configured successfully.
After acquiring the gateway access point address, execute:
curl -H "Host: demo.example.com" http://<Gateway Access Point>/versionSeeing the following output indicates that the Gateway API routing has taken effect:
version: v1
hostname: httpbin-5d4f8b6c7f-xxxxxUp to this point, you have implemented routing from Cloud Native API Gateway to services in containers through the Gateway API, and external traffic can normally access applications in the cluster.
In addition to basic routing, Gateway API also supports rich advanced scenarios like request header modification, weight-based traffic splitting, header-based canary routing, and more. For more practical cases, please refer to Expose services with Gateway API via Cloud Native API Gateway.
The retirement of Ingress Nginx is not the end, but a new starting point for container networking towards standardization. As the next-generation routing standard of the Kubernetes community, Gateway API already possesses the complete capability to replace Ingress.
While representing full support for Gateway API, Cloud Native API Gateway provides long-term compatibility and migration tools for Ingress, allowing you to calmly cope with this change—whether you want to embrace the new standards, or steady existing business first before gradually evolving, there is a suitable path for you.
If you are looking for an alternative to Ingress Nginx, or want to introduce more modern container routing capabilities for your team, try starting with Gateway API: with one Gateway + one HTTPRoute, you can complete your first practice within 10 minutes.
For more details, please refer to the practical tutorials in Cloud Native API Gateway official documentation: Exposing Services Using Gateway API through Cloud-Native API Gateway.
From an 18-Year-Old Hidden Nginx Vulnerability to the Evolution of Gateway Security Architecture
721 posts | 58 followers
FollowAlibaba Container Service - June 13, 2024
Alibaba Cloud Indonesia - February 13, 2026
Alibaba Cloud Native Community - September 12, 2023
Alibaba Cloud Community - May 7, 2025
Alibaba Cloud Native Community - May 22, 2025
Alibaba Cloud Native - September 4, 2023
721 posts | 58 followers
Follow
Container Service for Kubernetes
Alibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.
Learn More
ACK One
Provides a control plane to allow users to manage Kubernetes clusters that run based on different infrastructure resources
Learn More
API Gateway
API Gateway provides you with high-performance and high-availability API hosting services to deploy and release your APIs on Alibaba Cloud products.
Learn More
Cloud-Native Applications Management Solution
Accelerate and secure the development, deployment, and management of containerized applications cost-effectively.
Learn MoreMore Posts by Alibaba Cloud Native Community