Service-Mesh vs Ingress/API Gateway¶

Tasks¶

They handle different traffic:

Service Mesh = Pod-to-Pod (EAST-WEST) inside cluster
Ingress = External-to-Pod (NORTH-SOUTH) into cluster

Visual Explanation¶

═══════════════════════════════════════════════════════════════════════════
                    NORTH-SOUTH vs EAST-WEST TRAFFIC
═══════════════════════════════════════════════════════════════════════════

                         External Users
                         (Internet/Corp Network)
                                 │
                                 │ NORTH-SOUTH
                                 │ (Ingress handles this)
                                 │
                    ┌────────────▼────────────┐
                    │    KUBERNETES CLUSTER   │
                    │                         │
                    │    ┌──────────────┐     │
                    │    │   Ingress    │     │
                    │    │  Controller  │     │
                    │    └──────┬───────┘     │
                    │           │             │
                    │  ┌────────▼────────┐    │
                    │  │  Frontend Pod   │    │
                    │  └────────┬────────┘    │
                    │           │             │
                    │           │ EAST-WEST   │
                    │           │ (Service Mesh handles this)
                    │           │             │
                    │  ┌────────▼────────┐    │
                    │  │   API Pod       │────┼─► Database Pod
                    │  └────────┬────────┘    │
                    │           │             │
                    │  ┌────────▼────────┐    │
                    │  │   Auth Pod      │────┼─► Cache Pod
                    │  └─────────────────┘    │
                    │                         │
                    └─────────────────────────┘

What Each Does¶

Ingress/API Gateway (NORTH-SOUTH)¶

Purpose: Get traffic INTO the cluster

Handles:

✅ External → Cluster routing
✅ TLS termination (HTTPS)
✅ Hostname routing (api.mci.local)
✅ Path routing (/users, /orders)
✅ External load balancing
✅ Public IP exposure

Example Flow:

User Browser (Internet)
    ↓
http://api.mci.local/users
    ↓
LoadBalancer IP (192.168.228.200)
    ↓
Ingress Controller
    ↓
Routes to "api-service"
    ↓
API Pod receives request

Service Mesh (EAST-WEST)¶

Purpose: Manage traffic BETWEEN pods inside cluster

Handles:

✅ Pod → Pod communication
✅ mTLS (encrypted pod-to-pod)
✅ Service-to-service policies
✅ Retries, timeouts, circuit breakers
✅ Traffic splitting (A/B testing)
✅ Observability between services
✅ Service discovery

Example Flow:

API Pod wants to call Auth Service
    ↓
Service Mesh intercepts
    ↓
Checks: Is API pod allowed to call Auth?
    ↓
Encrypts with mTLS
    ↓
Load balances across Auth pods
    ↓
Tracks latency, errors
    ↓
Auth Pod receives request

Complete Architecture¶

═══════════════════════════════════════════════════════════════════════════
              BOTH INGRESS AND SERVICE MESH TOGETHER
═══════════════════════════════════════════════════════════════════════════

External User
    │
    │ 1. NORTH-SOUTH (Ingress)
    ▼
┌────────────────────────────────────────────────────────────────┐
│  Ingress Controller (Cilium Envoy)                             │
│  • TLS termination                                             │
│  • Hostname routing                                            │
│  • External authentication                                     │
└────────────────┬───────────────────────────────────────────────┘
                 │
                 ▼
            Frontend Pod
                 │
                 │ 2. EAST-WEST (Service Mesh)
                 │    • mTLS encryption
                 │    • L7 policies
                 │    • Retry logic
                 │    • Circuit breaker
                 ▼
            API Pod ──────► Auth Pod
                 │              │
                 │              │ 3. EAST-WEST
                 │              ▼
                 │         Database Pod
                 │
                 │ 4. EAST-WEST
                 ▼
            Payment Pod ───► Kafka Pod
                 │
                 │ 5. EAST-WEST
                 ▼
            Notification Pod

Why You Need Both¶

Scenario Without Service Mesh (Only Ingress)¶

✅ External traffic reaches cluster
❌ No encryption between pods
❌ No pod-to-pod policies
❌ No retry logic between services
❌ No circuit breakers
❌ Limited observability of internal traffic
❌ No canary deployments

Scenario Without Ingress (Only Service Mesh)¶

❌ External traffic can't reach cluster
❌ No TLS termination for external clients
❌ No hostname-based routing from outside
✅ Internal pod-to-pod works great

