Stage 5 · Platform
Networking, Storage & Service Mesh
Service Mesh
Istio, Linkerd, Cilium Service Mesh — mTLS, traffic management.
Service Mesh Overview
A service mesh adds a dedicated infrastructure layer for service-to-service communication. It handles mTLS, traffic routing, load balancing, retries, and observability without changing application code. The mesh consists of a control plane (configuration) and data plane (proxies).
| Feature | Istio | Linkerd | Cilium Mesh |
|---|---|---|---|
| Proxy | Envoy | linkerd2-proxy (Rust) | eBPF (no proxy) |
| mTLS | Yes | Yes | Yes |
| Traffic mgmt | Full | Basic | Full |
| Complexity | High | Low | Medium |
| Performance | Good | Best | Best |
Sidecar Proxy Model
Traditional service meshes inject a sidecar proxy (Envoy) into every pod. All inbound and outbound traffic flows through the proxy. The proxy handles mTLS, load balancing, retries, and telemetry. This adds latency (1-2ms per hop) and resource overhead.
apiVersion: v1
kind: Pod
metadata:
name: my-app
labels:
app: my-app
annotations:
sidecar.istio.io/inject: "true"
spec:
containers:
- name: app
image: my-app:1.0
ports:
- containerPort: 8080
# Istio proxy is injected automatically:
# - name: istio-proxy
# image: istio/proxyv2:1.20.0
# ports:
# - containerPort: 15006 # inbound
# - containerPort: 15001 # outbound
# - containerPort: 15090 # metricsThe sidecar injection webhook automatically adds the Envoy proxy to pods with the right label. Traffic is redirected through the proxy using iptables rules (REDIRECT). The proxy communicates with the Istio control plane (istiod) for configuration.
Mutual TLS
mTLS encrypts and authenticates all service-to-service traffic. Each service gets a certificate from the mesh CA. When two services communicate, they establish a TLS connection and verify each other's identity. This provides zero-trust networking without application changes.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production
spec:
mtls:
mode: STRICT # Require mTLS for all traffic in namespace
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: api-policy
namespace: production
spec:
selector:
matchLabels:
app: api
rules:
- from:
- source:
principals: ["cluster.local/ns/production/sa/web-frontend"]
to:
- operation:
methods: ["GET", "POST"]
paths: ["/api/v1/*"]PeerAuthentication STRICT mode rejects any plaintext traffic. AuthorizationPolicy restricts which services can access api — only web-frontend SA can call GET/POST on /api/v1/*.
Each service's identity is its SPIFFE ID: spiffe://cluster.local/ns/<namespace>/sa/<service-account>. The mesh CA issues short-lived certificates (24h default) for these identities. Certificate rotation is automatic and transparent.
Traffic Management
Service meshes provide fine-grained traffic control: canary deployments, traffic splitting, retries, timeouts, circuit breakers, and fault injection. This is configured through mesh CRDs, not application code.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: api-routing
spec:
hosts:
- api-service
http:
- route:
- destination:
host: api-service
subset: stable
weight: 90
- destination:
host: api-service
subset: canary
weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: api-destinations
spec:
host: api-service
subsets:
- name: stable
labels:
version: v1
- name: canary
labels:
version: v2
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
h2UpgradePolicy: DEFAULT
maxRequestsPerConnection: 10VirtualService routes 90% of traffic to stable (v1) and 10% to canary (v2). DestinationRule defines the subsets and traffic policy. You can gradually shift weight as you gain confidence in the canary.
Mesh Observability
Service meshes provide built-in observability: request metrics (latency, error rate, throughput), distributed traces, and access logs. Envoy proxies emit detailed telemetry without any application instrumentation.
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: mesh-default
namespace: istio-system
spec:
metrics:
- providers:
- name: prometheus
tracing:
- providers:
- name: jaeger
randomSamplingPercentage: 10
accessLogging:
- providers:
- name: stdoutThis configures the mesh to export metrics to Prometheus, sample 10% of traces to Jaeger, and log access to stdout. The mesh gives you RED metrics (Rate, Errors, Duration) for every service automatically.
Cilium eBPF Mesh
Cilium replaces sidecar proxies with eBPF programs in the kernel. This eliminates the proxy overhead — no extra container, no context switches, no additional memory. Cilium Service Mesh provides mTLS, traffic management, and observability with near-native performance.
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: api-policy
spec:
endpointSelector:
matchLabels:
app: api
ingress:
- fromEndpoints:
- matchLabels:
app: web
toPorts:
- ports:
- port: "8080"
protocol: TCP
egress:
- toEndpoints:
- matchLabels:
app: database
toPorts:
- ports:
- port: "5432"
protocol: TCPCiliumNetworkPolicy supports L3/L4/L7 filtering. The endpointSelector uses pod labels directly. Cilium compiles these policies into eBPF programs that run in the kernel, providing wire-speed enforcement.
Start with a permissive mTLS mode — accepts both plaintext and mTLS traffic. This lets you gradually enable encryption without breaking existing services. Once all services have sidecars, switch to STRICT mode.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.