Author: Haim Helman

Kubernetes 1.17 became generally available on Dec. 9 bringing with it a host of new stable enhancements, but what’s perhaps more interesting is not what’s in that release, but what’s missing.

The release notes identify 22 enhancements in total, which is half what was originally expected to debut in the release. Among the enhancements that were originally planned for the release but didn’t end up making it into Kubernetes 1.17 is full support for sidecar containers, but don’t worry, it’ll likely come together in time for Kubernetes 1.19.

A sidecar container is one that is deployed in a pod alongside other containers, enabling a proxy that can be used for different purposes, such as enabling a service mesh for connectivity.

The Sidecar KEP

When other software projects add new capabilities they are typically referred to as ‘features’ but Kubernetes is not a typical software project. In Kubernetes, new features are commonly referred to as – Enhancements. Going a step further, within the Kubernetes development community, all new features need to first be defined and outlined in a proposal known as a Kubernetes Enhancement Proposal (KEP).

The KEP for sidecar containers was first submitted in May 2018 and has been the subject of debate and development ever since. The KEP notes that Kubernetes users have informally been using the sidecar approach already, though there are issues that have come up, which the KEP aims to address.

“To solve the problem of container lifecycle dependency we can create a new class of container: a “sidecar container” that behaves primarily like a normal container but is handled differently during termination and startup,” the KEP summary explains.

The lifecycle dependency issue is such that if there are for example two containers in a pod and one of them is a sidecar, determining when to terminate the pod is a bit of a challenge. When the primary container completes its process, the pod should terminate, but the sidecar might keep the resources running and the actual job will keep on running.

“The only way around this problem is to manage the sidecar container’s lifecycle manually and arrange for it to exit when the main container exits,” the KEP noted. “This is typically achieved by building an ad-hoc signalling mechanism to communicate completion status between containers.”

The solution is a new way to define containers with a field for container.lifecycle of either Standard or Sidecar.

Why Sidecar Containers Matter

The new Sidecar container specification makes a difference mainly for users.

Currently there are a lot of corner cases in Kubernetes where you cannot put a sidecar on a certain kind of workload, because it affects the way the workload starts and affects the way the workload is terminating.

So there are a lot of workloads in Kubernetes currently that people don’t instrument because you can’t with the current, non official sidecar deployment. Once the sidecar KEP become a stable part of Kubernetes that would change and it will make it possible to have sidecar as a ubiquitous capability anywhere in a cluster.

In security coverage is everything. If you have 90% of your Kubernetes pods protected, your Kubernetes cluster is still not secure. Sidecars are a core enabler for security in Kubernetes and enabling broader deployment will be a big help for improving security.

Column contributed by Octarine.