API Gateway vs Kubernetes Gateway vs Service Mesh

An API gateway, Kubernetes Gateway API, and a service mesh solve related but different traffic-management problems:

An API gateway is a runtime component that receives API traffic and applies routing, authentication, rate limits, transformations, observability, and other policies.
Kubernetes Gateway API is a set of Kubernetes resources for configuring traffic infrastructure. It is not a proxy by itself; a controller and data-plane implementation must reconcile the resources.
A service mesh manages communication between workloads, commonly adding workload identity, mutual TLS, authorization, traffic policy, and telemetry without placing that logic in every application.

A Kubernetes platform can use all three. For example, Apache APISIX can act as the API gateway data plane, APISIX Ingress Controller can translate Gateway API resources into APISIX configuration, and a separate service mesh can govern workload-to-workload traffic.

Quick Comparison

Dimension	API gateway	Kubernetes Gateway API	Service mesh
What it is	Traffic-processing runtime and policy layer	Kubernetes configuration API	Workload communication infrastructure
Primary traffic	Client-to-API and partner-to-API	Commonly traffic entering Kubernetes; also supports mesh routing through GAMMA	Workload-to-workload traffic
Typical owners	API platform, security, or integration teams	Cluster operators and application teams	Platform, networking, and security teams
Main concerns	API exposure, consumer identity, quotas, transformations, analytics	Portable listeners, routes, backends, and policy attachment	Workload identity, mTLS, service authorization, telemetry, retries, and internal routing
Data plane included	Yes	No	Yes
Kubernetes required	No	Yes	Usually Kubernetes, although some meshes support VMs

The familiar "north-south versus east-west" shortcut is useful, but it is not an absolute boundary. API gateways can protect internal APIs, meshes can expose ingress and egress gateways, and Gateway API now includes service-mesh use cases. Choose based on ownership, identity, policy, and deployment requirements rather than direction alone.

What an API Gateway Does

An API gateway sits on the request path between API consumers and backend services. It gives teams one place to apply policies that would otherwise be repeated across services.

Common responsibilities include:

routing requests by host, path, method, header, or other attributes;
authenticating API consumers and enforcing authorization decisions;
applying rate limits, quotas, request validation, and transformations;
terminating TLS and controlling upstream connections;
producing access logs, metrics, and traces for API traffic;
supporting controlled rollouts, traffic splitting, and failure handling.

An API gateway is not the entire API management lifecycle. Developer portals, API design, governance workflows, subscription management, and monetization may be supplied by surrounding systems or a broader API management platform.

API gateways also run outside Kubernetes. They can proxy services on virtual machines, bare-metal hosts, multiple clusters, and public clouds through the same policy layer.

What Kubernetes Gateway API Does

Gateway API is an official Kubernetes project that defines role-oriented, portable, and extensible resources for service networking.

Its stable resource model includes:

GatewayClass, which identifies a controller and shared behavior;
Gateway, which requests traffic-handling infrastructure and defines listeners;
HTTPRoute, which maps HTTP requests to backend Services;
additional Route kinds and policies for other protocols and traffic concerns.

The resources separate infrastructure ownership from application routing. A cluster operator can manage GatewayClass and shared Gateway resources while application teams attach their own routes, subject to namespace and listener policies.

Gateway API does not process packets by itself. Installing its custom resource definitions without a compatible implementation has no effect on traffic. You must select a controller and verify its conformance, supported fields, policy extensions, and data-plane behavior.

The Kubernetes project recommends Gateway API for new capabilities because the older Ingress API is frozen. Existing Ingress resources remain supported, so migration should be based on a concrete need rather than the assumption that Ingress is being removed.

For a focused comparison, see Kubernetes Gateway API vs Ingress.

What a Service Mesh Does

A service mesh adds a data plane that mediates communication between workloads and a control plane that configures that data plane. Depending on the implementation, proxies may run as sidecars, node-level components, shared waypoint proxies, or a combination.

Typical mesh responsibilities include:

assigning and verifying workload identity;
encrypting workload-to-workload connections with mutual TLS;
enforcing service authorization policy;
collecting telemetry for internal calls;
controlling internal routing, retries, timeouts, and failure behavior;
supporting multi-cluster or cross-network service communication.

