Comparison
PodvsSidecar
Pod
two containers share an IP address and a lifetime, and are scheduled onto the same node together or not at all.
The smallest schedulable unit: one or more containers sharing a network namespace, storage volumes and a fate. The reason it exists rather than scheduling containers directly is that some helper processes must be co-located with the application — a proxy, a log shipper — and giving them a shared address and lifetime makes that a first-class idea. It is also disposable by design: a pod is never repaired, only replaced.
Full entry →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 →