By ByteBot
Ingress-NGINX, the controller running traffic routing in roughly half of all Kubernetes clusters, stopped receiving security patches on March 24, 2026. Not a deprecation notice — done. New CVEs will not be patched. The repositories are read-only. Kubernetes 1.36 “Haru,” released April 22, arrived into this reality with a clear message: the old way of doing ingress is over. If your cluster still runs Ingress-NGINX today, you’re operating unsupported infrastructure.
Here’s what 1.36 actually ships and — more urgently — what you need to do about the routing infrastructure you’re probably running right now.
What “Haru” Actually Ships
Kubernetes 1.36 is 80 tracked enhancements: 18 graduating to stable, 18 to beta, 26 new alpha features. The headline stable features are worth knowing, especially if you’re running multi-tenant workloads or AI/ML pipelines.
User Namespaces reached GA. This one matters more than most release notes convey. With a single field — hostUsers: false — root inside your container maps to an unprivileged UID on the host. A container escape no longer hands an attacker node-level admin access. It works transparently: no image changes, no volume workarounds. You need Linux 5.12+ for the underlying ID-mapped mounts, which most production distributions have shipped for a while now. For multi-tenant clusters and CI environments, this is the most meaningful security improvement Kubernetes has shipped in years.
Mutating Admission Policies (CEL) hit stable. Previously, adding mutations to admission — injecting sidecars, enforcing label policies, defaulting image pull behavior — meant running an external webhook server with its own TLS, its own deployment, and its own failure modes. With Mutating Admission Policies, you define the mutation as a native Kubernetes object using Common Expression Language. The kube-apiserver handles it in-process. Lower latency, no webhook infrastructure to maintain. For the 80% of mutation needs that are straightforward, you can retire the webhook server entirely.
DRA (Dynamic Resource Allocation) is now GA, replacing static device plugins as the standard mechanism for managing GPUs and FPGAs. Static device plugins required pods to be deleted and recreated for resource changes. DRA enables native scheduling with partitioning, sharing, and taints. If you’re running AI inference workloads on Kubernetes, this is the infrastructure primitive that makes GPU scheduling actually work at scale.
OCI VolumeSource reached stable. You can now store ML model weights or configuration packages as OCI artifacts in any registry and mount them directly into pods as volumes — no custom init containers, no bespoke image layering tricks.
IPVS kube-proxy mode was removed. Deprecated in 1.35, gone in 1.36. Many ops teams defaulted to IPVS for its hash-table-based service routing performance at scale. Run this to check yours:
kubectl get cm kube-proxy-config -n kube-system -o yaml | grep modeMigration options: NFTables (modern, ships in kube-proxy, good default for most clusters) or skip straight to eBPF via Cilium or Calico if you’re rebuilding and want maximum throughput.
The Ingress-NGINX Situation Is Urgent
The 60-day window SIG recommended for inventory after Ingress-NGINX’s March 24 retirement has expired. If you haven’t started, you’re behind. Here’s the decision you need to make:
Option 1: Patch it yourself. The repositories are public and read-only. You can fork and maintain your own builds. This is the wrong choice for almost every team — you’re taking on the security burden of a project SIG Network abandoned because it couldn’t keep up.
Option 2: Migrate to Gateway API. This is the right long-term move. The official ingress2gateway tool v1.0 converts your existing Ingress resources to Gateway API HTTPRoute objects automatically, including NGINX annotation translation. Budget 4-12 weeks depending on cluster size and annotation complexity.
Option 3: Switch to a maintained ingress controller. Some teams aren’t ready for Gateway API. Fair enough. But pick something actively maintained.
For most teams migrating off Ingress-NGINX, the clearest paths are:
- kgateway — CNCF-donated, Envoy data plane, 7 years of production history, has its own ingress2gateway fork that handles NGINX-specific annotations. Low-effort migration.
- NGINX Gateway Fabric — the official F5/NGINX successor, Gateway API-native. Keeps NGINX semantics without the dead-end maintenance trajectory.
- Envoy Gateway — community-governed, strong spec conformance, no vendor lock-in. Good for teams that want Gateway API purity.
- Traefik v3 — simpler to operate, good for smaller clusters or dev platforms.
- Cilium — only if you’re already using Cilium as your CNI. Switching CNIs just to get Gateway API support is rarely worth the disruption.
Gateway API’s design is genuinely better than the Ingress spec. It separates concerns by role: infrastructure providers manage GatewayClass, cluster operators manage Gateway, app teams manage HTTPRoute. Header matching, traffic splitting, and backend weighting are first-class — no annotation soup. The InfoQ breakdown of 1.36 has good context on the broader shift SIG Network is making.
What to Do This Week
If you’re on Kubernetes 1.35 or earlier and running Ingress-NGINX, here are your immediate actions:
- Run an inventory: which clusters use Ingress-NGINX and how many Ingress resources do they have?
- Check your IPVS config before upgrading to 1.36:
kubectl get cm kube-proxy-config -n kube-system -o yaml | grep mode - Enable User Namespaces on any pod spec where you control the workload and want host isolation:
hostUsers: false - Pick your Ingress-NGINX replacement and run ingress2gateway in dry-run mode to see what migration output looks like
- File the sprint. This isn’t something to defer past Q2.
Kubernetes 1.36 is a consolidation release, not a flashy one. User Namespaces GA and DRA stable are meaningful long-term improvements. But the immediate story is the routing infrastructure many teams are still running on — and the fact that it is now officially unmaintained. That’s the thing to act on today.
