Kubernetes Networking & Services
Service Mesh — Istio and Linkerd Overview
Sidecar patterns, mutual TLS, traffic shaping, and telemetry.
Interview: Expect questions on microservice operations. You should know what a Service Mesh solves (mTLS, canary releases, distributed tracing, circuit breakers) without modifying application code, and how the control plane (Istiod) manages Envoy sidecar proxies.
The Observability & Security Challenge
As a cluster scales to support hundreds of microservices, managing network traffic becomes increasingly complex. Implementing encryption in transit (TLS), distributed tracing, rate limiting, and canary traffic routing inside each service's code requires significant developer overhead.
A **Service Mesh** is a dedicated infrastructure layer that abstracts these network operations away from application code.
Sidecar Proxy Architecture
A Service Mesh operates by deploying a helper container proxy (commonly **Envoy**) alongside each application container in a Pod. This architecture splits into two planes:
- Control Plane (e.g. Istiod): Compiles routing rules, security policies, and cryptographic certificates, distributing them to the active sidecar proxies.
- Data Plane: Lightweight Envoy proxies injected into application Pods. All network traffic entering or leaving the application container is intercepted and routed through these proxies.
Core Service Mesh Capabilities
- Mutual TLS (mTLS): Automatically encrypts and authenticates all service-to-service communications, enforcing zero-trust transit security.
- Traffic Splitting: Dynamically routes traffic based on percentages (e.g., routing 10% of traffic to a new version for canary testing).
- Resilience & Fault Injection: Implements retries, timeouts, rate limits, and circuit breakers (halting connections to failing pods to prevent cascading failures).
- Distributed Telemetry: Generates trace metrics, latencies, and service dependency maps without requiring changes to application code.