A sidecar proxy is a helper container deployed alongside each application container in Kubernetes. It intercepts all inbound and outbound network traffic, applying policies (mTLS, retries, rate limits) without application modification. Envoy is the dominant sidecar proxy, used by Istio, AWS App Mesh, and Consul Connect.
The sidecar pattern deploys a proxy container (typically Envoy) in the same Kubernetes pod as the application container. Kubernetes iptables rules redirect all pod traffic through the sidecar. The application connects to localhost – unaware that a proxy is intercepting, encrypting, and routing its traffic. The sidecar handles: TLS origination and termination (app speaks plaintext to localhost, sidecar encrypts to the network), health checking of upstream services, retries with exponential backoff, circuit breaking, request timeout enforcement, and metrics/tracing injection. Sidecars add resource overhead: ~50MB RAM and ~0.5 vCPU per pod for Envoy. In large clusters (1000+ pods), this overhead is significant. Alternatives: ambient mesh (Istio ambient mode uses per-node proxies instead of per-pod) and eBPF-based meshes (Cilium) that move functionality into the kernel, eliminating sidecar overhead entirely.
Service Mesh
A service mesh is a dedicated infrastructure layer for service-to-service communication in microservices. Sidecar proxies (Envoy) handle mTLS, retries, circuit breaking, and observability transparently – without application code changes. Istio, Linkerd, and Consul Connect are the major implementations.
Circuit Breaker
A circuit breaker stops calling a failing downstream service after a threshold of errors, preventing cascade failures. States: Closed (normal flow), Open (all calls fail-fast without attempting), Half-Open (limited test calls to check recovery). Prevents a slow/failing service from consuming all caller resources and propagating failure upstream.