DEV Community: DevOps

How to Choose a Kubernetes Gateway API Implementation

DevOps — Tue, 29 Sep 2026 10:10:10 +0000

In July we covered the basics — this is the decision guide. Original at: https://www.astrokube.com/blog/in-depth-comparison-of-api-gateway-solutions.

From Understanding Gateway API to Choosing the Right Kubernetes Implementation.

In the previous article, we discussed the creeping limitations of Ingress, the structural promise of Gateway API, and the conceptual shift from a single monolithic controller to a well-defined separation of concerns. If you’ve followed that reasoning, you now understand why Gateway API exists and what it’s trying to solve.

But understanding the specification is only the beginning.

Gateway API gives you structure. It does not give you answers. Just like Ingress, it relies on controllers to turn those definitions into real traffic behavior.

The moment you move from “should I adopt Gateway API?” to “which implementation should I deploy?”, you enter territory the spec deliberately leaves open. And that openness, which is genuinely one of Gateway API’s strengths, is also where teams make decisions they’ll be living with for years.

Why Choosing a Gateway API Implementation Is Harder Than It Looks

There’s a trap that catches even experienced platform teams. Because Gateway API is a standard, it’s tempting to treat the choice of controller as an afterthought, an implementation detail you can swap out later if you need to. This assumption is usually wrong because Gateway API implementations vary in:

How closely they follow the specification
How they extend beyond it
Their operational model and maturity
Their alignment with broader ecosystems (Envoy, NGINX, service mesh, cloud providers) If you’re not careful, you can recreate the same fragmentation and hidden complexity that made Ingress painful, just with better APIs.

Migrating from Ingress to Gateway API is not just a replacement. It’s an opportunity to reset how traffic is managed in your platform. And that makes the choice of implementation far more consequential than it might initially appear.

How to Choose a Kubernetes Gateway API Controller (Key Criteria)

Before looking at specific implementations, it’s worth defining what matters.

This is not about finding the controller with the most features. It’s about understanding which trade-offs best fit your platform.

In practice, most teams end up evaluating implementations along a few key dimensions:

1. Alignment with Gateway API

Is Gateway API the primary configuration model?
Or is it layered alongside existing, implementation-specific APIs?

A tighter alignment usually means better portability and a more future-proof design.

2. Operational model and complexity

Does it follow a clear control plane / data plane separation?
How complex is it to deploy, upgrade, and operate?
What does day-two maintenance look like?

Some solutions optimize for simplicity. Others trade simplicity for flexibility and power.

3. Scope: gateway vs platform

Is it focused purely on north-south traffic?
Or does it extend into service mesh and east-west concerns?

A broader scope can be powerful, but it also increases operational overhead.

4. Extensibility and lock-in

How are advanced features exposed?
Through standardized APIs or implementation-specific extensions?

Extensions are often necessary, but they can reduce portability if overused.

5. Security and policy model

Are security features first-class and integrated?
Or do they depend on external systems or commercial add-ons?

This becomes critical in multi-team or regulated environments.

6. Governance and ecosystem maturity

Is the project community-driven or vendor-led?
How mature and widely adopted is it?

This influences long-term stability, support, and evolution.

These criteria reflect real trade-offs that affect how platforms behave under scale, how teams collaborate, and how easily systems evolve over time.

Gateway API Implementations Compared: Envoy, Istio, NGINX, Traefik, and KGateway

With that lens in place, the differences between implementations become easier to reason about.

Each one is not just a tool, but a set of design decisions about how traffic management should work and who owns that complexity.

Envoy Gateway
Alignment with Gateway API

Envoy Gateway shows strong alignment with Gateway API as its primary configuration model. It supports core resources (Gateway, HTTPRoute, GRPCRoute) as well as experimental ones (TCPRoute, UDPRoute, TLSRoute) and tracks the evolution of the spec closely, even if not always immediately on the latest version.

Operational model and complexity

It follows a clear control plane / data plane architecture. The controller translates Gateway API resources into Envoy Proxy’s xDS configuration and manages Envoy Proxy instances. This model is well understood and scalable, though it introduces moderate operational overhead.

Scope: gateway vs platform

Primarily focused on north-south traffic, but integrates naturally into broader ecosystems (API gateways, service mesh, observability stacks) thanks to Envoy.

