Service Mesh Sidecar

The sidecar's primary function is to intercept all network traffic to and from its attached service. It acts as a Layer 7 (application layer) proxy, enabling sophisticated traffic management policies without modifying the service's code.

• Transparent Proxying: Uses techniques like iptables rules or eBPF to redirect traffic destined for the service's port to the proxy's port.
• Intelligent Routing: Applies rules for load balancing (round-robin, least connections), traffic shifting (canary deployments, A/B testing), and failure recovery (retries, timeouts).
• Example: In Istio, the Envoy sidecar can route 10% of traffic to a new service version (v2) while 90% goes to the stable version (v1), based on VirtualService configurations.

The sidecar implements resilience patterns at the network edge, protecting services from upstream failures and preventing cascading outages.

• Circuit Breaking: Stops sending requests to an instance or service that is failing, allowing it time to recover. It monitors metrics like consecutive errors or request queue length.
• Retry Logic: Automatically retries failed requests with configurable policies (e.g., exponential backoff with jitter).
• Timeout Management: Enforces deadlines for outbound requests to prevent hung connections from consuming resources.
• Outlier Detection & Ejection: Identifies unhealthy service instances (e.g., those returning 5xx errors) and temporarily removes them from the load balancing pool.

The sidecar provides a uniform security layer, enabling zero-trust networking principles where no service is inherently trusted.

• Mutual TLS (mTLS): Automatically encrypts all service-to-service traffic. The sidecar handles TLS certificate issuance, rotation, and validation, providing strong identity for each service.
• Authentication: Verifies the identity of the calling service based on its presented certificate (SPIFFE ID).
• Authorization: Enforces fine-grained access control policies (e.g., "service frontend can call GET on service backend/api/v1") using tools like Istio's AuthorizationPolicy.
• Example: A sidecar can be configured to reject any request from a service in the development namespace to a service in the production namespace.

The sidecar is the primary source of uniform telemetry data, as it sees every request and response. It generates the three pillars of observability.

• Metrics: Collects RED metrics (Requests, Errors, Duration) and golden signals (traffic, latency, saturation, errors). These are exported to systems like Prometheus.
• Distributed Tracing: Automatically injects and propagates trace context headers (e.g., W3C Trace Context, B3) and reports spans to backends like Jaeger or Zipkin, providing a full view of request flow.
• Access Logs: Logs detailed information about every HTTP/gRPC request, including headers, response codes, and timing. This data is often sent to a centralized log aggregator.

Sidecars can bridge communication gaps between services using different protocols, acting as a universal adapter.

• HTTP/gRPC Bridging: Can accept an HTTP/1.1 request from a legacy service and translate it to a gRPC (HTTP/2) call for a modern backend, and vice-versa.
• WebSocket Management: Handles the long-lived connections and protocol upgrades for WebSocket traffic, providing load balancing and observability even for stateful streams.
• TCP Proxying: While optimized for Layer 7, sidecars can also perform basic Layer 4 (TCP) proxying for non-HTTP/gRPC services, offering basic connectivity and metrics.

The sidecar acts as the runtime enforcement agent for declarative policies defined in the service mesh's control plane.

• Rate Limiting: Enforces quotas on how many requests a service can make or receive within a time window, protecting backends from being overwhelmed.
• Quota Management: Interfaces with external quota services (like Mixer in Istio 1.5) to check resource usage.
• Request/Response Transformation: Can modify headers (add, remove, rewrite), mirror traffic to a shadow service for testing, or even transform the body of requests/responses (e.g., JSON to Protobuf).
• Centralized Control: All these policies are defined centrally (e.g., in Istio's Gateway, VirtualService, and DestinationRule resources) and pushed dynamically to the sidecars.

A core security feature enforced by the service mesh sidecar, where both the client and server sides of a connection authenticate each other using TLS certificates. This provides strong service-to-service identity and encrypts all traffic within the mesh.

• Process: The control plane's certificate authority (CA) automatically issues and rotates short-lived certificates for each service/workload. The sidecar proxies handle the TLS handshake transparently to the application.
• Benefit: Enables a zero-trust network model where no service is inherently trusted, and all communication is authenticated and encrypted.