Kubernetes Wants You Off Ingress, but Gateway API Feels Like a Puzzle

A better idea trapped behind a worse experience

There is real excitement around Gateway API, and the concept clicks fast: more flexibility, cleaner abstractions, and a future-facing way to manage traffic inside Kubernetes. The problem shows up the moment someone tries to use it. The experience feels heavier than expected, especially for something positioned as the next step forward.

One voice captured it perfectly. They liked the idea and appreciated what it unlocks, yet could not ignore how difficult it feels to get running. That contrast creates friction. A feature can be technically superior, but if the path to using it feels complicated, people hesitate, and that hesitation ends up being a bigger barrier than anything in the technology.

Ingress worked because it was just there

Ingress succeeded for a simple reason: it felt native. It was part of the environment people already understood. Teams only needed to plug in a controller and everything else fell into place, charts could assume its presence, and workflows stayed predictable.

Gateway API changes that expectation. Now teams install controllers and manage CRDs, and that extra layer introduces version concerns that charts cannot anticipate. Something that used to feel standard suddenly becomes conditional. One developer described this as an "additional layer of version management," which hits harder than it sounds.

That difference changes how people think about adoption. The familiarity and certainty are gone, and even experienced teams start second guessing what used to be routine.

The argument for staying outside the core

A maintainer stepped in to explain the reasoning behind this design, and from a systems perspective it holds together. Keeping Gateway API outside the core allows faster iteration, so features can evolve without waiting for full Kubernetes release cycles. That speed matters in a world where infrastructure moves quickly.

Stability is the other reason. Core Kubernetes carries a heavy responsibility, and adding more directly into it increases maintenance risk and the chance of security issues. Keeping things modular reduces that pressure. One explanation put it clearly: core needs to stay stable, even if that means moving slower.

On paper, that reasoning makes sense. It matches how large systems tend to scale, and it puts long term health ahead of short term convenience.

The frustration from the people who actually use it

The frustration comes from a different place. Operators care less about architectural purity than about getting traffic into their clusters without jumping through extra steps. One reaction leaned into that hard, pointing out how strange it feels to need extra setup just to "receive traffic."

Another perspective questioned the timing. If Gateway API is not ready to be part of the core experience, why push it as the future replacement? That question lingers because it reflects a mismatch between messaging and reality.

Then there is the awkward coexistence problem. Ingress still exists and Gateway API sits beside it, so teams now navigate both, which adds mental overhead. One comment called it a "usability nightmare," capturing the feeling of juggling two overlapping systems.

A middle ground that still feels unfinished

Some voices try to bridge the gap. They acknowledge the current experience is not ideal while pointing out the benefits of flexibility. Running Gateway API outside the core allows faster updates without upgrading entire clusters, which matters in environments where upgrades take time or carry risk.

Versioned CRDs also promise stability: install stable definitions and avoid breaking changes. That sounds reassuring, and the contract could smooth adoption if it holds up consistently.

Even so, the experience still feels incomplete. One operator described challenges across multiple environments, especially in controlled setups where every dependency matters. Extra layers add friction in ways that documentation alone cannot solve.

The experience is holding it back

What holds Gateway API back is the experience of using it. The idea resonates, but the execution demands more effort than many expect, and that gap shapes perception faster than any technical advantage.

This feels like a transition phase. Ingress remains simple and familiar, while Gateway API is more powerful and also more demanding. Teams stand in the middle, weighing convenience against future readiness.

The conversation shows how difficult it is to replace something that already works well enough. Improvement alone does not drive adoption; the path to that improvement has to feel natural. Until it does, even strong ideas move slowly.