Extensibility

Provides a structured extension model through CRDs such as BackendTrafficPolicy, ClientTrafficPolicy, and SecurityPolicy. These extend beyond the core spec while maintaining conceptual alignment with it.

Security

Strong and comprehensive: JWT, mTLS, API keys, Basic Auth, OIDC, CORS, and external authorization. Many capabilities are inherited from Envoy’s mature data plane.

Governance

Open source (Apache 2.0), part of the Envoy ecosystem, with strong ties to a CNCF graduated project. Backed by a mature community and governance structure.

Trade-offs

Strong spec alignment and flexibility
Mature, high-performance data plane
Extensions reduce portability across controllers
Moderate operational complexity

Istio
Alignment with Gateway API

High and improving. Istio supports Gateway API and is moving toward making it the default, but still maintains its own CRDs for advanced features not yet covered by the spec.

Operational model and complexity

High complexity. Uses a full control plane (istiod) and distributed Envoy proxies. Designed for dynamic configuration and large-scale environments, but requires significant operational investment.

Scope: gateway vs platform

Covers both north-south (gateway) and east-west (service mesh) traffic. The broadest scope among all implementations.

Extensibility

Extensible via WebAssembly (Wasm), though this is still evolving and not fully mature. Also relies on its own CRDs for advanced capabilities.

Security

Strong overall, especially in mesh scenarios (mTLS, policy enforcement). For ingress-specific use cases, capabilities are solid but less extensive compared to dedicated gateway solutions.

Governance

Open source (Apache 2.0), CNCF graduated project with high adoption and well-established governance.

Trade-offs

Unified model for gateway + mesh
Very powerful but operationally heavy
Gateway API is not the only configuration interface
Higher learning curve and maintenance cost

NGINX Gateway Fabric
Alignment with Gateway API

High. Supports standard and experimental resources with a steady update cadence and clear roadmap.

Operational model and complexity

Traditional controller + proxy model. Familiar and predictable, especially for teams already using NGINX. Complexity increases when using NGINX Plus features.

Scope: gateway vs platform

Focused on north-south traffic, with stronger value when integrated into the broader NGINX ecosystem.

Extensibility

Provides multiple implementation-specific extensions (RateLimitPolicy, AuthenticationFilter, SnippetsPolicy, etc.), enabling detailed proxy configuration but tightly coupled to NGINX behavior.

Security

Moderate. Supports basic authentication and mTLS, with more advanced capabilities available through NGINX Plus.

Governance

Open source (Apache 2.0), but closely tied to the NGINX/F5 ecosystem, with less neutral, community-driven governance.

Trade-offs

Strong ecosystem continuity for NGINX users
Flexible but tightly coupled extensions
Advanced features may require commercial offering
Less neutrality in governance

Traefik Proxy
Alignment with Gateway API

High. Supports Gateway API resources and tracks the spec reasonably well.

Operational model and complexity

Simplified model where the proxy itself acts as both control and data plane. Easier to deploy and operate, with fewer moving parts.

Scope: gateway vs platform

Primarily north-south traffic, with mesh capabilities existing outside the core OSS proxy.

Extensibility

Limited in the open source version. Many advanced features depend on the broader Traefik ecosystem (e.g., Traefik Hub).

Security

Limited in OSS. More advanced features (JWT, OIDC, WAF) are part of the commercial offering.

Governance

Open source (MIT), but primarily driven by Traefik Labs.

Trade-offs

Very easy to operate and adopt
Lower feature depth in OSS
Reliance on commercial ecosystem for advanced capabilities
Less flexibility for complex scenarios

** KGateway**
Alignment with Gateway API

Medium-high. Supports most resources but evolves more slowly alongside the specification.

Operational model and complexity

Control plane model similar to Envoy Gateway. May require additional components (e.g., Istio) for certain capabilities like mTLS, increasing complexity in some scenarios.

Scope: gateway vs platform

Focused on north-south traffic, with additional specialization for AI and microservices workloads via agentgateway. Not a full service mesh.

Extensibility

Provides its own CRDs (TrafficPolicy, HTTPListenerPolicy, DirectResponse) to extend functionality, particularly around traffic control and resilience.

Security

Moderate. Covers common needs (CORS, CSRF, access logging), with mTLS often relying on external systems like Istio.

Governance

