The Great Kubernetes Ingress Transition: From ingress-nginx EoL to Modern Cloud-Native

The Uncomfortable Reality of Maintenance Mode

The Kubernetes ingress landscape faces an unprecedented crisis. With ingress-nginx officially projected to enter maintenance mode, thousands of organizations running critical production workloads suddenly find themselves at a crossroads. No new features. No major improvements. Just maintenance patches for a controller that powers much of the internet's Kubernetes traffic.

This isn't just another project lifecycle transition—it's an infrastructure emergency waiting to happen. The #IngressNightmare vulnerabilities revealed fundamental architectural flaws that go beyond patchable bugs. When your ingress controller can be compromised through malicious configuration injection, you're dealing with systemic design problems, not isolated incidents.

The proposed solution? InGate—a complete rewrite that exists today as little more than an ambitious roadmap with a handful of commits. The timeline? Years of development before reaching production readiness. The reality is organizations can't wait years to address critical security vulnerabilities that exist now.

Meanwhile, platform teams face an impossible choice: continue running outdated and vulnerable infrastructure or embark on disruptive migrations to entirely different ingress solutions, losing years of operational knowledge and configuration investments in the process.

Key Requirements for a New Ingress Controller

With ingress-nginx entering maintenance mode and InGate still years from production readiness, a gap has emerged in the ingress controller world. The Kubernetes community faces an immediate and critical challenge: the need for a new ingress controller. The stakes are incredibly high, given that ingress-nginx currently powers millions of these workloads. Therefore, any viable solution must meet four non-negotiable requirements.

1. Security by Design

The controller must be architecturally immune to the template injection vulnerabilities that plague NGINX-based solutions. This means no raw configuration templating, no dynamic library loading, and no string interpolation of user inputs into configuration files.

2. Broad Ecosystem Adoption

Any replacement must have proven production scalability and a thriving community. Organizations can't afford to bet their infrastructure on experimental or niche solutions during a critical transition period.

3. Gateway API Leadership

The future of Kubernetes networking lies in Gateway API, not “legacy” Ingress resources. The ideal controller should be a leader in Gateway API implementation, providing a clear migration path toward modern standards.

4. ingress-nginx Compatibility

Most critically, there must be a practical migration path that respects existing investments. Organizations have spent years building expertise around ingress-nginx annotations and configurations—this knowledge shouldn't become obsolete overnight.

Can Traefik be the One?

Given Traefik's wide adoption across the cloud-native ecosystem, it's worth exploring whether it could satisfy these four critical requirements and serve as a practical bridge during this transition period. Here's how Traefik aligns to the four requirements we just discussed:

Security: A Decade of Secure-by-Design Architecture

Traefik's security advantages aren't accidental—they're the result of fundamental architectural decisions made a decade ago. When I designed Traefik ten years ago, I made some critical architecture decisions:

• Go over C/C++: Choosing Go eliminated entire classes of memory safety vulnerabilities and optimized for interoperability with the cloud-native ecosystem
• Static linking over dynamic libraries: It is impossible to execute code not already part of the binary and the code base
• Structured parsing over templating: Configuration inputs are parsed into strongly typed Go structs, not interpolated into template strings
• Minimal attack surface: No external component, like admission controllers, have elevated cluster privileges

These weren't performance optimizations—they were security-first decisions that have proven prescient in light of today's threats.

Adoption: Battle-Tested at Scale

Traefik isn't an experimental solution—it's a proven platform trusted by organizations worldwide:

• 3.4+ billion downloads across its lifetime
• 55,000+ GitHub stars and growing showcasing a strong preference
• 800+ contributors actively developing and maintaining the codebase
• Production deployments in a wide range of startups and enterprises
• Cloud-native DNA built specifically for dynamic, containerized environments

Unlike solutions built for traditional infrastructure and later adapted for Kubernetes, Traefik was designed from the ground up for cloud-native environments where services appear and disappear dynamically. For a decade, Traefik's modern and flexible architecture has been proven extremely reliable at scale across a wide range of enterprise deployments.

