Gateway API becoming the baseline
Kubernetes ingress is quietly consolidating around the Gateway API as teams move off legacy Ingress controllers and standardise traffic, security and rollout controls. Datadog recommends staged migrations from Ingress NGINX to Gateway API to preserve traffic shifting and observability, and the CNCF now lists kgateway as a Kubernetes‑native gateway project that signals ecosystem alignment. For large, multi‑cluster services this reduces bespoke edge logic and makes north‑south policy surfaces easier to reason about across regions. (datadoghq.com) (cncf.io)
Most Kubernetes apps still need one thing before a user can reach them: a front door that accepts internet traffic and sends it to the right service. For years that front door was usually an Ingress object plus a controller like Ingress NGINX. (kubernetes.io) That setup worked, but Kubernetes froze the Ingress specification after version 1.19, so new networking features stopped landing there. The newer Gateway Application Programming Interface is now the official successor, and Kubernetes describes it as the next generation of Ingress, load balancing, and service mesh application programming interfaces. (kubernetes.io) (gateway-api.sigs.k8s.io) The big change is that Gateway Application Programming Interface splits one job into separate pieces. A GatewayClass says which gateway controller runs the system, a Gateway is the actual traffic entry point, and an HTTPRoute says where matching web requests should go. (kubernetes.io) (gateway-api.sigs.k8s.io) That sounds abstract until you compare it with old Ingress files stuffed with controller-specific annotations. Kubernetes says Gateway Application Programming Interface makes things more portable because traffic weighting, header matching, and other common routing features are native fields instead of one-off vendor extensions. (kubernetes.io) (gateway-api.sigs.k8s.io) It also changes who gets to touch what. Kubernetes documents the model around three roles — infrastructure provider, cluster operator, and application developer — so the team that owns the load balancer does not have to hand full control of edge policy to every app team shipping a route. (kubernetes.io) That is why this is becoming a baseline, not just a new syntax. In multi-team clusters, a Gateway can decide which routes are allowed to attach to which listeners, creating what Kubernetes calls a bidirectional trust model between the shared edge and the app routes that want to use it. (kubernetes.io) The migration story has also gotten more concrete in the last few weeks. On March 20, 2026, Kubernetes SIG Network announced Ingress2Gateway 1.0, a tool that converts Ingress resources and implementation-specific annotations into Gateway and HTTPRoute objects while flagging settings it cannot translate cleanly. (kubernetes.io) That release matters because the hard part is not writing new YAML, it is preserving behavior. Kubernetes says Ingress2Gateway 1.0 now supports more than 30 common Ingress NGINX annotations, including cross-origin resource sharing, backend transport layer security, regular expression matching, and path rewrites, and it tests generated configs against live controllers to check runtime equivalence. (kubernetes.io) The official migration guidance is careful on purpose. The Gateway Application Programming Interface project recommends running a Gateway controller alongside Ingress NGINX first, because the two controllers get different external internet protocol addresses, which lets teams validate routing in parallel without touching production traffic. (gateway-api.sigs.k8s.io) Datadog is telling users to take the same slow-road approach. Its current migration guide for Ingress NGINX says teams should validate behavior, shift traffic in stages, and monitor the cutover so they can keep rollout controls and observability instead of doing a one-shot swap at the edge. (datadoghq.com) The ecosystem signal is now showing up in project governance too. The Cloud Native Computing Foundation lists kgateway as a Sandbox project accepted on March 4, 2025, and describes it as an Envoy-powered, Kubernetes-native application programming interface gateway that integrates Kubernetes Gateway Application Programming Interface with a control plane for connectivity across cloud environments. (cncf.io) Put together, that means the “front door” layer in Kubernetes is getting less bespoke. Instead of every cluster carrying its own pile of annotations, custom edge rules, and controller quirks, more teams are converging on one shared traffic model that can handle internet ingress, policy boundaries, and progressive rollouts across regions with fewer surprises. (gateway-api.sigs.k8s.io) (cncf.io)
