Kubernetes Ingress Nginx is retiring

Retirement & Maintainership

  • Thread consensus: ingress-nginx was widely used, “just worked” for many, and its retirement feels like “end of an era.”
  • Backstory described as a maintainership failure: effectively one maintainer for years, best-effort only, offers of help not effectively onboarded. No new maintainers emerged; F5 (owner of NGINX) has its own competing product and little incentive to adopt it.
  • Some see this as a normal lifecycle after ~a decade; others see it as disruptive churn for something that still works.

Ingress vs Gateway API

  • Clarification: the Kubernetes Ingress API itself is not yet deprecated but is frozen and “on the path” to deprecation; Gateway API is positioned as the successor.
  • ingress-nginx’s retirement is seen as a loud signal to move toward Gateway API, though technically users could switch to another Ingress controller.
  • Gateway API is praised for richer features (rewrites, redirects, multiple L4/L7 route types, better security model) and for standardizing what used to be controller-specific annotations.
  • Some criticize Gateway as immature (e.g., cert-manager integration pain) and unnecessary complexity when ingress-nginx already met their needs.

Migration Options & Alternatives

  • Mentioned replacements:
    • Envoy Gateway (multiple route types, works in homelabs and EKS; can run side-by-side with existing Ingress).
    • Traefik with an nginx-annotations compatibility layer; partial coverage only.
    • NGINX Gateway Fabric (Gateway API-based, with tools to convert from ingress-nginx).
    • HAProxy Unified Gateway (beta) and other Gateway implementations listed in official docs.
    • Cloud provider-native ingress/gateway, Caddy or Apache frontends, Docker Swarm, ECS, Nomad.
  • Migrating custom nginx annotations is flagged as the hardest part; tools exist to inventory current annotations.

Envoy Configuration Debate

  • Envoy praised for zero-downtime reconfiguration at massive scale, but several consider its native config “unreadable” and only suitable when generated programmatically by controllers.
  • Others argue that once you think in terms of network layers, it’s manageable, especially when configured via Kubernetes CRDs rather than raw Envoy config.

Kubernetes Churn & Complexity

  • Strong split:
    • Critics: Kubernetes behaves like a fast-changing JS framework; infra needs stability and LTS-style behavior. Each retirement adds work for no clear business gain.
    • Defenders: for medium/large orgs, Kubernetes plus containers is more reliable and maintainable than legacy VM/config-management stacks; swapping ingress controllers is routine when clusters are well-managed.
  • Broader ops discussion touches on:
    • Difficulty “keeping up” vs. benefits of platform teams and immutable infra.
    • Comparisons with Puppet/Chef/Ansible and alternative orchestrators.
    • Concerns that constant platform churn pulls time away from product work.

Open Source Sustainability

  • Several comments frame ingress-nginx as another example of critical OSS maintained by underpaid volunteers while companies of all sizes rely on it.
  • Some argue users are not “entitled” to long tail support if they never contributed; others call it immoral and shortsighted that companies won’t fund what they depend on.