Gateway API: A Smarter Way to Handle Kubernetes Ingress

By Ananta Cloud Engineering Team | Kubernetes | September 10, 2025

Kubernetes Ingress has been the go-to solution for routing external traffic into clusters for years. It works well for basic use cases and is supported by many controllers like NGINX, Traefik, and Istio. However, as our infrastructure and traffic management needs have grown more complex—spanning multiple teams, protocols, and routing rules - I’ve hit the ceiling of what Ingress can offer.

That’s what pushed me to explore and eventually adopt the Kubernetes Gateway API, a newer and more extensible model for service networking. In this post, I’ll share why I made the switch, how the Gateway API addresses Ingress's limitations, and what to consider if you're planning a similar move.

Quick Comparison

Here’s a high-level comparison between Ingress and Gateway API:

Feature	Ingress	Gateway API
Resource Structure	Flat (single resource)	Layered (GatewayClass → Gateway → Route)
Extensibility	Annotations (limited, opaque)	CRD-based, cleanly extensible
Protocol Support	HTTP/HTTPS only	HTTP, HTTPS, TCP, TLS, UDP, gRPC
Multi-Tenancy	Hard to manage safely	Designed with role separation in mind
Status Visibility	Minimal or inconsistent	Standardized and rich
Controller Binding	Implicit via class	Explicit and declarative

Why Ingress No Longer Works for Us

1. Annotation Overload

Ingress uses annotations to configure custom behavior, such as TLS termination, path rewrites, timeouts, or security headers. These annotations are:

• Vendor-specific (NGINX, Traefik, etc.)

• Poorly validated

• Hard to test and version

They’ve become a brittle part of our deployment process. A small typo or incompatible annotation silently breaks routing.

2. Single Protocol Limitation

Ingress is fundamentally designed around HTTP and HTTPS. If you want to expose services over TCP, UDP, or gRPC, you need to hack around it using custom controllers, load balancer Services, or non-standard CRDs.

That’s not ideal when you're running diverse workloads (databases, game servers, message queues, etc.).

3. No Separation of Concerns

Ingress resources bundle together both infrastructure concerns (e.g., which IP or port to expose) and application logic (e.g., host/path routing). This makes it hard to:

• Delegate responsibilities between teams

• Apply fine-grained access control

• Reuse components cleanly across environments

How Gateway API Solves These Problems

The Gateway API introduces a set of CRDs that are purpose-built to support modern, scalable, and multi-tenant Kubernetes networking.

1. Clear, Layered Resource Model

Instead of cramming everything into a single resource, Gateway API breaks things down:

• GatewayClass: Defines how gateways are provisioned (e.g., NGINX, Istio)

• Gateway: Represents a load balancer instance and its listeners

• Routes (like HTTPRoute, TCPRoute, etc.): Define traffic behavior and service backends

This enables a clear separation of infrastructure and application logic.

2. Built-In Multi-Tenant Support

Using resources like ReferencePolicy, Gateway API allows fine-grained control over which namespaces can reference what. You can allow or deny routes to access backends across namespaces in a safe and auditable way - essential in shared clusters.

kind: ReferencePolicy
spec:
  from:
    - namespace: frontend
      kind: HTTPRoute
  to:
    - namespace: backend
      kind: Service

3. Support for Multiple Protocols

With native CRDs for various protocols (HTTP, TCP, TLS, UDP, gRPC), you no longer need to stitch together half-baked solutions. Everything is standardized and works consistently.

4. Extensible Without Annotations

Instead of fragile and opaque annotations, Gateway API supports clean extensibility using well-defined fields and custom filters, with schema validation and better IDE support.

5. Improved Observability

The status fields across Gateway API resources provide detailed feedback about listener readiness, route binding, and controller ownership. This drastically improves debuggability.

A Practical Example: Canary Routing

Canary deployments with Ingress often require extra tooling or annotations. With Gateway API, it's a first-class feature.

kind: HTTPRoute
spec:
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: / 
    backendRefs:
    - name: my-service-v1
      weight: 80
    - name: my-service-v2
      weight: 20

It’s straightforward, declarative, and vendor-neutral.

What You Should Know Before Migrating

While Gateway API is powerful, it comes with a few caveats:

What’s Good

• Better structure and separation of roles

• Native multi-protocol support

• Vendor-agnostic and standardized

• Safer for multi-team environments

What to Watch For

• Not all controllers fully support Gateway API yet

• Slightly more complex resource definitions

• Helm charts and third-party tools might not support it out of the box

Migration Tips

Here’s how to approach a smooth migration:

1. Audit Current Ingress Usage: Identify which features and annotations are in use

2. Evaluate Controller Compatibility: Check if your ingress controller supports Gateway API (e.g., Istio, NGINX, Envoy Gateway)

3. Start with Non-Critical Services: Migrate less critical routes first to test Gateway API behavior

4. Run Ingress and Gateway in Parallel: Use separate Gateway listeners to avoid downtime

5. Update CI/CD Pipelines and Helm Templates: Refactor deployments to generate Gateway API resources

   
   

Final Thoughts

Ingress was a great starting point for Kubernetes networking, but as workloads scale and complexity grows, it starts to feel limiting. The Gateway API brings a much-needed modern take—structured, flexible, extensible, and designed for real-world use cases beyond just HTTP.

If you're building multi-team, multi-protocol platforms on Kubernetes, the Gateway API is well worth adopting. For us, it’s been a game-changer.

Modernize Your Kubernetes Ingress with Gateway API

Ready to simplify and scale your traffic management? Discover how Ananta Cloud leverages the power of the Gateway API for smarter, more flexible Kubernetes ingress.

---

Email: hello@anantacloud.com | LinkedIn: @anantacloud | Schedule Meeting