Why Four Years to Call Something Stable?
Kubernetes 1.32 landed in December 2024 with the Gateway API finally marked as generally available. That’s not hyperbole, not marketing language. It’s actually stable now. But four years from initial proposal to GA? That timeline tells you something important about what the Kubernetes community learned the hard way with the original Ingress API.
Ingress was designed as a simple, opinionated path from your cluster to the outside world. It worked. It still works. The problem was that it tried to be everything to everyone while not being flexible enough for anyone. Every vendor extended it differently. Every team bolted on CustomResourceDefinitions to handle their specific use case. By the time the community realized Ingress had become a Rorschach test, the damage was already done.
The Gateway API took the time to fix something Ingress got wrong: role separation. Instead of one monolithic resource that a cluster operator and an application developer both needed to understand, the Gateway API splits the problem into three distinct perspectives. The infrastructure provider configures the physical gateway. The cluster operator defines routing policies. The application developer just specifies which routes their app needs. This makes sense architecturally. It also makes sense politically, which is harder to achieve and frankly more valuable in practice.
Three Roles, One Paradigm Shift
Here’s where most teams hit their first real friction point. Your current Ingress setup probably isn’t organized this way. You probably have a single YAML file or a small set of files that one person maintains, or maybe your application teams define their own Ingress resources and someone central validates them. This works because Ingress doesn’t force you to think about roles. Gateway API does.
The infrastructure provider role deals with GatewayClasses and Gateways. Think of this as the layer that says “here’s how traffic enters this cluster, what hardware backs it, what certificates are available, what policies apply at the perimeter.” The cluster operator role works with HTTPRoutes and other route types, defining how traffic gets distributed once it’s inside the cluster. The application developer role? They just attach their route to a gateway and move on.
When you start mapping your existing structure to this model, you discover that your team hasn’t actually defined who owns what. Is your platform team the infrastructure provider or the cluster operator? Are both? Are your application teams the cluster operator? You can’t start migrating until you answer these questions, and the answers depend on your org chart, not your technology choices. This is why the transition takes time.
The NGINX and Envoy Divergence
NGINX released Gateway Fabric in 2024 as its native Gateway API implementation. The obvious move, the expected move. NGINX powers a huge percentage of Kubernetes ingress configurations, so you’d think adoption would follow naturally. It hasn’t. As of early 2026, deployment metrics show NGINX Gateway Fabric trailing significantly behind Envoy-based solutions, and there are real reasons for this gap beyond just inertia.
Envoy’s Gateway API implementation shipped earlier and benefited from being the reference implementation that many controller developers used as a working example. Envoy also brought years of sophisticated traffic management capabilities that mapped naturally onto the Gateway API’s more expressive route matching and policy attachment model. NGINX had to build those capabilities into Gateway Fabric from scratch while maintaining backward compatibility with its classic Ingress controller, and that’s a harder engineering problem than it looks from the outside.
What matters to you is this: if you run NGINX today, your migration path is clear but less optimized than if you run something Envoy-based. Your NGINX configs will still work. Gateway Fabric exists. But you won’t get the full benefit of Gateway API’s design philosophy until you’re willing to rearchitect how you think about your ingress layer.
The Adoption Wall and Your Risk Profile
KubeCon NA 2024 data showed that fewer than 15 percent of production clusters had adopted the Gateway API despite near-universal awareness. That’s not a typo. That’s a statement about how real this migration friction is. Most of the remaining 85 percent aren’t opposed to the Gateway API. They’re just not compelled enough to move yet.
This matters for your timeline planning because it means the ecosystem around Gateway API is still maturing. You’re not adopting a mature standard that every vendor has already optimized for. You’re adopting something that’s stable but still in active development across the implementation layer. The Kubernetes community has officially put Ingress into long-term maintenance mode, which is a clear signal about direction. But “official signal” and “actually ready for your production workload” are different things.
Check the Kubernetes Gateway API documentation for the current implementation status. As of early 2026, you can find detailed conformance reports from various controllers. Use these to validate that your chosen implementation actually passes the tests that matter for your use case. Don’t assume conformance. Verify it.
Service Mesh Complications and Istio’s Turn
If you run Istio or any major service mesh, there’s another layer to this decision. Istio’s 2025 roadmap deprecated its proprietary traffic management CustomResourceDefinitions in favor of Gateway API conformance. This affects roughly 35 percent of service mesh deployments according to CNCF data. If you’re in that group, the decision is partially made for you.
What this means in practice: Istio is saying “we’re moving to Gateway API as our primary configuration surface.” Your VirtualServices and DestinationRules still work today. They’ll continue to work through the maintenance window. But Istio’s development energy is moving toward Gateway API implementations, which means new features will appear there first, and existing features will eventually stabilize there while the proprietary APIs get fewer engineer-hours.
The complication is that Gateway API alone doesn’t give you everything a service mesh provides. VirtualServices included traffic management, retry logic, circuit breaking, and advanced routing that maps onto Gateway API through policies and experimental extensions. The bridge is workable but requires you to understand which features live where and how they compose. Again, this isn’t a blocker. It’s a learning curve with a cost attached.
Calculating Your Migration Cost
So what does it actually cost you to migrate from Ingress to Gateway API? First, the hidden curriculum: you need to rethink your team structure and document who owns what layer of traffic management. This takes time and conversations, none of which appear in a sprint backlog but all of which matter. Budget a month for this on a small to medium team.
Second, the technical translation. Your existing Ingress resources don’t convert cleanly to Gateway API. You need to redesign them with the three-role model in mind. If you have a hundred Ingress resources, this is a project, not a tweak. Budget two to three months if you’re doing this carefully, which you should.
Third, testing and validation. Your new Gateway API setup needs to behave identically to your old Ingress setup until you’re sure it’s better. You’ll need testing infrastructure that lets you run both in parallel or switch between them. That’s probably another month of work for a platform team.
For most teams, a full migration is a two to three quarter project, not something you slip into a sprint. The good news is that you don’t have to migrate everything at once. You can run Ingress and Gateway API side by side in the same cluster today. Move workloads incrementally. This lets you learn on a subset of your traffic before betting your whole system on the new model.
The Kubernetes 1.32 release notes are worth reading if you want the official word on what’s changed and what’s coming. More valuable, though, is running a proof of concept on a non-critical cluster and measuring how your specific tools actually behave with Gateway API. What works in documentation sometimes works differently in your infrastructure.
This transition isn’t urgent yet, despite the GA status. Ingress isn’t going anywhere for years. But the direction is clear, and the earlier you understand the shape of that change, the less painful it is when you decide to move. What’s your current Ing
