This Member Blog was originally published on the Isovalent blog and is republished here with permission.
If you’re running Kubernetes, there’s a good chance you rely on ingress-nginx to route external traffic to your workloads. For years, ingress-nginx has been the go-to open source ingress controller, valued for its reliability and broad community support. Data collected from a recent State of Kubernetes Networking Report shows that 50% of respondents use Ingress-nginx today. But that’s about to change.
Archival of Ingress-nginx: What Does This Mean for You?
The maintainers of ingress-nginx have announced that the project is being archived at the start of 2026. This means it will no longer receive active maintenance, security patches, or bug fixes. The news, unveiled during KubeCon, marks a significant turning point for thousands of Kubernetes users and organizations that have built their ingress strategy around it.
What Are Your Options?
With ingress-nginx entering retirement, platform teams face a choice: keep a critical control-plane component without upstream maintenance, or move to an actively supported alternative.
The Kubernetes community has aligned on the Gateway API as the long-term standard for traffic management. That direction shapes your two primary migration paths:
- Move to another ingress controller (such as Cilium Ingress, Traefik, or HAProxy Ingress).
- Adopt the Kubernetes Gateway API, the next-generation standard for ingress and traffic management, using a controller like Cilium Gateway API.
Cilium offers both. You can start with Cilium Ingress for a drop-in replacement and later transition to the Gateway API without switching vendors, controllers, or datapaths.
Option 1 – Quickest: Moving to Cilium Ingress
Cilium Ingress is a drop-in ingress controller that supports standard Kubernetes Ingress resources. It runs on Cilium’s eBPF-powered datapath, which provides excellent performance, deep visibility, and seamless integration with Cilium Network Policies.
Why Teams Choose This Path
- Minimal changes to application manifests and CI/CD pipelines.
- Continuity in using an actively maintained product and a clean path away from NGINX-specific annotations.
- Built-in observability and stronger security through Cilium’s tooling.
What to Watch Out For
- NGINX-only annotations and custom directives will not translate directly.
- If you rely on complex rewrites or advanced NGINX behaviours, plan a validation phase to map those features to Cilium equivalents, or consider the Gateway API for richer routing capabilities.
How to Migrate from ingress-nginx to Cilium Ingress:
1. Inventory current Ingress usage: Record hosts, paths, TLS settings, annotations, rewrite rules, and rate limits.
2. Install or verify Cilium: Follow the Cilium Getting Started guide
3. Enable Cilium Ingress: See Cilium Ingress documentation.
4. Update manifests to target Cilium’s ingress class: Switch ingressClassName to cilium and remove NGINX-specific annotations where appropriate.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app
namespace: apps
spec:
ingressClassName: cilium
rules:
- host: my-app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-app-svc
port:
number: 80
5. Validate and cut over: Test TLS, path routing, and network policies in staging before switching production traffic.
Option 2 – Recommended: Upgrading to Cilium’s Gateway API Implementation
While switching to Cilium Ingress is the fastest way to move off ingress-nginx, the Kubernetes ecosystem is shifting towards the Gateway API.
A subproject of SIG-Network, Gateway API is the successor to Ingress, covering not just north-south traffic but also east-west and service-mesh entry points through a consistent, extensible model.
Cilium’s implementation supports all Core Gateway API resources and features, in addition to most Extended (or optional) features, and enhances them with eBPF-powered performance, observability, and policy integration.
Why Choose Cilium’s Gateway API Implementation?
Cilium’s Gateway API implementation isn’t just a replacement; it’s an upgrade that brings a host of benefits, from enhanced traffic control to streamlined operations.
- Advanced traffic management: Native support for header-based routing, traffic splitting, and cross-namespace routes.
- Unified traffic management (GAMMA): Leverage a single, consistent API (Gateway API) to manage both external (north-south) ingress traffic and internal (east-west) service mesh traffic, simplifying operations and policy enforcement.
- Role separation: Decouple infrastructure from application routing for better security and multi-tenancy.
- Rich policy integration: Combine L7 routing with Cilium Network Policies and Hubble observability.
- Future alignment: Gateway API is the endorsed standard by Kubernetes SIG-Network and major cloud providers.
What Are the Key Features Over Ingress?
While Ingress has served us well, its design inherently limits advanced traffic management. The Gateway API, especially with Cilium’s implementation, unlocks a new level of control and flexibility. This table highlights some key areas where Gateway API goes beyond what traditional Ingress can offer, providing more robust and granular control over your traffic flows.
| Feature | Ingress-nginx | Cilium Ingress | Cilium Gateway API |
| Basic HTTP routing | ✔️ | ✔️ | ✔️ |
| Path-based routing | ✔️ | ✔️ | ✔️ |
| Header-based routing | ❌ | ❌ | ✔️ |
| Traffic splitting | ❌ | ❌ | ✔️ |
| Cross-namespace support | ❌ | ❌ | ✔️ |
| East-West Traffic Management (GAMMA) | ❌ | ❌ | ✔️ |
| Role/resource separation | ❌ | ❌ | ✔️ |
| Enhanced observability | ❌ | ✔️ | ✔️ |
| Advanced security policies | ❌ | ✔️ | ✔️ |
Migrating to Cilium’s Gateway API Implementation:
- Ensure Cilium is installed and configured for Gateway API: Cilium Gateway API Docs
- Install Gateway API CRDs: If your Kubernetes distribution does not ship with Gateway API, install CRDs as per the Gateway API Installation Guide.
- Define GatewayClass and Gateway resources: This is a simple example, but you can find more detailed examples in this tutorial blog post for Gateway API:
apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
name: cilium
spec:
controllerName: io.cilium/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: my-gateway
namespace: default
spec:
gatewayClassName: cilium
listeners:
- name: http
protocol: HTTP
port: 80
4. Translate Ingress rules into HTTPRoute objects: The new model offered by Gateway API allows Application teams to define routes and backends, optionally with cross-namespace references. Removing this task from the responsibility of the platform owner.
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: my-app
namespace: apps
spec:
parentRefs:
- name: shared-gw
namespace: infra
rules:
- matches:
- path:
type: PathPrefix
value: /
headers:
- name: X-Canary
value: "true"
backendRefs:
- name: my-app-svc
port: 80
5. Test advanced features: Try features such as header-based routing, traffic splitting, and cross-namespace scenarios as needed in staging/development, and promote into production as needed. These are capabilities not previously available with Kubernetes Ingress.
Use the Ingress-to-Gateway Migration Tool
For teams with many Ingress resources, manual translation can be tedious.
In an effort to keep migration simple, here is a guide, How to Migrate from Kubernetes Ingress to Gateway API, that introduces a migration utility to automate much of the conversion process.
For large estates, manually translating every Ingress is slow and error-prone. The Kubernetes SIG Network utility ingress2gateway converts existing Ingress resources into Gateway API resources, either by reading from your current kubeconfig or from input files. This gives you a solid starting point that you can review and apply with Cilium Gateway API enabled.
Below is an example of running the tool, specifying Cilium as the destination output.
ingress2gateway print \
--providers=cilium
Notifications from CILIUM:
+--------------+----------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------+
| MESSAGE TYPE | NOTIFICATION | CALLING OBJECT |
+--------------+----------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------+
| INFO | parsed "ingress.cilium.io/force-https" annotation of ingress and patched httproute.spec.rules[].filters fields | HTTPRoute: default/basic-ingress-https-httpbin-cilium-com |
+--------------+----------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------+
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
annotations:
gateway.networking.k8s.io/generator: ingress2gateway-0.4.0
creationTimestamp: null
name: cilium
namespace: default
spec:
gatewayClassName: cilium
listeners:
- hostname: httpbin.cilium.com
name: httpbin-cilium-com-http
port: 80
protocol: HTTP
- hostname: httpbin.cilium.com
name: httpbin-cilium-com-https
port: 443
protocol: HTTPS
tls:
certificateRefs:
- group: null
kind: null
name: demo-cert
status: {}
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
annotations:
gateway.networking.k8s.io/generator: ingress2gateway-0.4.0
creationTimestamp: null
name: basic-ingress-https-httpbin-cilium-com
namespace: default
spec:
hostnames:
- httpbin.cilium.com
parentRefs:
- name: cilium
rules:
- filters:
- requestRedirect:
scheme: https
statusCode: 301
type: RequestRedirect
matches:
- path:
type: PathPrefix
value: /
status:
parents: []
The tool can also run against a cluster and print equivalent Gateways and HTTPRoutes, which you can pipe to files for version control.
There are options to test the tool with a hands-on Cilium Ingress Controller lab, where you will learn how you can use Cilium to deploy Ingress resources and migrate to Gateway API.
Which Path Should You Take First?
Most teams start with Cilium Ingress to remove the maintenance risk immediately, then move to the Gateway API as their routing and organizational needs evolve.
If your platform already separates infrastructure and application teams, Gateway API will feel natural from the start. If your environment is smaller or less complex, Cilium Ingress offers the fastest path to replace ingress-nginx with minimal change.
A practical migration plan:
- Document current behaviour: Capture hosts, paths, TLS, health checks, and any NGINX annotations.
- Select a target: Choose Cilium Ingress for quick replacement, or Gateway API for long-term flexibility.
- Deploy and test: Install Cilium, configure DNS and certificates, and enable Hubble for visibility.
- Run side-by-side: Mirror traffic and validate behaviour before cutting over.
- Switch production: Redirect DNS or load balancer targets, monitor closely, and keep a rollback plan.
- Iterate: Once stable, identify services that can benefit from Gateway API features and migrate them next.
Why Cilium Is a Sensible Default: Preparing for the Future
The deprecation of ingress-nginx is a pivotal moment for Kubernetes networking. Rather than patching together point solutions, this is your opportunity to adopt a unified, eBPF-powered platform built for performance, visibility, and security.
Cilium gives you:
- A drop-in Ingress replacement: Minimal migration pain, maximum reliability.
- A best-in-class Gateway API implementation: Unlock powerful new features and future-proof your stack.
- Unified observability and security: Deep insights and fine-grained controls out of the box.
- Active support and rapid innovation: Cilium is trusted by major cloud providers and community leaders.