Good news everyone, sidecars are cool again! The long-awaited merge of "sidecar KEP" in Kubernetes 1.28 officially introduces sidecars to the Kubernetes API and makes some major improvements to how they work.
In this post William Morgan walks you through everything you need to know: what sidecars are, what's good and what's bad about them, and what changes in Kubernetes 1.28—all from the perspective of a sidecar enthusiast and highly opinionated service mesh person.
Pretty good clear value proposition for sidecars, good intro:
> But why is the idea that a container can run next to another container so interesting and so deserving of a special name? Because the sidecar pattern provides something really powerful: a way of augmenting an application at runtime without requiring code changes, while running in the same operational and security context as the application itself. That statement is key to understanding the power of sidecars and, I think, the power of Kubernetes's pod model.
3 comments
[ 2.9 ms ] story [ 19.3 ms ] threadIn this post William Morgan walks you through everything you need to know: what sidecars are, what's good and what's bad about them, and what changes in Kubernetes 1.28—all from the perspective of a sidecar enthusiast and highly opinionated service mesh person.
> But why is the idea that a container can run next to another container so interesting and so deserving of a special name? Because the sidecar pattern provides something really powerful: a way of augmenting an application at runtime without requiring code changes, while running in the same operational and security context as the application itself. That statement is key to understanding the power of sidecars and, I think, the power of Kubernetes's pod model.