Ingress & Service Mesh

How does an external user hit your K8s cluster? And how do internal services talk securely? We use Ingress Controllers for the "Front Door" and Service Mesh for internal security.

1. Ingress Controller (Nginx / ALB)

Instead of creating an expensive LoadBalancer for every single service, you create ONE Ingress Controller. It acts as an internal Nginx that routes traffic based on the URL path (e.g., /api -> API service, /web -> Web service). It also handles **SSL/TLS Termination** in one place.

2. The Service Mesh (Istio)

As you grow to 50+ microservices, you need internal security and metrics. **Istio** injects a "Sidecar" proxy (Envoy) into every pod. It provides:

• mTLS: Automatic encryption of all internal traffic.
• Canary Progressions: Send 1% of traffic to v2 of your service.
• Retries/Timeouts: Automatically handle internal network drops.

4. Interview Mastery

Q: "When is a Service Mesh an Overkill?"

Architect Answer: "Service Mesh adds significant resource overhead (every pod gets a 50MB+ sidecar) and massive complexity to your K8s manifests. If you only have 5-10 services, you can handle retries and security in your application code. You should only adopt a Service Mesh when you reach 'Complexity Debt'—where the cost of managing internal traffic manually is higher than the cost of running Istio."