How did that sidecar get there?

When I began investigating sidecars and service meshes I needed to understand how a key feature, automatic sidecar injection, worked. If I use something like Istio or Consul , when I deploy my application container, an Envoy container suddenly appears preconfigured in the same pod. Huh? How? This led me to start digging….

For those who are unaware, a sidecar container is a container that you deploy alongside your application containers to assist the application in some way. A few examples of this include a proxy to help manage traffic and terminate TLS, a container for streaming logs and metrics, or a container that scans for security issues. The idea is to isolate and encapsulate the various concerns of a full application from the business logic itself by using separate containers for each function.

Before I continue, I want to set some expectations. The point of this article is not to explain the intricacies or use cases of Docker , Kubernetes , service meshes, etc., but rather to clearly illustrate one powerful method for extending these technologies. This article is for those already somewhat familiar with using these technologies or, at the very least, done a good amount of reading. You will need a machine with docker and Kubernetes already setup to try this. Easiest method: https://docs.docker.com/docker-for-windows/kubernetes/ (works on docker for mac as well)

Overview

First, let’s take apart Kubernetes a bit.

When you want to deploy something to Kubernetes, you need to send an object to the kube-apiserver. The way most folks do that is by passing arguments or a YAML file to kubectl. When you do this, the API server goes through a handful of stages before pushing the data to etcd and getting things scheduled:

This is the pipeline we need to understand in order to understand how sidecar injection works. Specifically, we need to look at Admission Control , which is where Kubernetes validates and, if needed, alters the objects before they are persisted. Kubernetes also allows the registration of webhooks , which can perform custom validation and mutation.

However, this process of creating and registering custom hooks is not tremendously straightforward or well documented. I had to spend several days reading and rereading documents and reverse engineering both Istio and Consul code. I honestly spent at least half a day doing random trial and error when it came to coding some of the API response.

So, once I finally had this working, I thought it would be unconscionable not to share it with all of you. It’s simple and powerful. The lack of a clear guide was the only thing missing!