The Kubernetes Ingress Landscape in 2026: Nginx Isn't the Center Anymore

For about a decade, “Kubernetes ingress” effectively meant one thing: ingress-nginx, the community-maintained controller that wrapped the Nginx engine behind the Kubernetes Ingress resource. It was fine. It was the default everyone reached for. It was also, quietly, the wrong long-term shape for the problem.

That era ended in 2026. The community ingress-nginx project reached end-of-life in March 2026. The Kubernetes Gateway API, which graduated to GA on the v1.2 line, is now the forward-looking standard. Envoy Gateway is the CNCF reference implementation. Cilium does L7 routing in eBPF without a sidecar or an extra proxy. RKE2 flipped to Traefik by default in v1.36 and removes ingress-nginx entirely in v1.37.

So the question stopped being “which Nginx do I run?” and started being something much more interesting: which of the half-dozen serious answers fits this cluster, this team, and this decade?

This post is the full survey. If you want my opinionated take on just Caddy / Nginx / Traefik as reverse proxies, that’s in my Caddy / Nginx / Traefik comparison post. This one is about Kubernetes specifically — both the old Ingress controllers and the new Gateway ones — and how I’d actually pick in 2026.

The shift from Ingress API to Gateway API

The reason this isn’t just a “swap your controller” exercise is that the underlying API changed.

The Ingress resource was always a compromise. One CRD, a thin spec, and twenty different controllers piling their actual feature set into annotations. Want a rewrite rule? Annotation. Want a TLS passthrough? Annotation. Want canary routing? Annotation. Every cluster I’ve ever inherited has an ingress.yaml that’s 80% annotation soup and only readable if you happen to know which controller wrote it.

The Gateway API is SIG-Network’s redesign with three goals, and it actually hits them:

• Role-oriented. GatewayClass, Gateway, and *Route resources split cleanly between infra owners (who provision Gateways) and app teams (who attach Routes). No more shared annotation namespace.
• Expressive without annotations. Header matching, weighted splits, mirroring, retries, TLS modes — all in the typed spec.
• Portable across implementations. A HTTPRoute you wrote for Envoy Gateway works on Cilium Gateway API and NGINX Gateway Fabric, because the spec is the contract, not the controller.

The Gateway API hit GA on the v1.2 line in 2024 and has been expanding the supported feature set steadily since. By 2026 every serious implementation supports the GA HTTPRoute, most support GRPCRoute and TLSRoute, and the experimental TCPRoute and UDPRoute are in increasing use.

This is the layer the new generation of controllers targets first. A few still ship Ingress support for compatibility, but Ingress is now the legacy shape.

The old guard: Ingress controllers worth knowing

These are the controllers that implemented the original Ingress API. They are not dead — most are actively maintained — but their center of gravity is shifting.

ingress-nginx (community) — RIP

The community ingress-nginx controller, the one that lived in kubernetes/ingress-nginx, reached EOL in March 2026. No more releases. No more CVE backports. If you are still running it in production, the clock is loud.

The planned official successor, InGate, did not ship. The project quietly stalled, and the Kubernetes ecosystem moved on without it. If you read articles from 2024 promising “InGate is the future,” ignore them — that future didn’t happen.

What replaced it depends on what you want:

• Stay on Nginx, supported: migrate to F5 NGINX Ingress Controller (NIC). Different repo, different config shape, different annotations, actively maintained, OSS available.
• Stay on Nginx, Gateway API: NGINX Gateway Fabric, also from F5, is the Gateway API-native one. See below.
• Leave Nginx entirely: Traefik, Envoy Gateway, or Cilium Gateway API, depending on the cluster.

