service mesh

Evaluate identity, traffic policy and telemetry against measured proxy overhead and operating responsibilities, then test the authorization boundary.

Init containers are the easy half. The hard half is why plain sidecars race your app at both ends of the pod's life, and what restartPolicy Always changes about that.

Yes, the proxy moves: one L4 agent per node, eBPF in-kernel, waypoints only where L7 policy demands. The scored answer quantifies the sidecar bill, compares where each architecture lands the proxy, and names migration risks.

A Job with a sidecar was broken by design for years: the workload finishes, the proxy does not, and the pod never terminates. Native sidecars fix it by making the container an init container that keeps running.

Choose by trust boundary, not fashion: mesh-issued mTLS inside a cluster, audience-bound tokens across teams and clouds, both together at scale. Static shared secrets are the thing being replaced.

Turning on strict mTLS across two hundred services in one change breaks everything that talks to something outside the mesh. Permissive mode exists so the migration can be observed instead of guessed at.