Open source (Apache 2.0), CNCF Sandbox project. Earlier-stage maturity despite a longer history (formerly Gloo, created by Solo.io).

Trade-offs

Strong fit for specialized (especially AI-driven) use cases
Less mature and slower-moving than alternatives
Some overlap with evolving Gateway API features
May require complementary tooling for full capabilities

How to Choose the Right Gateway API Implementation for Your Platform

Based on real-world platform engineering experience, here is how we’d reason through the decision:

- If your primary goal is replacing Ingress with something that’s genuinely designed around Gateway API’s model, Envoy Gateway is the most coherent choice. Its extension model, security depth, and alignment with the spec’s evolution make it the strongest general-purpose option for most platform teams. You’re not betting on a controller that bolted on Gateway API support, you’re adopting one that was built around it.
- If you need to unify ingress and service mesh under a single platform, Istio is the only option that credibly addresses both. This is the right call when internal service-to-service complexity has reached the point where a mesh is genuinely warranted. Not as a hedge, but as a response to a clear operational need. If you’re not yet at that point, defer this decision. Don’t buy mesh complexity to solve an ingress problem.
- If your organization has deep operational investment in NGINX and continuity matters more than feature breadth, NGINX Gateway Fabric is a pragmatic choice. You’ll trade some security depth and governance neutrality for a smoother operational transition. For teams where that trade-off is acceptable, it’s defensible.
- If you’re operating a smaller platform and want to minimize moving parts, Traefik Proxy’s simpler architecture has real appeal. Go in with clear eyes about where the commercial tier begins, and make sure your projected security and extensibility requirements don’t outpace what the OSS proxy provides.
- If AI workloads are a first-class concern for your platform, KGateway deserves evaluation that the other controllers don’t need. The capabilities it adds for LLM routing and agent-oriented infrastructure are unique. Accept the trade-off on security depth and spec cadence, and plan for a less mature operational knowledge base.

Final Thoughts: Choosing the Right Gateway API Strategy

In the first article in this series, we saw that Ingress solved an important problem, but many teams have reached the limits of what it was designed to handle.

Gateway API addresses those structural problems. But Gateway API is a contract, not an outcome.

The implementation you choose determines how that model behaves in practice: how much complexity you carry forward, how your teams collaborate, and how your platform evolves over time.

The goal isn’t just to move beyond Ingress. It’s to avoid carrying its hidden complexity into your next architecture.

For most of the platforms we’ve worked with, Envoy Gateway represents the most durable starting point: built around the spec, strong on security, governed openly, and with an extension model that’s designed to stay coherent as the ecosystem matures. That’s not a universal answer. But it’s where we’d start, and where we’ve seen teams find the most confidence on both day one and day two.

Kubernetes Gateway API: when Ingress isn't enough and what to use instead.

DevOps — Tue, 28 Jul 2026 08:30:00 +0000

This is a cross-post from the AstroKube engineering blog. Original at https://www.astrokube.com/blog/kubernetes-gateway-api-when-ingress-isnt-enough-and-what-to-use-instead

If you’ve been running Kubernetes workloads, chances are you’ve used Ingress to expose HTTP services and define routing rules. For many teams, it handled basic routing requirements reliably.

Before Ingress became common, exposing applications often meant creating a separate Service of type LoadBalancer for each workload. In cloud environments, that translated into provisioning a new external load balancer per service, which was costly, fragmented, and difficult to standardize. The introduction of the Ingress API, together with an Ingress Controller (such as one powered by NGINX, Traefik, or HAProxy), consolidated this model into a shared entry point. Multiple applications could now reuse a single external load balancer, with routing rules defined declaratively inside Kubernetes. This was a significant architectural improvement and, for many teams, a major step toward platform maturity.

But as platforms grow, traffic patterns become complex, teams share clusters, security requirements tighten, and traffic isn’t just HTTP. This is when Ingress starts to feel insufficient and fragile, where a small change could have unexpected consequences.

The Ingress API was designed for basic north-south HTTP routing. Layer 4 traffic, fine-grained policy control, clear separation of responsibilities were out of scope. TCP routing was never part of the standard API and required controller-specific workarounds or separate LoadBalancer services.

