Giant Swarm Blog | Kubernetes Insights from the team at Giant Swarm

The Gateway API shift: how Kubernetes networking actually works at scale » Giant Swarm

Written by Lucas Weatherhog | Oct 27, 2025

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. 
View full post