A platform team adds a service mesh to a cluster and observes that a lightweight proxy container is now injected alongside every application container in each Pod, intercepting all inbound and outbound traffic for that Pod. What is this per-Pod proxy pattern called, and what does it fundamentally allow the mesh to do?
- AIt is the DaemonSet pattern, which runs one shared proxy per node so that all Pods on that node route through a single node-level agent.
- BIt is the sidecar proxy pattern, which lets the mesh handle traffic concerns such as encryption, retries and telemetry without changing application code. Correct
- CIt is the init-container pattern, which runs once before the application starts to configure networking and then exits before traffic flows.
- DIt is the ambassador pattern, which exposes the application to external clients by proxying only inbound requests from outside the cluster.
Why A is wrong: Tempting because a node-level proxy does exist in some designs and DaemonSets run one Pod per node, but the described per-Pod injected proxy is a sidecar, not a single shared node agent.
Why B is correct: Correct: a service mesh injects a sidecar proxy into each Pod so the proxy transparently intercepts traffic and applies policy, meaning features like mTLS, retries and metrics are added without modifying the app.
Why C is wrong: Tempting because meshes do use an init container to set up iptables rules, but that container exits at startup and cannot intercept live traffic, so it is not the proxy that carries ongoing requests.
Why D is wrong: Tempting because an ambassador proxy is a real sidecar variant, but it handles a narrow outbound-representation or edge role and does not describe the mesh proxy intercepting all inbound and outbound Pod traffic.