Growing teams increasingly relied on controller-specific annotations and extensions to stretch the Ingress model beyond its original scope. What began as simple HTTP routing gradually accumulated custom behaviors, blurring the boundary between standardized API and implementation-specific logic. At small scale, this is manageable. At larger scale, configurations become harder to evolve confidently.

If Ingress feels like it’s working against you rather than for you, that’s not a reflection of your configuration skills. It’s a sign that Kubernetes traffic management has outgrown the assumptions Ingress was built on. The good news is that the ecosystem is responding with more flexible, scalable solutions. In this article, we’ll introduce the leading alternative, Gateway API, and lay the foundation you’ll need to evaluate which implementation is right for your platform.

Kubernetes Gateway API: A More Scalable Approach to Traffic Management

Gateway API is Kubernetes’ answer to a problem you may already feel but haven’t articulated: modern traffic management needs better boundaries, shared ownership, and room to grow. It doesn’t replace Ingress; it builds on its lessons and is designed for today’s reality: diverse traffic types, multi-team infrastructure, and explicit ownership separation.

Gateway API vs Gateway Controllers: Understanding the Specification

One common misconception is treating Gateway API as a standalone tool you install. In reality, just like Ingress, it is a Kubernetes API specification. With Ingress, you define Ingress resources in the cluster, but you must install an Ingress Controller—such as the NGINX Ingress Controller—to translate those resources into actual traffic behavior. Gateway API follows the same pattern: it defines standardized resources, while a Gateway controller implements them.

The key difference is that Gateway API makes this separation more explicit and structured. Instead of relying heavily on controller-specific annotations and loosely defined behaviors, it introduces clearer contracts, conformance profiles, and well-defined extension points. The boundary between API and implementation is deliberate.

What the Gateway API Defines

Gateway API defines contracts: a set of resources, relationships, and behaviors for consistent traffic management. It answers critical questions:

What is a gateway?
How do routes attach to it?
How are responsibilities shared across teams?

These questions translate directly into how you structure routing rules, delegate ownership across teams, and reason about traffic flow in a shared cluster.

What the contracts don’t describe is how traffic is actually processed; that’s the implementation’s job.

How Implementations Work

A Gateway API implementation (or controller) is a component that watches Gateway API resources and turns them into real traffic behavior, for example, configuring an underlying data plane such as Envoy, NGINX, or similar. Different implementations support the same resources but vary in performance, extensibility, and feature depth.

This separation is intentional. Ingress already supported controllers, but the challenge was that the core API covered only basic HTTP routing. Advanced capabilities—custom headers, authentication, TCP handling, and traffic policies—were often exposed through controller-specific annotations rather than standardized resources. The result was portability in theory but fragmentation in practice. Switching controllers frequently meant rewriting annotations and reinterpreting behavior.

Gateway API addresses this by elevating common traffic management needs into first-class resources such as Gateway, HTTPRoute, and TCPRoute. Instead of relying on ad-hoc annotations, most requirements are now expressed through structured, portable APIs. Extensions still exist, but they are formalized rather than improvised.

Think of it like Kubernetes itself: the platform defines what Deployments and Services are, but the underlying container runtime or CNI that processes them can differ. Gateway API works the same way. Gateway API works the same way. Multiple controllers exist, backed by different proxies or networking stacks. They all “speak” the same API but behave differently under the hood. The specification defines the contract; the controller fulfills it.The real question becomes: Which Gateway API implementation fits my platform’s needs today and will scale with me tomorrow?

How Gateway API Improves on Ingress

Now that you understand what the Gateway API is, let’s look at how it improves on Ingress.

Separation of Concerns and Role-Oriented Design

Ingress already allowed application teams to define routing rules without directly managing load balancers. However, the ownership boundaries were often implicit and loosely enforced.

Gateway API formalizes a clearer, three-layer model that reflect how platform teams actually operate:

Cluster administrators manage the underlying infrastructure and networking foundation.
Platform teams define and operate Gateways (the shared, stable entry points into the cluster).
Application teams define routes to those Gateways within defined guardrails. Instead of developers and cluster admins negotiating changes directly through a single abstraction, Gateway API enables controlled delegation to the intermediate platform role. Routes can be attached, limited, or scoped according to policy, reducing the risk of unintended cross-team impact.

Built for Evolution

Unlike Ingress’s ad-hoc annotations, Gateway API provides standardized extension points. This means fewer surprises when switching controllers and easier adoption of new features over time.

