Community Ingress-Nginx Retired: Kubernetes Migration Guide & Best Practices

Skip to main content

Pricing<br>Resources

Academy

About

Contact usDocs

Get Service Mesh Certified with Buoyant.<br>Enroll now!

Blog home<br>Community ingress-nginx Retired: How to Plan Your Migration

Linkerd Production Readiness Pre-Launch Checklist

Download checklist

Heading

Relevant articles<br>Linkerd vs Istio

eBPF, Sidecars, and the<br>Future of The Service Mesh

A Kubernetes engineer’s guide to mTLS

Ivan Porta

July 27, 2026

Linkerd

In March 2026, the Kubernetes project retired ingress-nginx, the community ingress controller that sits in the critical path of roughly half of all Kubernetes clusters. The repository is now archived and read-only, with no more releases, bug fixes, or security patches coming.<br>Your cluster kept running when this happened, and it still will. That's the catch. ingress-nginx continues to serve traffic as before, so it's easy to put off migrating. But every new vulnerability found from now on will remain unpatched, right in front of your workloads.<br>This leaves you with two options, both with trade-offs. You can fork ingress-nginx and maintain it yourself, which means your team is responsible for a security-sensitive controller. Or you can switch to a maintained controller. If your compliance requires no critical CVEs in production, the frozen image becomes a real problem as soon as a new critical issue appears, since there won't be a patched version to upgrade to. According to Datadog's telemetry, about half of Kubernetes environments were still running it when the retirement was announced, so a large share of the ecosystem is now carrying unpatched software in the most exposed position in the cluster.

Watch our Service Mesh Academy workshop: Community Ingress-Nginx is Retired. What are Your Ingress Controller Options Now?<br>How your ingress controller picks endpoints, and why the mesh cares<br>Before we get to Linkerd and the different ways of configuring ingresses and their effects, here's a quick overview of how an ingress controller behaves.<br>An ingress controller watches the Kubernetes API for Endpoints and Services, and when a request arrives, it applies your routing rules and forwards it on. By default, many ingress controllers do their own endpoint selection. They resolve the EndpointSlices or Endpoints associated with the Service, get the list of "Ready" pod IPs, and load-balance straight to a pod.

Diagram of an unmeshed cluster where the ingress controller watches Endpoints and Services, then load-balances straight to application pod IPs.On its own, that's fine, however it becomes a problem the moment you put a service mesh in front of your workloads, because now the mesh wants to do that endpoint selection. Linkerd meshes an ingress controller the same way it meshes any workload by injecting a proxy in front of it. When the controller hands that proxy a single pod IP, the proxy sees exactly one endpoint. It can't load-balance across the pods (Linkerd load-balances with power of two choices over a peak exponentially-weighted-moving-average (EWMA) latency estimate, which needs more than one endpoint to do anything useful).

Diagram of a meshed ingress controller handing its Linkerd proxy a single pod IP, leaving the proxy with one endpoint and no way to load-balance.In a normal flow that's hard to notice. You quietly lose the latency-aware load balancing the Linkerd proxy would have done and fall back to whatever round-robin or similar algorithm the ingress controller uses. The real damage shows up when you do a traffic split, because the proxy can't honor HTTPRoute-based traffic splitting, and your canary breaks.<br>Without Service resolution, the proxy receives a pod IP the controller already chose, so the HTTPRoute weights never get a say. Suppose you have an HTTPRoute that sends 100% of traffic to a canary and 0% to the primary. If the ingress controller resolves the Service to the primary's pod IP before the proxy ever sees the request, the proxy receives a pod IP, not the Service, and your weight rules never apply. Traffic goes to the primary. The HTTPRoute looks correct and does nothing. This is the failure mode to watch for on the first day behind any new controller.

Diagram with red question marks on the routes to the primary and canary pods, showing that the destination is already decided before the proxy sees the request.Two ways to make the handoff work<br>There are exactly two ways to fix this, and every ingress controller falls into one of them.<br>Tell the controller to target the Service, not the pod. You turn off the controller's own endpoint selection so it forwards to the Service IP and lets the mesh handle load balancing and routing.<br>Run Linkerd in ingress mode. When the controller can't be told to target the Service, you flip the proxy into ingress mode and have the controller pass the destination Service in a header.<br>The knob for each controller<br>Each controller has its own way to...