Migrate from NGINX Ingress to Envoy Gateway

Available as of MKE 3.9.0 Mirantis Kubernetes Engine (MKE) includes the Envoy Gateway controller, which implements the Kubernetes Gateway API. Gateway API is the successor to the Ingress API, which is the path that Mirantis recommends for new and migrated ingress traffic.

Attention

The NGINX Ingress Controller provided by MKE reached End of Life (EOL) status on 2026-APR-01. It is highly recommended that you migrate from NGINX Ingress Controller to Envoy Gateway controller before Mirantis support for the NGINX Ingress Controller ends on 2026-DEC-31. Plan your migration before support ends.

You can run NGINX Ingress and Envoy Gateway in the same cluster at the same time. Each controller exposes traffic through its own load balancer service, so they typically receive different external addresses. This allows you to:

Translate and test Gateway API resources without having to change production Ingress.
Compare behavior on an application-by-application basis.
Roll back quickly, by keeping DNS or the load balancer pointed at NGINX.

Only once you have validated Envoy Gateway for an application should you remove its Ingress resources. Disable the NGINX Ingress Controller only once there is nothing that relies on it.

Ingress controller high-level mapping

The following table maps common NGINX Ingress Conroller concepts to their Envoy Gateway equivalents.

NGINX Ingress	Envoy Gateway
Ingress rules (host/path)	HTTPRoute `hostnames` / `matches`
`spec.tls`	Gateway listener `tls` + secrets
`ingressClassName`	`Gateway.spec.gatewayClassName` (use `mke-gateway-ingress`)
NGINX annotations	HTTPRoute filters, Gateway API fields, or Envoy Gateway policies / extensions
Single Ingress resource	Gateway plus one or more `HTTPRoutes`

Migration approach

For migrating to Envoy Gateway from NGINX Ingress, Mirantis recommends the following approach:

Step	Direction	Detail
1	Inventory ingress per application.	For each application or team, list the ingress resources, hostnames, TLS secrets, and NGINX-specific annotations. Note which behaviors are required in production.
2	Enable Envoy Gateway Controller.	You can enable the Envoy Gateway Controller through the MKE configuration file or through the MKE web UI.
3	Plan per application.	For each application: Set target Gateway listeners Define HTTPRoute rules and backends Define gaps where annotations do not map cleanly to Gateway API Determine whether you plan to test as a non-production cluster or a parallel entry point.
4	Create Gateway API resources.	Draft Gateway and HTTPRoute manifests for each application from your inventory and plan. Unsupported snippets and many NGINX annotations require manual follow-up.
5	Adjust for MKE.	Set `gatewayClassName: mke-gateway-ingress` on Gateway resources. Align namespaces, TLS secrets, and parentRefs with your platform standards.
6	Deploy and verify in isolation.	Apply Gateway/HTTPRoute resources for one application. Reach the new entry point – separate hostname, DNS weighting, or test LB – and verify routing, redirects, path behavior, TLS, timeouts, body size, WebSockets/long-lived connections if applicable, and observability.
7	Shift traffic gradually.	Move production traffic per application; DNS, external LB, or traffic split. Keep NGINX Ingress in place until the application is stable on Gateway API.
8	Decommission Ingress for each affected application.	Delete the Ingress resources. Once none of your workloads are using NGINX Ingress, disable `cluster_config.ingress_controller`.