Service Mesh Platform  ·  View 02 of 31  ·  1 · Context and scope

High-Level Architecture

Five stages from declared intent to local enforcement and back, with the one rule that shapes all of them.

Editable source SVG draw.io All views
Declare Intent repositories Forgejo · 3 repos Argo Rollouts owns canary weights Admit Policy checks OPA · impact replay Admission guards Gatekeeper · VAP Compile istiod scoped · delta xDS SPIRE server attested SVIDs Enforce locally Envoy sidecar mTLS · authz · routes East-west gateway SNI passthrough Observe OTel collector bounded buffers Drift exporter intent sha per proxy effective weights High-Level Architecture — Intent In, Local Enforcement Out Data store Application we own Decision point Security / platform Interface / broker event / async Nothing left of the data plane is consulted while a request is forwarded. Every arrow into it is a push that can stop without stopping traffic. v 1.0 · owner Platform Networking Architecture · date 2026-09

Decisions

  • Intent is declared in Git and checked twice: by policy checks before merge, and by admission guards when it reaches a cluster. The second check exists because the first one can be bypassed by anyone with kubectl.
  • The data plane stage is the only one on a request path. Everything to its left pushes; nothing to its left is pulled from during a call.
  • The loop closes through observation. The rollout controller reads the traffic share the proxies actually applied, which is how a weight change that never landed gets noticed.

Why this shape lasts

  • Each stage is a replaceable product behind a stable interface: Git, the Kubernetes API, xDS, SPIFFE and OTLP. Istio, SPIRE or Argo can each be swapped without redrawing this page.

Risks

  • istiod also serves the sidecar injector. Losing it blocks new meshed pods as well as new config; view 21 shows that this is survivable, and view 31 how injection fails per namespace.