The sidecar pattern deploys a second, helper container in the same pod/host as your main application — handling concerns like traffic proxying, log shipping, or certificate rotation — so that logic doesn’t need to be built into every application’s own codebase in every language your org uses. A service mesh’s per-instance proxy is the most common real-world example of a sidecar.
Worked example: deploy a helper container alongside the main app in the same pod, sharing its network and lifecycle, to handle a cross-cutting job (proxy, log shipper, secrets agent) without changing the app. Gotcha: the sidecar competes for the pod’s CPU/memory and shares its blast radius — a crashing sidecar can take the app with it — and startup ordering matters (the app may start before its proxy sidecar is ready, dropping early requests).