Comparison
SidecarvsSidecar proxy
Sidecar
a second container next to your application handles TLS, logging or metrics, and your code was never changed.
A container that runs alongside the application in the same pod, providing a cross-cutting capability out of process. It is the mechanism behind service meshes, log shippers and secret-fetching agents, and its appeal is that a platform team can ship a capability to every service without touching anyone's code. The costs are equally real: it doubles the container count, it consumes requests and limits of its own, and startup and shutdown ordering between the two becomes your problem.
Full entry →Sidecar proxy
every connection your service makes actually goes through a proxy in the same pod, which is where the retries and the TLS happen.
The per-workload proxy that intercepts inbound and outbound traffic, giving a mesh its identity, encryption, routing and telemetry without application changes. It is the data plane of a service mesh, and it is why mesh features apply uniformly to services written in five languages. Its costs are a hop of latency, memory and CPU on every pod, and a genuinely difficult startup and shutdown ordering problem with the application beside it.
Full entry →