Appearance
From NGINX to Istio: A Complete Guide to Modern Kubernetes Ingress and Service Mesh
NGINX Ingress Controller reached end of life on March 31, 2026. If you're still running it in production — especially in a microservices or banking environment — it's time to understand what comes next. This post covers Istio: what it is, how it works, how it compares to Gateway API, and why it's the right choice for security-sensitive workloads.
Table of Contents
- Why This Matters Now
- What Is Istio?
- The Problem Without Istio
- What Istio Actually Does
- Istio Architecture: Control Plane vs Data Plane
- North-South vs East-West Traffic
- Istio vs Gateway API vs NGINX: The Full Comparison
- Real-World Use Case: Banking Microservices
- Key Istio Concepts You Must Know
- Should You Use Istio?
- Final Thoughts
1. Why This Matters Now
The NGINX Ingress Controller reached end of life on March 31, 2026. That's not a minor version bump or a deprecation warning — it's a hard stop on security patches, bug fixes, and community support. This sent many platform and DevOps teams scrambling to evaluate alternatives.
The three most prominent options that came into the spotlight are:
- Istio (service mesh with ingress capabilities)
- Gateway API (the CNCF-standard specification)
- Other ingress controllers (Traefik, Contour, Emissary, etc.)
This post focuses on Istio — the most feature-rich and security-hardened of the bunch — and helps you understand when and why to choose it.
2. What Is Istio?
Istio is an open-source service mesh platform that connects, secures, and observes microservices in distributed or cloud-native applications.
| Attribute | Detail |
|---|---|
| Initial Release | 2017 (v1.0 in 2018) |
| Founded By | Google, IBM, and Lyft |
| License | Apache 2.0 |
| Core Proxy | Envoy |
| Deployment Modes | Sidecar and Ambient (new) |
| CNCF Status | Graduated project |
Rather than replacing your application code, Istio works around your services — intercepting, securing, and monitoring all communication transparently.
The Building Analogy
Think of your Kubernetes cluster as a large office building:
- Each room = one microservice
- Employees walking between rooms = requests between services
- Messages passed around = API calls and responses
Without Istio, the building has:
- No security guards ❌
- No visitor logs ❌
- No access control rules ❌
Anyone (or any compromised service) can walk into any room freely. This is how vanilla Kubernetes works by default.
With Istio, you get:
- Every employee has a verified ID card (mTLS identity)
- Doors only open if access is authorized (AuthorizationPolicy)
- CCTV and logs everywhere (observability)
- A smart routing system that can send some employees to a new wing for testing (canary deployments)
3. The Problem Without Istio
In a standard Kubernetes setup:
- Services communicate freely with each other over plain HTTP
- There is no automatic encryption between services
- There is no enforcement of which service can talk to which
- Observability (tracing, metrics, logs) requires instrumentation in every app
This creates three major risks in production:
- Security gaps — A compromised service can freely access any other service in the cluster
- Zero visibility — You have no idea which service is calling which, how long it takes, or when it fails
- Hard-to-manage traffic — Rolling out a new version or implementing canary testing requires custom tooling in each application
4. What Istio Actually Does
Istio gives you four superpowers out of the box — without changing a single line of your application code.
🔐 1. Security (Automatic mTLS)
Every service-to-service connection is automatically encrypted using mutual TLS (mTLS). Services authenticate each other using cryptographic identities (SPIFFE-based), not IP addresses or passwords.
📊 2. Observability (Built-in Telemetry)
Istio automatically collects distributed traces, metrics, and access logs for every request in the mesh. It integrates natively with Jaeger (tracing), Prometheus (metrics), and Kiali (topology visualization) — no application-level changes needed.
🚦 3. Traffic Control (Intelligent Routing)
With resources like VirtualService and DestinationRule, you can:
- Route 90% of traffic to v1 and 10% to v2 (canary deployment)
- Inject faults or delays for chaos testing
- Set retries, timeouts, and circuit breakers declaratively
🔁 4. Resilience (Automatic Recovery)
Istio handles retries, circuit breaking, and timeouts at the proxy level. If a downstream service is flaking, Istio can retry intelligently and stop hammering it when it's clearly down.
The key insight: Your application doesn't change. Istio's proxy intercepts all traffic transparently.
5. Istio Architecture: Control Plane vs Data Plane
Istio is split into two distinct layers. Understanding this split is essential to operating it confidently.
The Analogy
Think of a large corporation:
- 🧠 Management team sets company-wide policies → Control Plane
- 👷 Employees execute work on the ground → Data Plane
🔶 Control Plane (istiod)
The control plane is a single component called istiod. It is the brain of Istio.
What istiod does:
- Reads your YAML configuration (
VirtualService,DestinationRule,Gateway,AuthorizationPolicy) - Converts that config into Envoy-compatible instructions
- Pushes those instructions to all Envoy proxies in real time
- Manages certificate issuance and rotation for mTLS identities
- Performs service discovery (knows which pods exist and where)
Critical point: istiod is never in the request path. It does not handle live traffic. It only programs the proxies that do.
🔷 Data Plane (Envoy Sidecars)
The data plane is made up of Envoy proxy instances running as sidecar containers inside every pod.
[Your App Container] ←→ [Envoy Sidecar]Every inbound and outbound request from your pod flows through the sidecar — your app never communicates directly with the network.
What each Envoy proxy handles:
- 🔐 Encrypting/decrypting mTLS traffic
- 🚦 Applying routing rules received from istiod
- 📊 Generating metrics, traces, and logs
- 🔁 Retries, timeouts, and circuit breaking
Control Plane vs Data Plane — Quick Reference
| Feature | Control Plane (istiod) | Data Plane (Envoy) |
|---|---|---|
| Role | Brain | Worker |
| Handles live traffic? | ❌ No | ✅ Yes |
| Runs where? | Central (usually 1–3 pods) | Alongside every app pod |
| Responsibility | Define and push rules | Execute rules |
| Installed how? | Helm / istioctl | Automatic sidecar injection |
End-to-End Request Flow
You define a rule in YAML (e.g., "send 20% to v2")
↓
istiod reads and compiles the config
↓
istiod pushes instructions to all Envoy sidecars
↓
Envoy proxies enforce the rule on live traffic
↓
Metrics, traces, and logs are generated automatically6. North-South vs East-West Traffic
This is the single most important concept for understanding why Istio is uniquely valuable.
🔼🔽 North-South Traffic
Traffic crossing the boundary of your cluster — coming in from the internet or going out to external systems.
Internet / User
|
↓ ← NORTH-SOUTH
[ Kubernetes Cluster ]Examples in a banking app:
- A customer's browser hitting
banking.example.com - A mobile app calling your REST API
- Your backend calling an external payment gateway like Razorpay
Both NGINX Ingress and Istio Gateway handle this boundary. Gateway API also operates here.
↔️ East-West Traffic
Traffic moving horizontally inside your cluster — service to service.
[ Kubernetes Cluster ]
Frontend ←→ Backend ←→ Cards DB
↕
Customer DB
← EAST-WEST →Examples in a banking app:
- Frontend calling the Backend API
- Backend querying the Cards DB
- Backend querying the Customer DB
This traffic never leaves your cluster — and this is exactly what NGINX was completely blind to.
Why This Is Critical for Security
NGINX Ingress only guards the front door (north-south boundary). Once a request is inside your cluster, NGINX has zero visibility.
Attack scenario: If a malicious actor compromises your Frontend pod, they could freely call your Cards DB directly. NGINX would never know or stop it — that's east-west traffic happening entirely inside the cluster.
Istio's fix: By injecting an Envoy sidecar into every pod, every east-west connection is also encrypted with mTLS and checked against AuthorizationPolicy. No free movement inside the cluster, even if one service is compromised.
NGINX guarded your front door. Istio guards every door.
7. Istio vs Gateway API vs NGINX: The Full Comparison
Here is where a lot of teams get confused. Let's clarify the landscape.
Gateway API is a specification — a set of Kubernetes CRDs defined by the CNCF that any implementation can follow. It is NOT a product you run. It separates concerns cleanly: infra teams control the Gateway, app teams control HTTPRoute.
Istio is a full service mesh that now implements the Gateway API spec, in addition to its own mesh resources. It covers both north-south and east-west traffic.
NGINX Ingress was an ingress controller — it only handled north-south traffic and is now EOL.
| Feature | NGINX Ingress (EOL) | Gateway API (bare) | Istio |
|---|---|---|---|
| North-South routing | ✅ | ✅ | ✅ |
| East-West (service mesh) | ❌ | ❌ | ✅ |
| mTLS between services | ❌ | ❌ | ✅ Auto-injected |
| Traffic observability | Limited | ❌ Not included | ✅ Built-in (Jaeger, Kiali) |
| Circuit breaking | ❌ | ❌ Needs external tool | ✅ Native |
| Authorization policies | ❌ | ❌ Needs external tool | ✅ Native |
| Canary / traffic splitting | Limited | Limited | ✅ Rich via VirtualService |
| PCI-DSS / SOC2 compliance | Hard to satisfy alone | Hard to satisfy alone | ✅ Much easier to satisfy |
| Complexity | Low | Medium | High |
| Best for | Simple apps (EOL) | Clean ingress spec | Security-sensitive, complex microservices |
When to Use Gateway API (Without Istio)
If your workload is relatively simple and you only need clean, modern north-south routing with proper role separation between infra and app teams, a bare Gateway API implementation (like Envoy Gateway or GKE's built-in implementation) is a great choice. It's lighter than Istio and follows the emerging Kubernetes standard.
When to Use Istio
Choose Istio when you need:
- Encrypted service-to-service communication (mTLS) across all services
- Fine-grained authorization between services
- Built-in distributed tracing and service topology visualization
- Advanced traffic management (canary, fault injection, circuit breaking)
- Compliance with PCI-DSS, SOC2, GDPR, or similar frameworks
8. Real-World Use Case: Banking Microservices
Let's make this concrete. Imagine a banking application with the following services:
[ Internet ]
↓
[ Istio Gateway ]
↓
[ Frontend Service ]
↓
[ Backend Service ]
↙ ↘
[ Cards DB ] [ Customer DB ]Here's exactly what changes when you migrate from NGINX to Istio for each service:
Frontend Service NGINX previously did path-based routing (/api → backend). Istio's VirtualService replicates this but adds rate limiting, JWT validation at the edge, and the sidecar Envoy proxy enforces mTLS before the request even reaches your pod.
Backend Service The most impacted service. Every call from Frontend → Backend is now mTLS-encrypted. You can add AuthorizationPolicy so that only the Frontend's service account identity can call the Backend, effectively blocking lateral movement attacks.
Cards DB You can enforce that only the Backend pod's service account can reach the Cards DB. NGINX could never do this — it had no awareness of east-west traffic. This is fundamental for PCI-DSS compliance, which requires encrypted in-transit communication between all services.
Customer DB Same isolation as Cards DB. Critical for GDPR compliance and RBI (Reserve Bank of India) data residency requirements.
The compliance argument: PCI-DSS requires encrypted communication between all components that handle card data. Istio's automatic mTLS satisfies this requirement out of the box — without writing a single line of TLS code in your applications.
9. Key Istio Concepts You Must Know
Once you're running Istio, you'll interact with these resources daily.
istiod — The Istio control plane. Pushes configuration to all Envoy sidecars. Think of it as the brain that programs all the proxies.
Envoy Sidecar — Automatically injected as a second container into every pod via a mutating admission webhook. Your app container is untouched — Envoy intercepts all traffic transparently.
Gateway — Replaces your Ingress object. Defines which ports and protocols are open to external traffic and which hosts are accepted.
VirtualService — The routing table. Replaces Ingress rules but is far more powerful. Supports percentage-based traffic splits, fault injection, retries, and timeouts — all declaratively in YAML.
DestinationRule — Defines policies for traffic after it reaches a service. Controls load balancing strategy, connection pool limits, and circuit breaker thresholds.
AuthorizationPolicy — The security enforcement layer. Defines which service identity (SPIFFE/SVID-based) is allowed to call which other service, on which path, and using which method. This is your replacement for IP-based firewall rules.
PeerAuthentication — Configures mTLS mode (STRICT, PERMISSIVE, or DISABLE) per namespace or workload. Use STRICT in production to enforce encrypted-only communication.
10. Should You Use Istio?
Istio is genuinely powerful — but it is also genuinely complex. Here's an honest assessment:
✅ Use Istio If You...
- Run microservices at scale (10+ services)
- Need service-to-service encryption (compliance requirement)
- Need fine-grained access control between services
- Require built-in distributed tracing and service topology
- Are operating in a regulated industry (finance, healthcare, government)
- Need advanced traffic management for zero-downtime deployments
⚠️ Think Twice If You...
- Run a small number of services (1–5)
- Have a small team without platform engineering capacity
- Don't have compliance requirements driving mTLS adoption
- Are still early in your Kubernetes journey
For small projects, a lightweight ingress controller implementing Gateway API may be sufficient and far easier to operate. Istio shines brightest in large, security-sensitive, compliance-heavy environments.
11. Final Thoughts
The end of life for NGINX Ingress Controller is genuinely a forcing function — and it's worth using it as an opportunity to re-evaluate your traffic management strategy holistically.
The landscape has evolved significantly:
- Gateway API brings a clean, standardized approach to ingress with proper role-based separation
- Istio brings a full-mesh security model that addresses threats NGINX was never designed to handle
If you're running microservices in any security-sensitive context — banking, fintech, healthcare, or any environment with compliance requirements — Istio is not just a NGINX replacement. It's a fundamentally different security posture for your cluster.
The core shift in mindset is this:
NGINX watched your front door. Istio watches every door — including the ones between your own services.
That's the shift that matters when you're protecting customer card data, PII, or any workload where a single compromised service should not mean the entire cluster is compromised.
References & Further Reading
- Istio Official Documentation
- Istio Architecture Overview
- Kubernetes Gateway API Spec
- Envoy Proxy Documentation
- CNCF Istio Project Page
- PCI-DSS v4.0 Requirements
Have questions about migrating from NGINX Ingress to Istio? Drop a comment below — happy to discuss specific migration patterns, ambient mode (Istio's sidecarless future), or how to structure your AuthorizationPolicies for your use case.
If this post helped you, follow for more content on Kubernetes, platform engineering, and cloud-native security.