Gateway API: Leading the Standard

Traefik leads Gateway API development and ensures seamless compatibility. As a key contributor to the Gateway API specification, Traefik Labs makes compatibility a fundamental design principle from day one.

With Gateway API now production-ready and positioned to become the new standard for exposing workloads in Kubernetes over the coming years, early adoption becomes a strategic advantage rather than a risky experiment. Organizations investing in Gateway API today are building toward the inevitable future of Kubernetes networking.

With full Gateway API v1.3 support in Traefik v3.5, organizations gain access to the most advanced Kubernetes networking capabilities available.

This represents true leadership in the future of Kubernetes networking. While other solutions treat Gateway API as an experimental add-on, Traefik has made it a core competency, positioning organizations for the networking standards that will define the next decade of cloud-native infrastructure.

Ingress NGINX Compatibility: The Missing Piece

The final requirement—practical migration support—has been the missing piece ... until now.

Making Traefik NGINX Compatible

Rather than building yet another ingress controller from scratch, we focused on three core objectives that would provide immediate value to the community:

• Support the most common use cases: We analyzed real-world ingress-nginx deployments and prioritized the annotations that represent 80% of actual usage.
• Preserve existing investments: We wanted organizations to use their existing ingress-nginx resources without modification. Teams shouldn't need to rewrite manifests, retrain engineers, or disrupt operational workflows in this transition.
• Eliminate injection vulnerabilities: Most critically, we wanted to securely parse NGINX ingress resources and transform them into Traefik's internal object configuration.

This approach offers compelling advantages:

• Leverage existing strengths: Security, performance, and Gateway API leadership
• Respect user investments: Preserve years of ingress-nginx expertise and configurations
• Accelerate migration: Provide immediate relief rather than years-long development cycles
• Enable gradual transition: Bridge from Ingress to modern Gateway API resources.

Replace ingress-nginx with Traefik, Step-By-Step

Let’s say you have an ingress resource deployed on your cluster with ingress-nginx as an ingress controller:

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-with-nginx-annotation
  namespace: default
  annotations:
    # BASIC Authentication
    nginx.ingress.kubernetes.io/auth-type: "basic"
    nginx.ingress.kubernetes.io/auth-secret-type: "auth-file"
    nginx.ingress.kubernetes.io/auth-secret: "default/basic-auth"
    nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"
    # SSL Redirect
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
    - host: whoami.localhost
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: whoami
                port:
                  number: 80
  tls:
    - hosts:
        - whoami.localhost
      secretName: external-certs
---
kind: Secret
apiVersion: v1
metadata:
  name: basic-auth
  namespace: default
type: Opaque
data:
  # user:password
  auth: dXNlcjp7U0hBfVc2cGg1TW01UHo4R2dpVUxiUGd6RzM3bWo5Zz0=

This snippet exposes a web server with basic authentication and http to https redirection, that can be accessed with the following `curl` command:

curl http://whoami.localhost -L -u "user:password" --location-trusted

If you want to expose with Traefik Proxy, you only need to deploy Traefik and enable the NGINX Provider:

kind: Deployment
apiVersion: apps/v1
metadata:
  name: traefik
  namespace: default

spec:
  replicas: 1
  selector:
    matchLabels:
      app: traefik

  template:
    metadata:
      labels:
        app: traefik

    spec:
      serviceAccountName: traefik-ingress-controller
      containers:
        - name: traefik
          image: traefik:v3.5.0
          imagePullPolicy: IfNotPresent
          args:
            - --log.level=DEBUG
            - --api.insecure
            - --api.debug
            - --entrypoints.web.address=:80
            - --entrypoints.websecure.address=:443
            - --experimental.kubernetesIngressNGINX
            - --providers.kubernetesIngressNGINX
          ports:
            - name: web
              containerPort: 80
            - name: admin
              containerPort: 8080
            - name: websecure
              containerPort: 443