Cilium's Unique Position¶

Cilium does BOTH Ingress AND Service Mesh!

┌────────────────────────────────────────────┐
│               CILIUM STACK                 │
│                                            │
│  ┌──────────────────────────────────────┐  │
│  │  Ingress Controller (Cilium Envoy)   │  │
│  │  Handles: NORTH-SOUTH                │  │
│  └──────────────────────────────────────┘  │
│                                            │
│  ┌──────────────────────────────────────┐  │
│  │  Service Mesh (Cilium + Envoy)       │  │
│  │  Handles: EAST-WEST                  │  │
│  └──────────────────────────────────────┘  │
│                                            │
│  ┌──────────────────────────────────────┐  │
│  │  Kube-proxy Replacement (eBPF)       │  │
│  │  Handles: Load balancing             │  │
│  └──────────────────────────────────────┘  │
│                                            │
│  ┌──────────────────────────────────────┐  │
│  │  Network Policies (eBPF + Envoy)     │  │
│  │  Handles: L3/L4/L7 security          │  │
│  └──────────────────────────────────────┘  │
│                                            │
│  ┌──────────────────────────────────────┐  │
│  │  Observability (Hubble)              │  │
│  │  Handles: All traffic visibility     │  │
│  └──────────────────────────────────────┘  │
└────────────────────────────────────────────┘

This is why Cilium is powerful - it's an all-in-one solution.

Feature Comparison¶

Feature	Ingress Only	Service Mesh Only	Both (Cilium)
External access	✅	❌	✅
TLS termination	✅	❌	✅
Hostname routing	✅	❌	✅
Pod-to-pod mTLS	❌	✅	✅
Retries/timeouts	❌	✅	✅
Circuit breakers	❌	✅	✅
Traffic splitting	❌	✅	✅
L7 observability	⚠️ (edge only)	✅ (internal)	✅ (everywhere)
Network policies	⚠️ (limited)	✅	✅

Real-World Example¶

E-commerce Application¶

User Request: https://shop.mci.local/checkout
    │
    │ ┌─────────────────────────────────────────┐
    │ │ INGRESS NEEDED                          │
    │ │ • Accept HTTPS from internet            │
    │ │ • Route /checkout to frontend           │
    │ │ • TLS termination                       │
    │ └─────────────────────────────────────────┘
    ▼
Frontend Pod
    │
    │ Makes API call: POST /api/payment
    │
    │ ┌─────────────────────────────────────────┐
    │ │ SERVICE MESH NEEDED                     │
    │ │ • Encrypt traffic (mTLS)                │
    │ │ • Retry if payment service down         │
    │ │ • Circuit breaker if failing            │
    │ │ • L7 policy: only POST allowed          │
    │ └─────────────────────────────────────────┘
    ▼
Payment Service Pod
    │
    │ Calls: GET /api/inventory
    │
    │ ┌─────────────────────────────────────────┐
    │ │ SERVICE MESH NEEDED                     │
    │ │ • Check authorization                   │
    │ │ • Track latency                         │
    │ │ • Load balance across inventory pods    │
    │ └─────────────────────────────────────────┘
    ▼
Inventory Service Pod

You need both:

Ingress to get the user's request into the cluster
Service Mesh to manage the internal service calls

When You DON'T Need Service Mesh¶

Simple applications:

User → Ingress → Single Monolith Pod → Database

If you have:

Only 1-3 services
No pod-to-pod communication
No need for mTLS
No complex retry logic
Simple architecture

Then skip Service Mesh, just use Ingress.

When You DON'T Need Ingress¶

Internal-only cluster:

No external access needed
Pods only talk to each other
All traffic is EAST-WEST

Examples:

Data processing cluster (Kafka, Spark)
Batch job cluster
ML training cluster

Then skip Ingress, just use Service Mesh.

Summary Table¶

Traffic Type	Component	Purpose	Do You Need It?
External → Cluster	Ingress	Get traffic in	✅ YES (always)
Pod → Pod	Service Mesh	Manage internal traffic	⚠️ Only if microservices
External APIs	API Gateway	Advanced API features	❌ Not for internal tools

Bottom Line¶

Service Mesh ≠ Replacement for Ingress

They're complementary:

Ingress = Front door to your cluster
Service Mesh = Internal traffic management

For MCI:

✅ Use Cilium Ingress (you need external access)
⚠️ Service Mesh features later (if you build microservices)
❌ Skip API Gateway (internal tools don't need it)