The migration from community ingress-nginx to F5 NIC is not zero-effort. Annotation prefixes change (nginx.ingress.kubernetes.io/* becomes nginx.org/*), some annotations have no equivalent, and the CRDs differ. Budget a sprint, not an afternoon.

Traefik

Traefik is the path of least resistance on Rancher-flavoured Kubernetes. RKE2 v1.36 made Traefik the default ingress, and v1.37 removes ingress-nginx entirely. If you run RKE2 on-prem (which I do — see my RKE2 on-prem write-up), you are getting Traefik whether you opted in or not.

Traefik 3.7 supports both Ingress and Gateway API, has real Kubernetes-native CRDs (IngressRoute, Middleware, TraefikService), and handles ACME without extra parts. The trade-offs I covered in the reverse-proxy post still apply — trails Nginx on raw RPS, configuration sprawl when teams don’t agree on which provider owns what — but on a Rancher cluster it’s the right answer.

Caddy

Caddy has a Kubernetes ingress controller, and it works, but calling it a serious K8s ingress in 2026 is generous. It’s a good fit for very small clusters or single-tenant setups where the automatic-TLS-out-of-the-box ergonomics matter more than anything else. For real production K8s, look elsewhere.

HAProxy Ingress

HAProxy is the controller that always shows up in the “still alive” column and never in the “exciting” column, and that’s the correct framing. HAProxy Kubernetes Ingress Controller is rock-solid, fast, has a small footprint, and supports the Gateway API as of late 2025. If you have a team that already runs HAProxy at the edge and on bare metal, the in-cluster controller will feel like home. If you don’t, there are more modern options.

Kong

Kong is interesting because it never really was “just an ingress.” It is an API gateway that also speaks the Kubernetes Ingress and now the Gateway API, via the Kong Gateway Operator. If you want rate limiting, OIDC, request transformation, and a plugin ecosystem at the edge — and you’re comfortable running a heavier control plane — Kong is genuinely good.

I tend to reach for Kong when “ingress” and “API gateway” are the same problem for the team. When they are clearly different layers, I’d rather have a thin ingress and a separate API gateway than one component pretending to be both.

Istio ingress gateway

If you already run Istio as your service mesh, the Istio ingress gateway is the obvious edge — same Envoy, same control plane, same identity story (mTLS, AuthorizationPolicy). The new Istio ambient mode changes the shape of this significantly: Envoy moves off the per-pod sidecar and onto a per-node ztunnel

• waypoint proxy. Cluster overhead drops substantially, and the ingress gateway is the same Envoy you were going to deploy anyway.

If you don’t run Istio, do not adopt Istio just to get an ingress.

Ambassador / Emissary

Worth a sentence so you’re not surprised. Emissary-ingress (the OSS continuation of Ambassador) is still maintained as a CNCF incubating project but has lost a lot of mindshare to Envoy Gateway, which is the same Envoy underneath with the official Gateway API contract on top. New deployments should default to Envoy Gateway; existing Emissary clusters are fine but the trajectory is what it is.

The Gateway API implementations

This is the more interesting layer in 2026.

Envoy Gateway

Envoy Gateway is the CNCF reference implementation of the Gateway API, sitting on top of the Envoy proxy. It is, for a lot of new clusters, the safest default if you don’t have a strong reason to pick something else. It’s the implementation Envoy’s own maintainers ship. It tracks the Gateway API spec closely. The performance ceiling is Envoy’s — which is excellent. The CRDs are the Gateway API CRDs with a small set of Envoy-specific extensions for things the spec doesn’t yet cover.

The cost is the cost of running Envoy: it’s a beefier proxy than Nginx and uses more memory per instance. Worth it for the feature parity, the protocol coverage (HTTP/3, gRPC, TLS passthrough), and the operational story of “this is the same engine the rest of the ecosystem standardised on.”

Istio (ambient + gateway)

Istio in 2026 means ambient mode for most new installs. The sidecar-per-pod model is finally optional, ztunnel runs at the node level for L4, and a waypoint proxy picks up L7 work only for the workloads that need it. Ingress is the same Envoy via the Istio Gateway API implementation.

If you want mTLS-everywhere, identity, and L7 policy on top of a real ingress, this is now a much lower-overhead choice than the 2024 sidecar-everywhere Istio. If you don’t need a mesh, don’t pay for one.

Cilium Gateway API (eBPF)

This is the one I keep telling people to look at.

Cilium, the eBPF-based CNI, has supported the Gateway API for a while and the 2026 releases make it production-credible. The trick: there is no sidecar and no extra proxy pod. Cilium does the L7 routing in eBPF programs attached at the kernel level, on the same node where the pod runs. Your packet path is shorter, your memory footprint is lower, and you don’t have an Envoy process to babysit.

If you’re already running Cilium as your CNI — which a lot of people are, after the kube-proxy / iptables migration story I covered in my eBPF post — turning on Gateway API is mostly a config flip.

Trade-off: feature coverage trails Envoy. The Gateway API GA surface is there, gRPC routing works, but if you need exotic HTTP/3 features, request mirroring, or some of the more advanced filters, you may hit the wall earlier than with Envoy Gateway. For 90% of HTTP and gRPC routing, it is more than enough.

NGINX Gateway Fabric

NGINX Gateway Fabric (NGF) is F5’s Gateway API implementation on top of Nginx. It’s not the same product as F5 NIC — NIC speaks Ingress, NGF speaks Gateway API. Both are F5. Don’t mix them up.

NGF is the right pick if your organisation already has Nginx expertise, you want to land on the Gateway API, and you’d rather keep the engine you know than learn Envoy. It’s actively developed, the F5 commercial backing is real, and the Gateway API feature coverage has caught up enough that for normal HTTP/gRPC workloads it’s a fine choice.

Kong Gateway Operator

Kong Gateway Operator is Kong’s Gateway API story, managing Kong Gateway instances through the standard Gateway and HTTPRoute resources. Same Kong underneath, same plugin ecosystem, same API-gateway-first mindset — just driven by the Kubernetes-standard API instead of Kong’s own CRDs.

Pick this when you want both Gateway API conformance and Kong’s plugin model. Don’t pick it if you don’t need the plugins; the extra control plane isn’t free.

Cloud-managed ingress

Sometimes the right answer is “let the cloud handle it.” Each hyperscaler has its own take on this, and all three now support the Gateway API.

AWS

AWS Load Balancer Controller still ships the Ingress integration with ALB and NLB and is the workhorse on EKS. The newer AWS Gateway API Controller speaks Gateway API and is backed by VPC Lattice — AWS’s service-to-service networking fabric — for cross-VPC and cross-account routing.

Two different controllers, two different mental models. For straight in-cluster HTTP ingress, the Load Balancer Controller + ALB is still the path most teams take. The Gateway API + VPC Lattice path is more interesting when “ingress” actually spans multiple clusters and accounts.

GCP

GKE Gateway Controller is Google’s native Gateway API implementation, backed by their global L7 load balancer. It’s the most polished cloud-managed Gateway API experience right now — you get global anycast, GFE-grade TLS termination, and Gateway API CRDs in one cohesive product. If you’re on GKE and want managed ingress, this is the default answer.

Azure

Application Gateway for Containers (AGC) is the Azure-managed Gateway API implementation, replacing the older Application Gateway Ingress Controller (AGIC). AGC is Gateway API-native, has better latency and scaling than AGIC, and is where Microsoft is investing. AKS clusters spinning up in 2026 should go straight to AGC unless there’s a specific reason to stick with AGIC.

Honest trade-offs

Here is the part that matters more than any feature list.

When the plain Ingress API is still fine

If your routing is “host or path → service” and you don’t need header matching, weighted splits, or anything fancy — the Ingress API still does the job. Don’t migrate to Gateway API for migration’s sake. The cost of the migration is real (CRDs, RBAC, GitOps templates, observability dashboards) and the benefit is zero if you weren’t using annotations to begin with.

When Gateway API earns its complexity

Two clear signals:

• You have multiple teams sharing an ingress and the annotation soup is becoming a coordination problem.
• You need features that were always annotation-driven: header matching, request mirroring, weighted canaries, typed TLS policies. Doing them in the typed spec instead of free-form strings is worth the move.

If you’re a single team running a single Gateway, the Gateway API is still nice — typed specs are typed specs — but the win is smaller.

Performance, briefly

The numbers in 2026 community benchmarks land roughly where you’d expect:

These are order-of-magnitude numbers, not benchmark gospel. For 99% of workloads none of this matters. For the 1% that are genuinely CPU-bound on the proxy tier, it matters a lot.

Operational overhead

The real cost of any ingress controller in 2026 is operational, not throughput:

• CRD count. Istio still has the most. Traefik and Kong are middle of the road. Envoy Gateway and Cilium are leaner.
• Observability. Envoy-based options give you the richest metrics out of the box (access logs, per-route stats, the whole Envoy admin surface). Cilium gives you Hubble for flow-level visibility but the L7 story is shallower. Nginx is the same Nginx logs you’ve been parsing for fifteen years.
• Debuggability. When something is wrong, “where did the request go” is easiest on Nginx (one config, one access log), hardest on Istio in a bad day, and in the middle for everything else.

What I’m actually deploying in 2026

Concrete picks, no hedging:

• New RKE2 / K3s clusters: Traefik. It is the default, the migration story is clean, and there’s no reason to fight the distribution.
• New self-managed clusters on bare metal or VMs: Cilium Gateway API if I’m already running Cilium as the CNI (which I am, increasingly). Envoy Gateway if I want the broadest Gateway API feature coverage.
• New EKS clusters: AWS Load Balancer Controller for plain Ingress if the workload is single-cluster. Envoy Gateway or AWS Gateway API Controller if the routing is multi-cluster.
• New GKE clusters: GKE Gateway Controller. Hard to beat a global anycast L7 LB the cloud provider manages for you.
• Existing community ingress-nginx deployments: migrate this year. Either to F5 NIC if you want the smallest change, or to a Gateway API implementation if you’re going to rebuild the routing anyway.

What I migrated away from: community ingress-nginx, on every cluster I touch. Not because the engine is bad — Nginx is still excellent — but because running EOL software in 2026 is a choice, not an inheritance.

What I’m not deploying: Istio purely for ingress, Ambassador/ Emissary on greenfield clusters, Caddy as a serious cluster ingress.

The “just use the cloud load balancer” argument

It comes up every time. Why run a controller at all? Put an ALB or a GLB in front of the cluster and route from there.

It works for small setups. It falls apart when:

• You have more than a handful of services and the per-LB cost starts adding up.
• You need L7 features (header matching, canaries, mirroring) the cloud LB doesn’t offer.
• You want GitOps over a typed Kubernetes resource, not over an IaC-managed cloud-LB rule set that lives outside the cluster.
• You’re multi-cloud or hybrid and don’t want a different ingress per environment.

For one team, ten services, one cloud — the cloud LB is fine. Past that, an in-cluster controller pays for itself fast.

TL;DR

• Community ingress-nginx is EOL March 2026. InGate didn’t ship. Plan your migration this year, not next.
• The Kubernetes Gateway API is GA, role-oriented, and the forward-looking standard. New routing decisions should target it, not Ingress.
• Envoy Gateway is the CNCF reference and the safest default for greenfield Gateway API clusters.
• Cilium Gateway API is the eBPF-native option — no sidecar, no extra proxy — and a no-brainer if you already run Cilium.
• Traefik is the default on RKE2 v1.36+ and gets the job done on Rancher-flavoured clusters.
• F5 NIC is the supported Nginx-based continuation; NGINX Gateway Fabric is F5’s Gateway API take. Different products.
• Cloud-managed Gateway API (AWS, GCP, Azure) is now real, and on GKE it’s the default I’d reach for.

What’s holding ingress on your cluster — and would you bet on it still being there in 2028?