Service Mesh

Controls how requests flow between services, decoupling routing logic from application code.

• Load Balancing: Distributes requests across healthy instances using algorithms like round-robin, least connections, or ring hash.
• Traffic Splitting: Enables canary deployments and A/B testing by routing a percentage of traffic to different service versions.
• Circuit Breaking: Stops cascading failures by ejecting unhealthy hosts from the load balancing pool after a configurable error threshold.
• Retries and Timeouts: Automatically retries failed requests with exponential backoff and enforces maximum request duration to prevent resource exhaustion.

Provides deep visibility into service-to-service communication without instrumenting application code.

• Distributed Tracing: Injects headers to propagate trace context across service boundaries, enabling end-to-end latency analysis with tools like Jaeger or Zipkin.
• Metrics Collection: Exports golden signals—latency, traffic, errors, and saturation—for every service interaction at the proxy level.
• Access Logging: Records every request with metadata including source, destination, response code, and duration for audit and debugging.

Enforces zero-trust networking principles through cryptographic identity and policy-based access control.

• Mutual TLS (mTLS): Automatically provisions and rotates X.509 certificates for every workload, encrypting all east-west traffic and authenticating both client and server.
• Authorization Policies: Enforces fine-grained access control based on workload identity, namespace, or custom attributes, implementing least privilege at the network layer.
• Identity Federation: Integrates with SPIFFE standards to assign cryptographically verifiable identities to services, decoupling identity from network location.

Implements patterns that prevent transient failures from becoming catastrophic outages.

• Bulkheading: Isolates failure domains by partitioning connection pools and resources per upstream service.
• Outlier Detection: Continuously monitors host health and proactively ejects instances exhibiting elevated error rates or latency.
• Rate Limiting: Enforces per-service or per-client request limits at the proxy layer to protect downstream services from overload.
• Fault Injection: Deliberately introduces delays or errors to test system resilience in production, validating that fallback mechanisms function correctly.

Two primary deployment models exist for implementing a service mesh data plane.

• Sidecar Proxy: A dedicated proxy container (such as Envoy or Linkerd-proxy) is deployed alongside each application pod. This pattern provides strong isolation but consumes additional resources per instance.
• Ambient Mesh: A newer approach using a shared node-level proxy for Layer 4 security and optional per-pod proxies for Layer 7 policies. Reduces resource overhead by eliminating the need for a sidecar on every workload.
• Control Plane: The management layer (such as Istiod or Linkerd's controller) distributes configuration, manages certificate rotation, and aggregates telemetry from all proxies.

Manages traffic entering and leaving the mesh perimeter with consistent policy enforcement.

• Ingress Gateway: Acts as the single entry point for external traffic, terminating TLS, performing authentication, and routing requests to internal services based on host headers or paths.
• Egress Gateway: Controls outbound traffic from the mesh to external services, enforcing allowlists and providing a fixed source IP for firewall rules.
• Gateway API: A Kubernetes-native specification that defines gateway resources, enabling declarative configuration of ingress and mesh-to-external routing.

The management and security inspection of data packets moving laterally between servers, containers, or workloads within a data center. Unlike north-south traffic (client-to-server), east-west traffic constitutes the majority of data center volume and is the primary attack vector for lateral movement.

• Service meshes enforce micro-segmentation on east-west paths
• Every hop is authenticated and authorized via mTLS and policy
• Provides granular observability into inter-service dependencies

The network component that activates, executes, and monitors access decisions for a specific connection. In a service mesh, the sidecar proxy functions as the PEP, enforcing rules received from the Policy Decision Point (PDP) .

• Acts as the 'gate' that physically allows or denies traffic
• Must operate with minimal latency to avoid degrading service performance
• Decoupled architecture allows policy updates without proxy restarts