---
apiVersion: v1
kind: Service
metadata:
  name: traefik
  namespace: default
spec:
  type: LoadBalancer
  selector:
    app: traefik
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 443
      name: websecure
    - protocol: TCP
      port: 8080
      name: admin

--providers.kubernetesIngressNGINX will enable Traefik to discover and parse ingress-nginx ingress resources.

Et voilà! The web server is exposed by Traefik using the same ingress resource:

Hostname: whoami-6f57d5d6b5-19ncq
IP: 127.0.0.1
IP: ::1
IP: 10.42.0.34
IP: fe80:: c498:5aff: fef7:be99
RemoteAddr: 10.42.0.38:47476
GET / HTTP/1.1
Host: whoami.localhost
User-Agent: curl/8.7.1
Accept: */*
Accept-Encoding: gzip
Authorization: Basic dXNlcjpwYXNzd29yZA==
X-Forwarded-For: 10.42.0.1
X-Forwarded-Host: whoami.localhost
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Server: traefik-7578bc64c5-pdjqm
X-Real-Ip: 10.42.0.1

As you can see, the migration path from ingress-nginx to Traefik could not be simpler! Bring your existing NGINX ingress resources, Traefik will do the rest.

As a cherry on top, Traefik Hub extends the open-source foundation with advanced API & AI Gateway & Management capabilities. This allows teams to start with secure ingress migration and evolve toward full API management capabilities without architectural disruption.

Full Support for High-Usage Annotations

The NGINX Provider doesn't attempt to support every possible ingress-nginx annotation—instead, we applied a data-driven approach to annotation selection based on real-world usage patterns and migration priorities.

The resulting annotation support spans the most critical operational requirements:

• Authentication and authorization mechanisms
• SSL/TLS configuration and backend communication
• Session management and load balancing preferences
• CORS policies for modern web applications
• Advanced routing capabilities

This curated approach means most organizations can migrate their core ingress configurations immediately while gradually adopting Traefik-native features for advanced use cases.

For the complete list of supported annotations, behavioral differences, and configuration examples, see the comprehensive NGINX Ingress Provider routing documentation.

The Path Forward: Community-Driven Evolution

The NGINX Provider isn't a finished product—it's a foundation designed for community-driven evolution toward becoming a true drop-in replacement for ingress-nginx. As mentioned, our current implementation focuses on 80% of use cases. 

The provider's architecture makes community contributions straightforward. Adding support for a new annotation typically involves:

1. Mapping the annotation to an equivalent Traefik middleware or option
2. Adding tests and documentation for the new functionality

This isn't just about building software—it's about building a sustainable community effort around practical migration needs. Each contribution makes the provider more useful for everyone facing the ingress-nginx transition.

Our long-term vision is clear: build a true drop-in replacement for ingress-nginx that provides both compatibility and modern capabilities.

Solutions, Not Promises…

The Kubernetes ingress crisis is happening now. ingress-nginx is about to be in maintenance mode. Many critical vulnerabilities have been discovered recently. Organizations need practical solutions today, not promises about tomorrow.

The Traefik NGINX Provider represents a pragmatic approach to an urgent problem. Instead of waiting years for InGate to mature or forcing disruptive migrations to completely different solutions, we're providing a secure bridge that respects existing investments while enabling future innovation. This isn't about perfect compatibility yet—it's about practical migration paths. 

The great Kubernetes ingress transition is happening whether we're ready or not. The question isn't whether you'll need to migrate from ingress-nginx—it's whether you'll choose a practical bridge that's available today or wait years for a solution that might never fully materialize.

Be pragmatic, not idealistic. Your production workloads depend on it.

The NGINX Ingress Provider is available as an experimental feature in Traefik 3.5. For complete setup instructions, visit the setup guide. For configuration examples and the full list of supported annotations, consult the routing configuration documentation. Join the conversation and contribute to the future of practical Kubernetes ingress migration.