Sidecar
Deploying a helper process alongside the main application in the same unit, to supply cross-cutting behaviour without changing the application.
The sidecar shares the lifecycle and network namespace of the main container but is developed and upgraded separately. Typical jobs: TLS termination, mTLS between services, proxying and retries, log shipping, secret rotation, configuration reload.
The attraction is language independence — one sidecar implementation serves a Java service, a Python service and a Go service identically, which is exactly what a polyglot estate needs, and it lets the platform team ship policy without asking every application team to upgrade a library.
The cost is real: an extra process per pod, extra network hops, extra memory, and a second thing to debug when latency is unexplained. Service meshes are sidecars applied estate-wide, with the resource cost multiplied accordingly.