Service mesh and the sidecar

Key points

• A sidecar proxy runs in the same pod. All traffic in and out of your container passes through it, with no change to your code.
• That buys mTLS, timeouts, retries, outlier ejection, traffic splitting and per-call metrics in one place, for every language you run.
• The control plane (Istio, Linkerd) pushes policy to the sidecars; the data plane is the proxies actually carrying the traffic.
• It is not free: one extra hop each way, more memory per pod, and a second network to debug when something is slow.
• A mesh and Resilience4j overlap. Choose one place for retries, or a retrying app behind a retrying mesh multiplies load during an incident.

Example

# Refuse plaintext traffic anywhere in the namespace.
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: shop
spec:
  mtls:
    mode: STRICT
---
# Timeouts and retries for calls to inventory - the app configures neither.
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: inventory
  namespace: shop
spec:
  hosts:
    - inventory
  http:
    - timeout: 2s
      retries:
        attempts: 2
        perTryTimeout: 800ms
        retryOn: 5xx,connect-failure       # never retry a plain timeout on a POST
      route:
        - destination:
            host: inventory

A mesh gives every service the same networking behaviour without a shared library.