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:

  1. Move to another ingress controller (such as Cilium Ingress, Traefik, or HAProxy Ingress).
  2. 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

What to Watch Out For

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.

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.

FeatureIngress-nginxCilium IngressCilium 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:

  1. Ensure Cilium is installed and configured for Gateway API: Cilium Gateway API Docs
  2. Install Gateway API CRDs: If your Kubernetes distribution does not ship with Gateway API, install CRDs as per the Gateway API Installation Guide.
  3. 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:

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: