Alongside the Kubernetes 1.35 "Timbernetes" release, the project confirmed that the official Ingress NGINX controller, long the default, most widely deployed way to route external traffic into a cluster, is moving to best-effort maintenance only, with full retirement scheduled for March 2026. For any platform or infrastructure team that adopted Ingress NGINX years ago simply because it was the obvious, community-blessed default, this forces a migration decision that a lot of teams have been able to defer indefinitely until now. The retirement is the tail end of a longer transition the Kubernetes project has been steering toward for a couple of years: the newer Gateway API, which graduated to general availability and has continued maturing through 2025 and 2026, was explicitly designed to replace the aging Ingress resource with a more expressive, extensible routing model, and a growing list of implementations, Envoy Gateway, Istio, Cilium, and others, now support it as a first-class citizen rather than a bolt-on. Kubernetes 1.35 itself also graduated in-place Pod resource updates to general availability, letting CPU and memory limits change without restarting a Pod, and made the image volume type stable, letting a Pod pull an OCI image from a registry and mount its contents directly as a read-only volume, both meaningful for teams running dense, resource-sensitive workloads. But the Ingress NGINX retirement is the change that actually forces action: teams still relying on it should treat this as a hard deadline to evaluate a Gateway API implementation, since running an officially unmaintained ingress controller in production is a growing security and reliability liability that only gets worse the longer it's deferred.