Around the 1.29 release, I started hearing lots of questions about sidecars. What are they? What’s this thing about them in 1.29? Why is it a big deal? Let’s get everyone up to speed with a brief Intro to Sidecars!
What’s in a “Pod”?
The term “sidecar” likely originated as a handy phrase to describe a natural pattern arising from how Kubernetes manages containers. Kubernetes manages containers by abstracting them away using its own concept of “the pod.” A pod in Kubernetes consists of one or more containers. Remember, our ultimate goal is to run some application. (You can find a deeper dive into Kubernetes pods in my intro to Kubernetes post.) In Kubernetes, applications are packaged into containers. Often, one container = one app. So why can a pod host more than one container? What do the other containers in a pod do?
Sharing is caring?
The key factor in deciding whether to put your containers in the same pod or separate ones, is resources. Two containers in the same pod share the same storage, network, and even the same IP address. Essentially, when two containers share a pod, Kubernetes treats them as a single unit. They’ll be scaled together, they have unrestricted access to the same data, and they’re called together. This both creates a security risk and opens up some interesting use cases.
Istio by Example has a great explanation of how Istio uses a “sidecar” container to ensure mTLS is used to secure communications between clients and servers (for example). Think of the boxes in this diagram as pods, the “server” or “client” boxes as the main app containers, and the hexagons as sidecar containers. Illustration from https://istiobyexample.dev/mtls/.
We’ve all likely seen a warning saying “Stop! Your connection is not secure! Someone could be stealing your data!” A “man in the middle” attack is one where someone maliciously intercepts data, but the same concept can be used in useful ways too. Service meshes often use an extra container (a sidecar) in the pod to intercept traffic intended for the main application. This allows for useful functionalities like enforcing mTLS encryption without changing the application itself, or performing checks to ensure traffic originates from a known safe IP range.
Containers within the same pod also share storage. Service meshes again leverage this storage-sharing capability of containers that share a pod. By accessing the same storage used by the main application, a sidecar pod can gather log data from the main application, again, without modifying the application itself.
Introducing the “Sidecar”
This pattern of using an extra container to perform tasks that it is uniquely capable of due to its close proximity to the main application, is what we call “the sidecar pattern.” This “extra container” is the “sidecar.” It’s called that because, like a sidecar on a motorcycle, it’s not the main event- it’s not doing the heavy lifting, but it does add on some useful functionality. It’s a reasonably descriptive name for this common pattern.
So if this “sidecar” pattern is so natural to the way Kubernetes does things, the question is, why aren’t sidecars “real?” Because, they haven’t been real. “A sidecar” is just the name used to describe this particular use case. “Sidecar” is not the name of an actual resource in Kubernetes. This is why sidecars are so exciting in Kubernetes 1.28 & 1.29: they’re *kind of* becoming real.
Sidecars in Kubernetes
Since 2018, there has been a Kubernetes Enhancement Proposal (KEP) around the idea of making sidecars “real,” or at least “native,” in Kubernetes. Kubernetes 1.28 finally added the concept of “native sidecar containers” in alpha. This feature, tracked in KEP-753, makes the concept of sidecars more “native” in Kubernetes, but it stops short of making them “real.” Rather than creating yet another resource in Kubernetes (which has a whole host of issues, not to mention adding complexity to Kubernetes resource types), the Kubernetes maintainers instead opted to add functionality to pods that makes them more sidecar-friendly. The blog post about the enhancement describes it like this:
“The built-in sidecar feature solves for the use case of having a lifetime equal to the Pod lifetime and has the following additional benefits: provides control over startup order, doesn’t block Pod termination”
Essentially, “sidecar containers” in Kubernetes are a specific use case for what Kubernetes actually calls init containers. The “sidecar” is just an init container that has the same life as the application it’s attached to. This init container functionality is enabled by default in Kubernetes v1.29. The “sidecar pattern” is so common, that this new functionality is described in the Kubernetes docs on its own page titled “Sidecar Containers.”
There still isn’t a “sidecar” resource in Kubernetes. But as of 1.28 and 1.29, this very popular pattern that has been in use since at least 2015, is finally natively supported and more officially recognized in Kubernetes.