Service Mesh Fundamentals — Vocabulary

The data plane (Envoy sidecars) handles real traffic; the control plane (istiod) handles configuration distribution — these are completely separate concerns.

This separation is fundamental to service mesh architecture. istiod translates your Istio YAML resources into xDS (Envoy discovery service) configuration and pushes it to the relevant sidecar proxies via gRPC streaming. When a request flows from service A to service B, it goes: A's container → A's Envoy sidecar → network → B's Envoy sidecar → B's container. istiod is never in that path — it only tells the sidecars what to do.

Key vocabulary:
• data plane — the Envoy sidecar proxies; handle actual request traffic
• control plane — istiod; distributes xDS config; no traffic flows through it
• xDS — Envoy's discovery service API; how control plane pushes config to data plane

Sidecar injection uses a mutating admission webhook to transparently add the Envoy container — the application code requires zero changes.

When a pod is created in an injection-enabled namespace, the Kubernetes API server calls Istio's webhook before scheduling. The webhook patches the pod spec: it adds the istio-proxy (Envoy) container and an init container that sets up iptables rules redirecting all inbound/outbound traffic through the proxy ports. The application sees only localhost — it has no idea a proxy is intercepting its traffic.

Key vocabulary:
• mutating admission webhook — intercepts pod creation and modifies the pod spec before it is saved
• iptables rules — redirect traffic to/from Envoy's port (15001 outbound, 15006 inbound) transparently
• istio-proxy — the name of the Envoy sidecar container added by Istio injection

East-west = internal service-to-service; north-south = external traffic at the cluster boundary — the service mesh's primary value is in the east-west layer.

The naming comes from network diagrams: services in a row communicate horizontally (east-west); traffic entering from outside comes from the top (north). The Istio service mesh excels at east-west: it applies mTLS, retries, timeouts, and observability between your microservices automatically. North-south traffic (from a user's browser or an external API) enters via the Istio Ingress Gateway, which is a specialized Envoy instance that bridges external to internal.

Key vocabulary:
• east-west traffic — internal, service-to-service; managed by sidecar proxies
• north-south traffic — external-to-cluster or cluster-to-external; managed by the Ingress/Egress Gateway
• Ingress Gateway — Istio resource defining how external traffic enters the mesh

Ambient mesh reduces per-pod overhead by moving from per-pod sidecars to per-node ztunnel + on-demand waypoint proxies for L7 features.

In a high-density cluster with 500 pods, the sidecar model means 500 Envoy containers (each using ~50MB RAM minimum). Ambient mode deploys one ztunnel daemonset per node — far fewer proxy instances. The catch: L7 features (retries, header-based routing, fault injection) require deploying a waypoint proxy per namespace or service. So ambient mode is simpler and cheaper for services that only need mTLS and basic L4 policies, but adds a waypoint proxy step for services needing L7 traffic management.

Key vocabulary:
• ztunnel — per-node proxy in ambient mode; handles L4 mTLS and basic authorization
• waypoint proxy — per-namespace/service proxy in ambient mode; handles L7 features on demand
• ambient mesh — Istio's sidecar-less architecture; generally available since Istio 1.22

One of the key values of a service mesh is transparent mTLS — zero application code changes required.

When mTLS PeerAuthentication is enabled, the Envoy sidecars handle the full TLS handshake transparently. Service A's application sends a plain HTTP request to service B. Service A's Envoy intercepts it, wraps it in mTLS, and forwards it to Service B's Envoy, which terminates the TLS and delivers plain HTTP to B's container. Both application containers continue to use plain text internally. This is a fundamental selling point of the mesh: you get encryption and identity verification with no application refactoring.

Key vocabulary:
• transparent mTLS — TLS handled by sidecars; app code uses plain HTTP
• PeerAuthentication — Istio resource configuring mTLS mode (STRICT/PERMISSIVE/DISABLE) per namespace
• STRICT mode — all traffic must use mTLS; plain-text connections are rejected