A mesh does not automatically replace an API gateway. Workload identity is different from API consumer identity, and internal service policy is different from managing public APIs, partner access, request quotas, payload transformations, and API products.

Similarly, not every platform needs a service mesh. Its security and traffic controls must justify the operational cost, resource overhead, upgrade process, and additional failure modes.

For a two-way decision guide, see API Gateway vs Service Mesh.

Where the Boundaries Overlap

Gateway API Can Configure Mesh Traffic

Gateway API began with ingress traffic, but its GAMMA initiative extended the API for service-mesh use cases. In the mesh model, Route resources can attach directly to Kubernetes Services instead of attaching to a Gateway.

This makes Gateway API a possible common configuration language for ingress and mesh routing. It does not eliminate the mesh data plane that intercepts and enforces workload traffic.

A Gateway Product Can Support Kubernetes Resources

Some API gateway products also provide a Kubernetes controller. The controller watches resources such as Ingress, Gateway API, or implementation-specific custom resources and translates them into gateway configuration.

For example, APISIX Ingress Controller can use Kubernetes Ingress, Gateway API, and APISIX custom resources to configure the Apache APISIX data plane. Support varies by resource and field, so review the current Gateway API support matrix before choosing a configuration model.

A Service Mesh Can Have Ingress and Egress Gateways

Mesh ingress and egress gateways connect mesh workloads to networks outside the mesh. They remain part of the mesh trust and traffic model. They do not necessarily provide the consumer-facing API lifecycle, plugin ecosystem, analytics, or organizational workflows expected from an API gateway platform.

When to Use Each Option

Use an API Gateway When

external or internal API consumers need authentication and policy enforcement;
multiple services need consistent API-level rate limits, transformations, or observability;
the same gateway must front services across Kubernetes, VMs, or multiple clouds;
APIs require a stable entry point independent of backend topology.

Use Gateway API When

Kubernetes teams need a role-oriented replacement for annotation-heavy Ingress configuration;
application teams should own routes without owning shared listeners or load balancers;
portability across conformant Kubernetes networking implementations is valuable;
the selected implementation supports the Route kinds and policy fields you require.

Use a Service Mesh When

workload identity and mutual TLS must be consistent across many services;
internal calls need centralized authorization, telemetry, or traffic controls;
application teams should receive those capabilities without implementing them in every service;
the platform team can operate the mesh control plane and data plane safely.

Common Deployment Patterns

API Gateway Without a Mesh

This is often sufficient when the main requirement is controlling client-to-API traffic. Kubernetes Services or another discovery system can handle basic internal connectivity.

API Gateway and Gateway API

Use Gateway API as the Kubernetes configuration surface and an API gateway implementation as the controller and data plane. Confirm which gateway features are portable Gateway API capabilities and which require implementation-specific policies or custom resources.

API Gateway and Service Mesh

Place the API gateway at the API boundary and use the mesh for workload communication behind it. Define which layer owns retries, timeouts, TLS termination, telemetry, and authorization so the same request is not governed by contradictory policies.

All Three Together

Gateway API can configure Kubernetes entry routes, an API gateway can apply consumer-facing policy, and a mesh can secure service-to-service traffic. This design is useful only when responsibilities are explicit; adding three control systems without clear ownership increases complexity.

Decision Checklist

Before adding or replacing a traffic layer, answer these questions:

Are you controlling API consumers, Kubernetes routing objects, workloads, or more than one of these?
Which team owns listeners, routes, identity, authorization, retries, and observability?
Must the policy work outside Kubernetes or across several clusters?
Does the selected Gateway API implementation support every required field and extension?
Will two layers retry, rate-limit, terminate TLS, or emit duplicate telemetry for the same request?
How will you test upgrades and roll back control-plane or data-plane changes?

Start with the smallest architecture that meets the requirement. Add Gateway API for Kubernetes ownership and portability, an API gateway for API-level policy, and a service mesh for workload-level communication controls. Use them together only when each layer has a distinct job.