What Are Sidecar Containers?

A sidecar container refers to a container that runs alongside the application container, within the pod. It serves to enhance the application by adding functionalities such as logging, monitoring or networking features without making any changes to the application code.

Understanding Pods and Containers

In Kubernetes pods serve as the unit of execution.  A pod can contain one or more containers. Kubernetes distinguishes between two types of containers; containers and init containers.

Init containers are executed during pod initialization. The init containers terminate once their tasks are completed allowing ordinary containers to run.

Sidecar Containers Prior to Release 1.28

To grasp the developments regarding sidecar containers it is essential to understand how things were before Kubernetes 1.28 release.

Prior to the 1.28 release Kubernetes did not have a concept of sidecars.

The term "sidecar" was more of a pattern than an integrated feature. Sidecars were containers that operated alongside the application container within the same pod. They were utilized in order to enhance the functionality of the application without requiring any modifications, in its code.

However this approach posed challenges;

Pod Restart; Upgrading a sidecar required restarting the pod, including its associated application container.
Job Termination; Kubernetes lacks a mechanism to signal termination, to the sidecar leading to complications when jobs are expected to end upon completion. It could cause that the job never actually ended. 

Startup Race Conditions; Kubernetes doesn't ensure an order for starting containers, which can cause issues if the main application relies on the sidecars initialization.

Introducing New Sidecar Functionality in Kubernetes 1.28 - RestartPolicy for Init Containers

The release of Kubernetes, version 1.28 introduces a RestartPolicy field for init containers.

This field allows you to define the restart behavior of containers within a pod.

When you set the RestartPolicy to "Always" for a container it effectively functions as a sidecar container.

Key Behaviors;

Startup Behavior; The init container starts before all containers.
Termination Behavior; The init container terminates after all regular containers have ended.
Restart Behavior; If the init container dies during the lifetime of the pod it is automatically restarted.

As we can see, there is no sidecar definition, instead we define a init container. Still confused?

We'll have a look at an example. 

Sample Configuration

Here's an example YAML configuration that illustrates how to define a sidecar container;

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  initContainers:
  - name: sidecar
    image: sidecar-image
    restartPolicy: Always
  containers:
  - name: main-container
    image: main-container-image

Why Does It Matter?

The latest update introduces a feature that simplifies the handling of sidecar containers and overcomes limitations. This advancement plays a role, in enhancing the adaptability of Kubernetes to diverse application architectures.

Typical Applications for Sidecars

Sidecars find uses in scenarios such as;

 Collecting metrics
 Aggregating logs
 Implementing service meshes (Istio, Linked, Consul)

Conclusion

With the arrival of Kubernetes 1.28 significant improvements have been made to manage sidecar containers effectively. This update empowers engineers, by providing ways to enhance applications without modifying their core code. Although challenges persist the advantages offered by sidecars outweigh any drawbacks significantly establishing them as a part of the Kubernetes ecosystem.

Aleksandro Matejic, a Cloud Architect, began working in the IT industry over 21 years ago as a technical specialist, right after his studies. Since then, he has worked in various companies and industries in various system engineer and IT architect roles. He currently works on designing Cloud solutions, Kubernetes, and other DevOps technologies.

In his spare time, Aleksandro works on different development projects such as developing devoriales.com, a blog and learning platform launching in 2022/2023. In addition, he likes to read and write technical articles about software development and DevOps methods and tools.

You can contact Aleksandro by visiting his LinkedIn Profile