Ingress gave Kubernetes a starting point for HTTP routing and Gateway API represents the next phase. It is a framework that’s easier to maintain and scale when multiple teams collaborate.

Gateway vs Mesh Traffic Management: Comparing Gateway API Profiles

Gateway API is a specification with multiple implementations. But to use it effectively, you need to grasp its two primary profiles: Gateway and Mesh. Each solves a different problem.

The Gateway Profile: North-South Traffic

The Gateway profile is primarily designed to manage traffic entering or leaving the cluster through shared entry points. It models external exposure and controlled delegation at the edge of your platform.

Key capabilities include:

Standardization of ingress points: clearly defining shared entry points and listeners.
Route attachment clarity: application teams can attach HTTPRoute or TCPRoute resources without needing deep knowledge of the underlying infrastructure.
Separation of responsibilities: cluster administrators manage infrastructure, platform teams define routes within defined guardrails. When using the Gateway profile, you define Gateways and attach Routes within this structured, role-aware model. Under the hood, the controller may still provision Service type: LoadBalancer resources to expose traffic externally. The difference is not the presence of load balancers, but the standardized API, explicit ownership, and controlled delegation it enables.

*The Mesh Profile: East-West Traffic
*
The Mesh profile focuses on service-to-service communication and policy enforcement inside the cluster (east-west traffic) Where the Gateway profile handles how traffic enters your platform, the Mesh profile governs how workloads talk to one another once inside it.

Key capabilities include:

Traffic shaping: retries, circuit breaking, and weighted routing expressed through standard Gateway API resources rather than mesh-specific APIs.
Security enforcement: mutual TLS (mTLS) and fine-grained authorization policies.
Observability: consistent telemetry and traffic visibility across services.
These are powerful capabilities for complex, multi-team, or regulated environments, but they come with meaningful operational overhead:
Extra configuration layers. Additional cost of managing proxy infrastructure at the service level.
Additional control planes in side-car based meshes.
But not every cluster needs them. Only when the internal complexity demands it, they are worth the cost.

Why this Distinction Matters

Without this separation, you might assume the Gateway API requires a full service mesh. It doesn’t. Each profile answers a different question:

Gateway Profile: “How should traffic enter my cluster in a scalable, role-based, future-proof way?”
Mesh Profile: “How should services within my cluster communicate securely and reliably?” You can implement the Gateway profile without committing to a service mesh. It’s strategic—and often recommended—to defer Mesh decisions until a clear need arises.

When to Consider Mesh

Mesh adoption depends on organizational maturity, security requirements, service topology, and operational capacity; factors that vary wildly between platforms. Many teams stage these decisions; they stabilize north-south traffic first, then evaluate mesh only if internal complexity justifies it.

For most growing platforms, modernizing ingress is the immediate and measurable step forward. Once that foundation is stable, deeper service-to-service concerns can be evaluated with greater clarity and less architectural risk.

Conclusion

Ingress solved a real problem. It replaced a fragmented landscape of per-service load balancers with a single, declarative entry point and for a long time, that was enough.

But platforms don’t stay still.

Teams grow, traffic diversifies, security requirements tighten, and what once felt like a solid foundation starts to show its cracks.

Gateway API isn’t just a newer version of the same idea. It’s a rethinking of how traffic management should work in a world where infrastructure is shared, ownership is distributed, and the cost of a misconfiguration ripples across teams. The separation of concerns, the role-oriented design, the distinction between Gateway and Mesh are answers to problems you’ve likely already run into.

If your goal is to replace a legacy Ingress Controller, the Gateway profile of Gateway API is the natural evolution. Mesh addresses a different class of internal service-to-service communication and advanced policy enforcement. It’s a separate concern that should be evaluated independently and adopted when internal complexity demands it.

Understanding the specification is only half the battle. Gateway API is a contract, not an implementation and the controller you choose to fulfill that contract will shape your platform’s operational reality in ways the API itself doesn’t dictate. Performance, extensibility, maturity, and the hidden complexity of day-two operations all vary significantly between implementations.

At AstroKube, we have spent considerable time evaluating and operating the leading Gateway API implementations across real platform engineering scenarios. In the next article, we break down exactly the differences among them, so you can choose with confidence rather than guesswork.