Gateway API v1.2 shipped four GA networking features on October 3, 2024. See why it is the real long-term successor to Kubernetes Ingress. Read now.
Why Ingress Hit a Ceiling
Kubernetes Ingress solved a real problem: expose HTTP services through a single entry point with host- and path-based routing. It did that with a small, shared API that almost every cluster could use. The cost of that simplicity showed up later. Controllers had to invent vendor-specific annotations for TLS options, traffic splitting, header matching, retries, and multi-protocol needs. The same manifest often behaved differently across clouds and mesh products because the portable core was thin and the real behavior lived in extensions.
Teams also ran into ownership friction. Application developers wanted routes and backends. Platform teams wanted listeners, certificates, and shared infrastructure. Ingress largely treated those concerns as one object, so policy, blast radius, and review workflows blurred together. Gateway API exists to keep the useful parts of Ingress while fixing that model.
Gateway API v1.2, which shipped four GA networking features on October 3, 2024, is part of that shift from a single catch-all object to a layered, role-aware design. It is not a cosmetic rename of Ingress. It is a different contract for how cluster networking is declared and shared.
What Changes When You Move to Gateway API
The practical upgrade is separation of concerns. Platform operators define gateways and listeners—what ports, protocols, and hostnames the cluster accepts. Application teams attach routes that point at services and describe matching rules. That split maps cleanly to how most organizations already work: infra owns the edge, product teams own traffic to their apps.
Expressiveness is the other major change. Matching and filters that used to require controller-specific annotations become first-class fields. You can describe header- and method-based rules, weighted backends, redirects, and rewrites in a form that is intended to be portable across conforming implementations. Multi-protocol traffic—not only simple HTTP—is part of the design rather than an afterthought bolted on with custom resources unique to one vendor.
- Platform layer: gateway lifecycle, certificates, shared listeners, capacity, and policy attachment points.
- App layer: route objects, service backends, path and header matches, and release-oriented traffic weights.
- Implementation layer: the controller that programs the actual proxy or load balancer from the same CRDs.
How to Approach a Real Migration
Treat migration as a controlled dual-run, not a flag flip. Inventory every Ingress: hosts, paths, TLS secrets, rewrite rules, and annotations that change real behavior. Map each annotation to either a native Gateway API field or an implementation-supported extension. Anything that only exists as a controller annotation is a risk item—decide whether to drop it, replace it with a standard field, or keep it behind a documented exception.
Stand up a Gateway for a low-risk namespace first. Mirror traffic rules as routes, validate TLS and health checks, then shift DNS or the external load balancer only after parity checks pass. Keep the old Ingress until you have proven timeouts, redirects, and canary weights under real load. Document which teams own which objects so review bots and RBAC follow the new split instead of treating every route change as a cluster-wide infra change.
Why This Is the Long-Term Successor
Ingress will remain available for a long time, and simple sites can still use it. The long-term successor role belongs to Gateway API because it standardizes the features operators already needed, encodes platform versus app ownership, and reduces the annotation tax that made Ingress hard to move between environments. Gateway API v1.2’s GA networking features strengthen that foundation: more of the day-to-day networking surface is stable API rather than experimental or vendor-only glue.
If you are designing new edge routing today, prefer Gateway API unless you have a hard dependency that only your current Ingress controller provides. If you already run Ingress at scale, plan the migration by ownership and annotation debt, not by rewriting every host on day one. The goal is fewer one-off configs, clearer review boundaries, and routing manifests that still make sense when the underlying proxy or cloud load balancer changes.