Kubernetes is declarative, modular, and cloud-agnostic. Until you hit the networking layer. For years, the Ingress API served as the default way to expose applications. It was enough to get started — simple TLS, host/path routing. But the moment you scale to multi-cluster, multi-team, or regulated environments, its limitations become painfully clear.
- Annotation sprawl
- Controller-specific quirks
- No support for service mesh
- No real separation between infra and app routing
That’s where Gateway API comes in. It’s not just ingress v2 — it’s a better design for Kubernetes networking: role-based, portable, and production-grade.
This post outlines what Gateway API offers, how it works, and how we’re helping real-world customers move from patchwork ingress setups to standardised, scalable, and observable traffic management.
Why ingress falls short
Ingress works well for basic use cases. But in the real world, teams end up relying on fragile, controller-specific features:
- You want header routing or canary deployments? That’s a pile of annotations.
- Want GRPC support? Hope your controller implements it.
- Want to share infra across teams safely? Not without writing glue code.
We’ve worked with teams running 20+ EKS clusters where inconsistencies in annotations and controller versions made standardisation almost impossible. Application teams couldn’t safely make changes. Platform teams couldn’t automate confidently.
What Gateway API fixes
Gateway API solves these pain points by introducing a clean separation of responsibilities:
GatewayClass defines the controller type (e.g., envoy, istio)Gateway defines listeners, addresses, and TLS- Routes (like HTTPRoute or GRPCRoute) define traffic behavior
This means platform teams manage infrastructure. Application teams own routing rules. And both do so with clear, versioned APIs.
Gateway API resource model
GatewayClass --> Gateway <-- HTTPRoute | GRPCRoute
A single Gateway can serve many Routes, and policies (timeouts, retries, mirrors) are now part of the spec — not annotations.
Preparing for Gateway API adoption in real-world platforms
Ingress has worked — until it hasn’t. Teams we work with are feeling the pressure: inconsistent routing behavior, annotation sprawl, no safe delegation model, and a growing need for portability across environments. While Gateway API adoption across the ecosystem is still early, the intent is clear: teams want to move toward a more modular, policy-driven networking model. And at Giant Swarm, we’re already supporting platform teams in getting ready.That means laying down the groundwork now so they’re ready to flip the switch when the ecosystem catches up.This includes:
- Defining a GatewayClass model for standardisation across environments
- Designing Gateway configurations with consistent TLS and listener setup
- Establishing safe app-team ownership of HTTPRoute using parentRefs
- Planning the use of ReferenceGrant for secure cross-namespace access
- Integrating policies like timeouts and retries into GitOps workflows
These patterns ensure routing logic can be tested, automated, and delegated safely across clusters, whether in production today or in rollout planning for tomorrow.
From ingress to mesh: GAMMA in production
Gateway API doesn’t stop at ingress. With GAMMA (Gateway API for Mesh Management), you can now attach HTTPRoute directly to a Service to control east–west traffic. This means one API for both ingress and service-to-service traffic.
GAMMA traffic flow
HTTPRoute
|
Service (mesh internal)
This is especially valuable for teams using service mesh frameworks like Istio or Linkerd. Instead of writing custom YAML or mesh-specific DSLs, they define timeouts, retries, and route splits with the same Gateway API.
In one customer case, we helped migrate existing Istio VirtualService to HTTPRoute, reducing complexity and bringing mesh policy into the same GitOps pipeline as ingress.
Delegation and safety
One of the best parts of Gateway API is safe delegation. Teams can:
- Define Routes in their own namespace
- Reference only allowed Services
- Use ReferenceGrant to declare cross-namespace trust
This structure scales in enterprise environments. You can control access without blocking autonomy.
Conformance and portability
Gateway API includes a conformance suite and publishes an implementation matrix. You can check exactly which features are supported by your controller before adopting them. That means no more guessing if GRPCRoute or timeouts will work in prod. You get consistent behaviour across clusters and vendors.
How Giant Swarm helps
We help platform teams adopt Gateway API in a way that fits their real-world environments:
- Define
GatewayClass and Gateways with consistent policies
- Delegate
Routes to app teams safely
- Integrate conformance-tested controllers
- Operate and monitor Gateway API 24/7
- Handle multi-cluster rollout, upgrades, and edge cases
We support this across AWS (EKS), Azure, on-prem, and hybrid setups. Whether you’re just starting or looking to replace legacy ingress, we’ll help you implement Gateway API without slowing your teams down.
Final thoughts
Gateway API represents more than just a better ingress. It’s a consistent, scalable interface for all Kubernetes traffic — with safety, conformance, and real role separation built in. If you’re running modern platforms at scale, this is the interface to bet on. And at Giant Swarm, we’re here to help you get it right.
Curious how Gateway API can simplify your networking strategy? Let’s explore how we can make it production-ready in your environment. Get in touch.
