API gateways, ingress controllers and service meshes all influence application traffic. That superficial similarity causes enterprises to buy overlapping platforms, create competing policy layers and leave teams unsure where authentication, routing, rate limits and telemetry belong.
The technologies solve different problems. An ingress controller primarily implements entry routing into a Kubernetes environment. An API gateway manages APIs as products and policy boundaries for consumers. A service mesh manages service-to-service communication inside a distributed application. Kubernetes Gateway API adds a more expressive, role-oriented configuration model and can support both ingress and mesh use cases, but it does not eliminate the need to decide which control plane owns each policy.
A sound architecture begins with traffic direction, trust boundary, consumer type and operating responsibility—not with a vendor feature checklist.
The shortest useful distinction
Use an ingress or Gateway API implementation to expose workloads and route north-south traffic into Kubernetes.
Use an API gateway when APIs require consumer identity, lifecycle management, quotas, monetisation, transformation or external developer governance.
Use a service mesh when internal service-to-service traffic requires consistent identity, encryption, routing, resilience and telemetry across many services.
An enterprise may need all three, two, one or none. The objective is not minimising component count at any cost; it is minimising duplicated responsibility and operational complexity.
What an ingress controller does
The Kubernetes Ingress resource describes HTTP and HTTPS routing to services. An ingress controller watches those resources and configures a proxy or load balancer to implement the desired behaviour.
Typical responsibilities include host and path routing, TLS termination, redirects and basic load balancing. Implementations often extend the resource with annotations, which can create vendor-specific configuration and governance challenges.
Kubernetes now recommends Gateway rather than Ingress for new capabilities. Ingress remains stable and widely used, but the API is frozen. Existing installations do not require immediate replacement; new platform designs should evaluate Gateway API.
Ingress is not automatically a full API-management system. It can expose an API, but exposure is only one part of managing an API as a governed product.
What Kubernetes Gateway API changes
Gateway API separates infrastructure ownership from application routing. GatewayClass identifies an implementation, Gateway represents traffic-handling infrastructure, and route resources such as HTTPRoute attach routing rules.
This role orientation matters in enterprises. A platform team can own the Gateway and allowed attachment policies while application teams own routes within defined boundaries. The model is more expressive and portable than annotation-heavy Ingress configurations.
Gateway API can also support service-mesh traffic through the GAMMA initiative, attaching routes directly to Services. This creates potential convergence at the configuration layer. It does not mean an API gateway product, ingress data plane and service mesh become operationally identical.
Treat Gateway API as an API for traffic configuration. Evaluate the implementation behind it for actual data-plane capabilities, security, observability and support.
What an API gateway does
An API gateway sits at a consumer-facing boundary and applies policies before requests reach backend services. Consumers may be public developers, mobile applications, partners, internal business units or AI agents.
Common capabilities include authentication and authorisation integration, API keys, quotas, rate limits, request validation, protocol transformation, version routing, analytics, developer portals and monetisation.
The gateway should enforce coarse-grained boundary policy. Fine-grained business authorisation usually belongs closer to the application or a dedicated policy decision service because the gateway may not have enough domain context.
An API gateway becomes especially valuable when the organisation treats APIs as products with owners, contracts, consumers, deprecation policies and service levels.
What a service mesh does
A service mesh provides a communication layer for workloads, commonly using sidecar proxies or node-level/ambient data planes. It establishes workload identity and applies policies consistently across service-to-service traffic.
Capabilities may include mutual TLS, traffic shifting, retries, timeouts, circuit breaking, service-level telemetry and authorisation policy. The mesh is designed for east-west communication where the number of interactions makes per-application networking code inconsistent and expensive.
A mesh is not a substitute for sound application resilience. Automatically retrying non-idempotent operations can duplicate transactions. A circuit breaker cannot repair a poor dependency design. Mesh policy must reflect protocol semantics and failure behaviour.
Compare them by architectural responsibility
Traffic origin is the first distinction. External-to-cluster traffic points toward ingress or Gateway API. Consumer-to-API traffic with product governance points toward an API gateway. Workload-to-workload traffic points toward a mesh.
Identity is the second distinction. An API gateway commonly validates user, client or partner credentials. A service mesh establishes workload identity. Ingress may terminate TLS but usually does not own the entire consumer identity lifecycle.
Policy scope is the third distinction. API gateways enforce boundary and consumer policy. Meshes enforce workload communication policy. Gateway API and ingress configure how traffic reaches workloads. Where features overlap, document a single authoritative layer.
When an ingress controller is enough
A straightforward web application with a small number of Kubernetes services may need host routing, TLS and load balancing—nothing more. An ingress implementation can be the correct answer.
It is also reasonable when authentication is handled by the application or a dedicated identity-aware proxy, traffic is primarily browser-based, APIs are not externally managed products and internal service communication does not require mesh-level controls.
Do not introduce a service mesh merely because the organisation uses microservices. Operational maturity, failure modes and policy requirements should justify it.
When to add an API gateway
Add an API gateway when different consumers need distinct credentials, quotas or contracts; when partners require onboarding and analytics; when versioning and deprecation must be managed; or when security policy needs a consistent consumer-facing enforcement point.
For internal APIs, an API gateway can still be useful when business units or platforms operate as formal consumers. However, routing every internal call through a central gateway can create latency, coupling and a large failure domain. Avoid turning the gateway into an enterprise service bus with hidden business logic.
Keep transformations limited and observable. Domain orchestration belongs in services or explicit workflow components, not an opaque gateway policy chain.
When a service mesh earns its complexity
A mesh becomes attractive when an enterprise operates many services across teams and needs consistent workload identity, mutual TLS, traffic policy and telemetry. It can also support progressive delivery and migrations by shifting traffic without modifying every application.
The mesh must have a platform owner, a supported onboarding path, capacity planning and an upgrade strategy. Teams need clear debugging tools because an additional network layer changes incident diagnosis.
Start with a small number of explicit use cases. If mutual TLS and identity are the primary goals, assess whether a lighter implementation can deliver them. If advanced traffic management is required, define how application and mesh retry policies will interact.
A common enterprise reference architecture
At the outer edge, a content-delivery network and web application firewall handle global delivery and broad threat filtering. A consumer-facing API gateway validates clients, applies quotas and produces API analytics.
A Kubernetes Gateway implementation routes approved traffic into clusters. Inside the environment, a service mesh establishes workload identity and applies east-west policy. Applications retain domain authorisation and business validation.
This is a possible pattern, not a mandatory stack. Smaller estates may combine the API gateway and cluster entry layer. The key is that every policy has one owner and one source of truth.
Prevent policy duplication
Create a traffic-policy matrix covering TLS termination, consumer authentication, workload identity, rate limiting, retries, timeouts, schema validation, authorisation, observability and audit logging.
For each policy, record:
- Authoritative enforcement layer
- Configuration owner
- Failure behaviour
- Exception process
- Evidence and monitoring source
- Testing method
Avoid applying retries at the gateway, mesh and application without coordination. Avoid three independent rate-limit systems. Duplicated controls do not necessarily create defence in depth; they often create unpredictable behaviour.
Design for failure and bypass paths
Ask what happens when the gateway control plane is unavailable, a mesh certificate rotates incorrectly, or an ingress configuration is rejected. Separate control-plane failure from data-plane failure and understand whether existing traffic continues.
Identify bypass routes. Can an internal service be reached directly around the API gateway? Can a public load balancer expose a service without platform approval? Can a namespace attach a route to a shared gateway?
Use network policy, admission controls, RBAC and cloud configuration governance to ensure the documented architecture matches reachable paths.
Build observability across layers
A request may traverse CDN, gateway, ingress, mesh proxies and several services. Standardise correlation identifiers and trace propagation. Define which layer records the consumer identity and how that context is passed safely.
Do not collect duplicate high-cardinality telemetry by default. Decide which layer provides traffic analytics, security audit evidence and service-level latency. Retain enough data to reconstruct failures while controlling cost and sensitive information.
Operational dashboards should distinguish boundary rejection, routing failure, connection failure and application error. A single “5xx rate” cannot locate responsibility.
Migration strategy
Inventory current routes, annotations and policies. Classify them as transport routing, consumer policy, workload policy or business logic. Remove obsolete rules before migrating platforms.
Move one responsibility at a time. For example, adopt Gateway API for cluster routing while retaining the existing API gateway. Validate route attachment, certificates, observability and rollback. Introduce mesh capabilities to selected services only after platform operations are stable.
Avoid simultaneous gateway replacement, mesh adoption and application modernisation. Too many moving layers make failures difficult to isolate.
Selection questions for architecture review
- Who are the consumers and what identity do they present?
- Is the traffic north-south, east-west or both?
- Are APIs governed products or simply application endpoints?
- Which policies require domain context?
- How many platforms will teams need to configure and debug?
- Does the implementation support Gateway API portability?
- What happens during control-plane and certificate failures?
- Which team owns upgrades and incident response?
- Can every rule be tested in delivery pipelines?
- Is the proposed complexity proportional to the risk?
Final recommendation
Choose by responsibility. Use Gateway API or ingress to control how traffic reaches Kubernetes workloads. Use an API gateway to govern consumer-facing APIs. Use a service mesh to manage service-to-service identity and traffic when scale and policy needs justify it.
Where platforms overlap, assign one authoritative enforcement point and test the complete path. Prefer standards-based configuration, explicit ownership and incremental adoption. The best architecture is not the one with the longest feature list; it is the one teams can operate, explain and recover under pressure.
Sources and further reading
Kubernetes Ingress documentation
Kubernetes Gateway API
Gateway API for service mesh
Istio traffic management
Responsibility matrix example
At the external boundary, the API product team owns consumer contracts, version policy and quotas. The security team defines authentication and baseline threat controls. The platform team operates the gateway and Kubernetes entry layer. Service teams own business authorisation, idempotency and domain validation. The mesh platform team, if separate, owns workload identity and east-west defaults.
Write this matrix before selecting products. Vendors often demonstrate the same feature—JWT validation, rate limiting or telemetry—at multiple layers. The matrix prevents capability overlap from becoming configuration overlap.
Performance and capacity engineering
Every proxy adds connection, memory and telemetry overhead. Benchmark the complete path with representative payloads, TLS, policies and failure injection. Compare median and tail latency because policy engines and external identity calls often appear in the tail.
Model connection pools and retry amplification. A client retry combined with gateway and mesh retries can multiply load during an incident. Establish retry budgets, backoff and idempotency rules. Capacity tests should include certificate rotation, configuration pushes and control-plane disruption.
Multi-cluster and multi-region considerations
Decide whether gateways are regional, global or cluster-local. Keep failure domains understandable. A global control plane may simplify policy but expand blast radius; independent regional planes require disciplined configuration distribution.
For meshes, clarify service discovery across clusters, identity trust domains, locality routing and failover. Do not allow cross-region traffic to emerge accidentally because a local dependency is unhealthy. Cost, data residency and latency policy should be explicit.
Governance through policy as code
Validate routes and policies before deployment. Use admission controls to restrict which namespaces can attach to shared gateways, expose public addresses or weaken TLS. Test configuration with representative requests in delivery pipelines.
Version traffic policy beside application or platform configuration according to ownership. Use progressive rollout for high-impact changes. Record who approved exceptions and when they expire. Architecture governance becomes effective when it is executable and observable, not when it exists only in diagrams.
