Ingress and a service mesh solve different networking problems.

Ingress
Ingress is a Kubernetes API object for managing external access into the cluster, typically HTTP/HTTPS. It routes inbound requests based on hosts and paths to backend Services. Kubernetes now says Ingress is stable but frozen, and recommends the newer Gateway API for future development. (Kubernetes)

Service mesh
A service mesh is an infrastructure layer for service-to-service communication inside and around your app, adding things like traffic policy, observability, and zero-trust security without changing app code. In Istio, this includes traffic routing, retries, timeouts, fault injection, mTLS, authentication, and authorization. (Istio)

Practical difference
Think of it like this:

• Ingress = the front door to your cluster
• Service mesh = the road system and security checkpoints between services inside the cluster

Use Ingress when
You need:

• a public endpoint for your app
• host/path routing like api.example.com or /shop
• TLS termination for incoming web traffic

That is the classic “internet → cluster → service” problem. (Kubernetes)

Use a service mesh when
You need:

• service-to-service observability
• mutual TLS between workloads
• canary / weighted routing between versions
• retries, timeouts, circuit breaking
• policy and identity for east-west traffic
• control over some outbound traffic too

Istio’s docs specifically describe percentage routing, version-aware routing, external service entries, retries, timeouts, and circuit breakers. (Istio)

Do they overlap?
A little. Both can influence traffic routing, but at different scopes:

• Ingress mainly handles north-south traffic: outside users coming in
• Service mesh mainly handles east-west traffic: service-to-service traffic inside the platform

A mesh can also handle ingress/egress via its own gateways, but that is a broader and heavier solution than plain Kubernetes Ingress. (Kubernetes)

Which should you choose?

• For a simple web app exposing a few services: Ingress is usually enough.
• For microservices that need security, tracing, traffic shaping, and resilience: service mesh is worth considering.
• Many teams use both: one for external entry, one for internal communication.

One current note: for new Kubernetes edge-routing designs, Gateway API is the direction Kubernetes recommends over Ingress. (Kubernetes)

Here’s a concrete example.

Example app

Imagine an e-commerce app running on Kubernetes:

• web-frontend
• product-api
• cart-api
• checkout-api
• payment-service
• user-service

Customers come from the internet. The services call each other inside the cluster.

With Ingress only

Traffic flow:

Internet → Ingress controller → Kubernetes Service → Pods

Example:

• shop.example.com goes to web-frontend
• shop.example.com/api/* goes to product-api

What Ingress is doing here:

• expose the app publicly
• terminate TLS
• route by host/path
• maybe do some basic load balancing

So a request might go:

1. User opens https://shop.example.com
2. Ingress sends / to web-frontend
3. web-frontend calls cart-api
4. cart-api calls user-service
5. checkout-api calls payment-service

The key point: Ingress mostly helps with step 1, the outside-in entry point. It does not, by itself, give you rich control/security/telemetry for steps 3–5. Ingress is for external access, and the Kubernetes project notes the API is stable but frozen, with Gateway API recommended for newer traffic-management work. (Kubernetes)

With Ingress + service mesh

Now add a mesh like Istio.

Traffic flow becomes:

Internet → Ingress/Gateway → web-frontend → mesh-controlled service-to-service traffic

Now you still have an entry point, but inside the cluster the mesh handles communication between services.

What the mesh adds:

• mTLS between services
• retries/timeouts
• canary routing
• traffic splitting
• telemetry/tracing
• authz policies between workloads

Example:

• checkout-api sends 95% of traffic to payment-service v1 and 5% to payment-service v2
• calls from cart-api to user-service get a 2-second timeout and one retry
• only checkout-api is allowed to call payment-service
• all service-to-service traffic is encrypted with mutual TLS

Those are standard service-mesh capabilities described in Istio’s traffic-management and security docs. (Istio)

Simple diagram

Ingress only

[User on Internet]
        |
        v
   [Ingress]
        |
        v

[web-frontend]

| v [product-api] -> [cart-api] -> [checkout-api] -> [payment-service]

Ingress + service mesh

[User on Internet]
        |
        v
 [Ingress / Gateway]
        |
        v

[web-frontend]

| v ————————————————- |

Service Mesh inside cluster | | [product-api] <-> [cart-api] <-> [checkout-api]| | \ | / | | \ v / | | ——> [user-service] | | [payment-service] | | | | mTLS, retries, tracing, canaries, policy | ————————————————-

Real-world way teams choose

Use just Ingress when:

• you have a small app
• you mostly need public routing
• internal service communication is simple
• you do not need per-service security/policy

Add a service mesh when:

• you have many microservices
• debugging internal calls is hard
• you need zero-trust service identity
• you do canaries/traffic shaping often
• you want consistent retries/timeouts/policies

One important 2026 note

For brand-new Kubernetes edge-routing setups, many teams are moving toward Gateway API instead of classic Ingress. Kubernetes recommends Gateway over Ingress for future-facing work, and Istio also supports Gateway API for traffic management. (Kubernetes)

Rule of thumb

• Ingress/Gateway API: “How does traffic get into my cluster?”
• Service mesh: “How do services inside my platform talk securely and reliably?”