For most of the last decade, Ingress NGINX has been the default Kubernetes ingress controller. It is widely deployed, well-understood, and free. Kubernetes survey data has consistently put it at or near the top of the most-used ingress controllers in production clusters.
That position changed on March 24, 2026, when Ingress NGINX was archived at KubeCon Europe. The repository will not receive further security patches, which means anyone running it as the front door to their cluster is now operating an unmaintained TLS endpoint. Operators have limited options. Pick another Ingress controller and stay on the frozen Ingress API, or move forward to the Kubernetes Gateway API, the standard and successor of Ingress API recommended by the Kubernetes project itself.
This article is about the second path, using Airlock Microgateway as the Gateway API implementation, with a brief highlight of the benefits and a concrete walkthrough of what changes and what tools help.
Why move to the Gateway API?
Three reasons make the Gateway API a real upgrade rather than a rebranding of Ingress API.
Role-oriented
Its main advantage is structural, not functional. Gateway API splits routing into three typed resources, each owned by a different role:
- GatewayClass: Owned by the infrastructure provider, the team that installs and operates the Gateway API implementation in the Kubernetes cluster. Describes the kind of gateway the cluster supports.
- Gateway: Owned by the cluster operator. The concrete listener configuration that decides which ports are exposed, which TLS certificates terminate traffic, and which hostnames are accepted.
- HTTPRoute: Owned by the application developer. Defines how traffic is routed to a specific application through a Gateway listener. Application developers can also configure Microgateway security policies for these routes.
Fields in Gateway API resources are validated at admission time, and the boundaries between roles are enforced by RBAC. Unlike the annotations used in Ingress NGINX, where a typo only surfaces hours later in the Kubernetes cluster, a misconfigured field is caught the moment you run kubectl apply.
Vendor-agnostic
Gateway API is a Kubernetes specification, not a controller-specific configuration model. Conformance tests verify that different implementations expose the same API semantics and behave the same way for the supported feature sets. So, moving from one conformant implementation to another can start with a change of gatewayClassName while the other resources stay untouched. The Gateway API specification is shaped by a working group with contributors from many organizations and product teams. This means each resource was reviewed from many angles before it became part of the standard, and the resulting design is more mature than what any single project would have produced on its own.
Ecosystem
Because Gateway API is a standard, new tools have emerged and existing tools have extended their capabilities to support it, without requiring vendor-specific workflows. The same day-to-day tooling you already use for Kubernetes now applies to Gateway API as well. Examples include:
- ingress2gateway: A conversion tool to translate Ingress API and provider-specific resources (CRDs) to Gateway API resources.
- gwctl: A command-line tool for managing and understanding Gateway API resources.
- Headlamp: A user-friendly Kubernetes UI focused on extensibility which also provides a Gateway API plugin.
- cert-manager: A cloud native certificate management tool with native Gateway API support since 2024.
- ArgoCD, FluxCD, Kyverno, OPA, and others: Many other tools have also extended their capabilities for Gateway API and are worth looking into.
The combined benefit of the ecosystem and vendor-agnostic configuration is significant. Your resources are portable across Gateway API implementations, and the surrounding tools keep your workflow portable as well.
The general conversion workflow
The migration happens in three steps and uses ingress2gateway to simplify this process.
Note: If you use Homebrew, brew install ingress2gateway is the quickest installation method on macOS and Linux. For other platforms and installation methods, see the official installation guide.
1. Convert the Ingress API resources
Retrieve the Ingress API resource from your cluster and convert it to Gateway API resources:
kubectl get ingress <MY-INGRESS-RESOURCE> -o yaml | \
ingress2gateway print \
--providers=ingress-nginx \
> gateway-api-resources.yamlThis example shows the basic conversion flow. Run ingress2gateway help to see additional commands and conversion options. The tool emits a warning for every annotation or field it could not translate to standard Gateway API resources. Review each warning before applying the generated resources.
2. Deploy and verify
It is highly recommended to run kubectl apply --dry-run=client before applying the resources to your cluster. This lets you catch and correct errors before they reach the API server.
After applying the resources, use gwctl get gateway and gwctl get httproute to check the status of your Gateway API resources. Look for Programmed: True on the Gateway, and Accepted: True and Resolved: True on each HTTPRoute. If anything is off, use gwctl describe on the affected resource to inspect its conditions and listener-specific status.
3. Test
Finally, test the migrated traffic path end to end before cutting over production traffic. Use gwctl get gateway <GATEWAY-NAME> to retrieve the Gateway address, then send test requests to that address with the expected Host header.
curl -H 'Host: <hostname>' https://<gateway-address>/<path>Compare the responses with the existing Ingress or current production endpoint. When the behavior matches, update DNS or your traffic routing configuration to point to the Gateway address. After the cutover is complete and verified, remove the old Ingress resources.
Ingress to Gateway API migration example
The following Ingress configuration is used as an example to show how a migration to Gateway API can work. It defines an Ingress for the FQDN app.company.com, terminates TLS at the edge, redirects HTTP traffic to HTTPS, and exposes two services, foo-svc under /foo and bar-svc under /bar. The illustration below shows the shape of this setup.
The corresponding Ingress NGINX configuration is stored in example-ingress.yaml and looks like this:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example
spec:
ingressClassName: nginx
tls:
- hosts:
- app.company.com
secretName: app-company-com-tls
rules:
- host: app.company.com
http:
paths:
- path: /foo
pathType: Prefix
backend:
service:
name: foo-svc
port:
number: 80
- path: /bar
pathType: Prefix
backend:
service:
name: bar-svc
port:
number: 80Install the CRDs and Airlock Microgateway
To test the migrated configuration, the cluster needs the Gateway API CRDs and a conformant Gateway API implementation such as Airlock Microgateway. The Gateway API CRDs define the standard resources such as GatewayClass, Gateway, and HTTPRoute. Airlock Microgatway is the controller that watches these resources and configures the actual data plane.
1. Install the Gateway API CRDs
Deploy the Gateway API CRDs in your cluster.
kubectl apply --server-side \
-f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.0/standard-install.yaml2. Install a conformant Gateway API implementation
This walkthrough uses Airlock Microgateway.
helm install airlock-microgateway \
oci://quay.io/airlockcharts/microgateway \
--version 5.1.0 \
--namespace airlock-microgateway-system \
--create-namespace \
--waitConvert the Ingress API resources
The conversion process is split into two steps. First, ingress2gateway converts the existing Ingress manifest into Gateway API resources. Then, review the generated configuration to understand how the original Ingress concepts map to Gateway and HTTPRoute resources.
1. Convert the Ingress configuration
Convert the Ingress NGINX configuration shown above, stored in example-ingress.yaml, into Gateway API resources and write the result to example-gateway-api.yaml:
ingress2gateway print \
--providers=ingress-nginx \
--input-file example-ingress.yaml \
> example-gateway-api.yamlThe tool prints a warning for every annotation or field it could not translate to a standard Gateway API resource. Review these carefully before proceeding. Each warning requires a manual decision.
Example output:
┌─ WARN ────────────────────────────────────────
│ Gateway API does not support configuring URL normalization (RFC 3986, Section 6). Please check if this matters for your use case and consult implementation-specific details.
│ source: STANDARD_EMITTER
└─2. Review the generated Gateway API configuration
The generated Gateway and two HTTPRoute resources look roughly like this, with gatewayClassName set to Airlock Microgateway.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
annotations:
gateway.networking.k8s.io/generator: ingress2gateway-1.1.0
name: my-ingress
spec:
gatewayClassName: airlock-microgateway
listeners:
- hostname: app.company.com
name: app-company-com-http
port: 80
protocol: HTTP
- hostname: app.company.com
name: app-company-com-https
port: 443
protocol: HTTPS
tls:
certificateRefs:
- group: ""
kind: Secret
name: app-company-com-tls
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
annotations:
gateway.networking.k8s.io/generator: ingress2gateway-1.1.0
name: example-app-company-com
spec:
hostnames:
- app.company.com
parentRefs:
- name: my-ingress
port: 443
sectionName: app-company-com-https
rules:
- backendRefs:
- name: foo-svc
port: 80
matches:
- path:
type: PathPrefix
value: /foo
- backendRefs:
- name: bar-svc
port: 80
matches:
- path:
type: PathPrefix
value: /bar
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
annotations:
gateway.networking.k8s.io/generator: ingress2gateway-1.1.0
name: example-app-company-com-http
spec:
hostnames:
- app.company.com
parentRefs:
- name: my-ingress
port: 80
rules:
- filters:
- requestRedirect:
scheme: https
statusCode: 308
type: RequestRedirect
matches:
- path:
type: PathPrefix
value: /foo
- filters:
- requestRedirect:
scheme: https
statusCode: 308
type: RequestRedirect
matches:
- path:
type: PathPrefix
value: /barThe following illustration shows the generated Gateway API configuration and how requests flow through the Gateway and HTTPRoute resources:
The Ingress tls block becomes a certificateRefs entry on the HTTPS listener. The two path rules become matches on a single HTTPRoute attached to that listener. The HTTP-to-HTTPS redirect becomes a second HTTPRoute attached to the HTTP listener with a RequestRedirect filter.
Deploy and verify
Deployment and verification are split into two steps. First, apply the generated Gateway API resources to the cluster. Then, verify that the Gateway and HTTPRoutes are accepted and ready to serve traffic.
1. Apply the Gateway API resources
It is recommended to run a dry-run before applying the resources to your cluster. This lets you catch and correct errors before they reach the API server.
kubectl apply --dry-run=client -f example-gateway-api.yamlIf the dry-run passes, apply the generated Gateway API resources:
kubectl apply -f example-gateway-api.yamlDuring the migration, the Gateway API resources can run in parallel with the existing Ingress NGINX if they do not compete for the same external address and port combination.
2. Verify the status
After applying the resources, use gwctl get gateway and gwctl get httproute to check their status:
gwctl get gateway my-ingress -o wide
gwctl get httproute example-app-company-com -o wide
gwctl get httproute example-app-company-com-http -o wideLook for Programmed: True on the Gateway, and Accepted: True plus Resolved: True on each HTTPRoute. If anything is off, use gwctl describe on the affected resource to inspect its conditions and listener-specific status.
Test connectivity
Finally, test the migrated traffic path end-to-end before switching production traffic. Use gwctl get gateway my-ingress to retrieve the Gateway address, then send test requests to that address with the expected Host header.
curl -H 'Host: app.company.com' https://<GATEWAY_ADDRESS>/foo
curl -H 'Host: app.company.com' https://<GATEWAY_ADDRESS>/barCompare the responses with the existing Ingress or current production endpoint. When the behavior matches, update DNS for app.company.com or your traffic routing configuration to point to the Gateway address. After the cutover is complete and verified, remove the old Ingress resources.
Picking an implementation: Airlock Microgateway
While conformant Gateway API implementations are interchangeable on standard resources, vendors differentiate through extra capabilities. Key differences typically lie in platform integration, observability, operational tooling, software supply chain, support model, and advanced capabilities beyond traffic routing.
Airlock Microgateway combines a conformant Gateway API implementation with Kubernetes-native Web Application and API Protection (WAAP) and identity-aware access control. In addition to routing, it can protect web applications and APIs, validate identities and tokens, enforce access policies, and provide security telemetry. Configuration is declarative and integrates with existing GitOps and DevSecOps workflows.
This makes Airlock Microgateway particularly suitable for teams that do not only want to replace Ingress NGINX, but also want to integrate application and API security directly into their Kubernetes architecture.
Key capabilities include:
- Kubernetes-native integration: Airlock Microgateway runs directly in Kubernetes and uses the Gateway API as the configuration standard for traffic routing. Its Operator and Custom Resource Definitions integrate with established GitOps and DevSecOps workflows.
- Observability: ECS-formatted logs, Prometheus metrics, Grafana dashboards, and OpenTelemetry-based tracing provide visibility into traffic and Gateway behavior.
- Secure software supply chain: Airlock Microgateway container images are signed with Cosign and can be verified before deployment.
- Application and API protection: Beyond Gateway API routing, Airlock Microgateway provides Web Application and API Protection (WAAP), including protection against OWASP Top 10 attacks, OpenAPI specification enforcement, GraphQL schema validation, and request rate limiting.
- Identity-aware access control: OpenID Connect, JWT, OAuth 2.0 Token Exchange, and client certificate-based authentication allow access decisions to be enforced before requests reach the application.
- Transport security: Airlock Microgateway supports TLS protection including hybrid post-quantum key exchange with TLS 1.3.
Ready to test Airlock Microgateway?
Explore Airlock Microgateway at your own pace with our license-free Community Edition, or unlock advanced security features with a free Evaluation License.
