Kubernetes networking has spent years doing something very Kubernetes: taking a simple idea, wrapping it in twelve implementation details, and then asking everyone to be calm because there is an annotation for that.
Ingress was supposed to be the friendly front door. In practice, it became a shared fiction with different controllers, different annotations, different load balancer behaviors, and different levels of "works on my cluster" energy.
This is why Gateway API v1.6 caught my attention.
Not because TCPRoute and UDPRoute graduating to Standard is the kind of news that makes normal people cancel dinner plans.
It is interesting because Kubernetes networking is finally admitting the real problem:
Networking is not one object owned by one team.
It is a contract between platform engineers, network operators, security people, application teams, and the poor person holding the incident phone.
Gateway API v1.6 makes TCPRoute and UDPRoute Standard in the v1 API. The release also moves experimental APIs into a clearer separate group, gateway.networking.x-k8s.io, so teams can see the line between stable contract and "please do not bet payroll on this yet."
That sounds like API housekeeping.
It is actually platform governance wearing a YAML hat.
ingress was too small for the job
Ingress was useful. I am not here to pretend we all imagined it. For a simple HTTP service, host, path, TLS secret, backend service, done. Great.
Then production arrived.
Someone needed redirects. Someone needed header matching. Someone needed gRPC. Someone needed traffic splitting. Someone needed cross-namespace routing. Someone needed TCP because not everything in life is an HTTP endpoint with a tidy JSON body. Someone needed UDP because DNS, games, voice, and other inconvenient realities exist.
The answer became annotations.
Annotations are fine when they are metadata. They are less fine when they become a shadow API where every controller has its own dialect and every migration requires reading the controller docs like ancient cave paintings.
You can build serious systems with annotations. Many teams did. But the contract is weak. The Kubernetes API says one thing, the controller-specific behavior says another thing, and the real platform behavior lives in tribal knowledge, Helm values, and a wiki page last updated by someone who now works somewhere else.
Gateway API exists because service networking needs a richer model than "here is an Ingress, good luck."
roles matter more than objects
The best part of Gateway API is not a specific route kind. It is the role model.
A platform team can own GatewayClass, deciding which implementation exists and how it is configured.
An infrastructure or network team can own Gateway, deciding where traffic enters and what listeners exist.
Application teams can own HTTPRoute, GRPCRoute, TCPRoute, or UDPRoute, describing how their traffic should attach to that entry point.
Security can care about which namespaces are allowed to bind to which listeners and what cross-namespace references are allowed.
This is not just prettier YAML. This is the shape of the organization finally showing up in the API.
That matters because most Kubernetes networking incidents are not caused by nobody knowing how packets work. They are caused by ownership being blurry.
Who is allowed to expose a service?
Who approves a public hostname?
Who owns TLS policy?
Who can route traffic across namespaces?
Who knows whether the load balancer behavior differs between dev and prod?
If the answer is "whoever found the right annotation first," congratulations, you have invented networking roulette.
Gateway API is useful because it makes those boundaries easier to express as Kubernetes resources instead of hallway negotiations with kubectl.
tcp and udp graduating is a big deal
The v1.6 headline is TCPRoute and UDPRoute graduating to Standard.
That is not glamorous. It is better than glamorous. It is boring in the way infrastructure should aspire to be.
HTTP gets the attention because it is where most web teams live. But platform teams know the cluster is full of protocols that do not fit cleanly into HTTP routing:
- database proxies
- Redis or Memcached
- MQTT
- DNS
- custom TCP protocols
- UDP services
- legacy systems that survived because nobody was brave enough to ask why
Before Gateway API matures across these protocols, teams often end up with side paths. Some traffic uses Ingress. Some uses Service LoadBalancer. Some uses controller-specific CRDs. Some uses a cloud load balancer configured outside the cluster. Some uses Terraform, prayer, and a diagram with three arrows labeled "network."
That fragmentation is expensive.
Not always in cloud bill terms, although give it time. It is expensive in reasoning. During an incident, nobody wants to ask five systems where traffic might be going. They want one control plane, or at least one contract that explains the different routes.
TCPRoute and UDPRoute reaching Standard says layer 4 routing is no longer a side quest. It belongs in the Kubernetes networking contract too.
standard and experimental should be visibly different
I also like the experimental API group separation more than I expected.
Experimental features are not bad. They are how platforms grow. But the problem is when experiments look almost exactly like stable APIs until they break under you.
The new gateway.networking.x-k8s.io group makes the risk more visible. That is healthy.
Engineers are adults. Mostly. Let them use experimental features when the trade-off is worth it. But make the choice explicit. Put it in code review. Put it in the platform policy. Put it in the upgrade checklist.
If a team wants an experimental route feature for an internal tool, fine.
If a team wants it for card authorization traffic on Black Friday, maybe open a second tab and reconsider your life choices.
The important thing is not banning experiments. The important thing is keeping experimental contracts from silently becoming production foundations.
portability is still not magic
Gateway API is often described as portable. That is good, but we should not turn portability into another comforting lie.
Portable does not mean every implementation behaves identically in every environment. Load balancers still have personalities. Cloud networks still have limits. Controllers still differ in supported features. TLS, health checks, source IP behavior, cross-zone traffic, and observability can still surprise you.
The contract gets better. The work does not disappear.
A serious platform team should still ask:
- Which Gateway API resources are supported by our implementation?
- Which features are Core, Extended, or implementation-specific?
- How do we test routes before production?
- Who owns upgrades of the Gateway API CRDs?
- What metrics prove traffic is going where we think it is going?
- What is the rollback path if a route change behaves badly?
There it is again. Evidence. Ownership. Rollback. The usual boring friends.
Gateway API gives teams a cleaner place to put the network contract. It does not make the contract self-enforcing by magic.
the platform lesson
The bigger story is that Kubernetes keeps moving from "here are primitives" toward "here are shared contracts."
That is what mature platform work looks like.
A cluster is not just a place where pods run. It is a place where many teams negotiate identity, traffic, policy, cost, observability, upgrades, and failure boundaries.
The primitive-only version says:
"Create an Ingress and add these annotations."
The platform-contract version says:
"This Gateway is the approved public entry point. These listeners are owned by the platform team. These namespaces can attach routes. These route kinds are stable. These features are experimental. These metrics and alerts prove the path is healthy. These changes require review."
Less exciting. More useful.
This is why Gateway API v1.6 matters. TCPRoute and UDPRoute becoming Standard is not just about supporting more protocols. It is about reducing the number of weird escape hatches teams need when reality does not fit HTTP.
And the clearer experimental boundary is not just cleanup. It helps teams avoid accidentally treating tomorrow's idea as today's production contract.
what I would do now
If I owned a Kubernetes platform today, I would not rewrite every ingress next week because a blog post happened. That is how platform teams create migrations that nobody asked for and then act surprised when application teams hide.
I would do something smaller and more useful.
First, inventory current ingress and load balancer patterns. Find the annotation zoo. Find the controller-specific features. Find the services bypassing the main path.
Second, pick one Gateway API implementation already aligned with the platform direction. Do not make this a beauty contest with twelve vendors and a scoring spreadsheet from the land of eternal meetings.
Third, define ownership. Who creates GatewayClasses? Who owns Gateways? Who approves Routes? Who can attach across namespaces? Who reviews experimental features?
Fourth, migrate the next new service first. New contracts are easier when you are not also moving the old mess under pressure.
Fifth, measure it like production. Route status, listener health, backend failures, certificate issues, rejected attachments, and controller errors should be visible without someone spelunking through events at 2 a.m.
Gateway API is not "Ingress 2.0" in the lazy sense.
It is the Kubernetes network contract growing up.
That is not as catchy as a new dashboard screenshot, but it is much more valuable.
Because the real win is not that we get another API object.
The real win is that fewer critical networking decisions have to live in annotations, controller folklore, and one senior engineer's memory.
That engineer deserves a vacation.
The cluster deserves a contract.
references
- Kubernetes Blog: Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard
- Gateway API documentation
- Gateway API roles and personas
- Gateway API v1.6 API reference
To test my projects, I use Railway. If you want $20 USD to get started, use this link.
Top comments (0)