Getting to know sidecar containers

Imagine owning a lovely 2023 Benz, which you drive every day. They are metrics that are taken into consideration as the vehicle moves, these metrics are most times displayed on your dashboard. Your car engine just does its work and doesn’t need to bother about submitting metrics to anyone. Meanwhile, there are elements that have been plugged alongside the car movement that take note of these metrics and display them on your dashboard. This is a similar illustration to what I will be discussing in this article about Sidecar containers.

What is a sidecar container?

A sidecar container is a separate container deployed alongside a primary application container to provide additional services and functionalities that are different from the primary application’s responsibilities. They run within the same pod and are managed within the same orchestration system.

Image source: https://www.go

The main purpose of a sidecar container is to extend the functionality of the primary container without modifying its code or requiring the container to have additional capabilities. This allows developers to add features such as logging, monitoring, service discovery, or security to an application without having to integrate those capabilities directly into the application code. The sidecar container can be responsible for these additional tasks, while the primary container can focus on its core functionality.

The architecture of a sidecar container

The sidecar container interacts with the primary container through inter-process communication mechanisms such as Unix domain sockets, shared memory, or network ports (mostly this). This allows the primary container to access the services provided by the sidecar container, such as logging, monitoring, or security. The mechanism of sidecar containers typically involves using an orchestration system such as Kubernetes or Docker Swarm.

Each pod can have one or more containers running within it, and these containers share the same network namespace by default. When a pod is created, Kubernetes assigns a unique IP address to it. Each container running within the pod is assigned its own network interface, which is configured with the same IP address as the pod. This allows all containers within the pod to communicate with each other through the localhost interface.

Regarding sidecar containers, they are deployed within the same pod as the primary container, which means they share the same network namespace and IP address. This allows the sidecar container to communicate with the primary container directly through the localhost interface.

Image source: https://www

For example, let’s say we have a primary container running a web application that listens on port 8080. We want to add a sidecar container that collects logs from the web application and sends them to a logging service. The sidecar container can listen on a separate port, such as 9000, and the web application can be configured to send its logs to the sidecar container’s port.

Since both containers are running within the same pod and share the same network namespace, the web application can communicate with the sidecar container using the localhost interface and the sidecar container can collect the logs directly from the web application without any additional network overhead.

We can illustrate this below in our yml file;

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ourapp
spec:
  replicas: 4
  selector:
    matchLabels:
      app: ourapp
  template:
    metadata:
      labels:
        app: ourapp
    spec:
      containers:
        - name: ourapp-container
          image: ourapp:latest
          ports:
            - containerPort: 8080
        - name: sidecar-container
          image: sidecar:latest
          ports:
            - containerPort: 9000

In this example, we have a Kubernetes deployment for an application called “ourapp” with a replica count of 4. The deployment includes two containers within the same pod:

1. The ourapp-container container runs the primary application code and listens on port 8080.
2. The sidecar-container container runs alongside the ourapp-container and provides additional functionality.

The sidecar-container listens on port 9000, which can be used to communicate with the ourapp-container and provide additional functionality such as logging, monitoring, or service discovery.

Some common use cases of sidecar containers

We have discussed a lot about sidecars and logging information. They are other use cases for sidecar containers, we will discuss them below.

1. Monitoring: A sidecar container can be used to collect metrics and other telemetry data from the primary container and send it to a monitoring service.
2. Service discovery: A sidecar container can be used to discover and register services running within the same pod or elsewhere in the cluster. This allows for easy building and deployment of microservice-based applications, without requiring any changes to the application code.
3. Security: A sidecar container can be used to provide additional security functionality, such as encryption, decryption, or access control.
4. Traffic management: A sidecar container can be used to manage network traffic, such as load balancing or routing, to multiple instances of a primary container. This allows for easy scaling of applications horizontally and distribution of traffic across multiple instances.
5. Setting up a light database: Sidecar containers can be used to run a lightweight database such as SQLite or PostgreSQL, which is deployed alongside your primary container within the same pod. The primary container could then interact with the database via a local socket connection, without requiring any network communication. Also, a sidecar container can be used to run a separate database service, such as MySQL or MongoDB, which is deployed alongside your primary container within the same pod. The primary container could then interact with the database via a network connection to the sidecar container, which manages all database-related tasks such as connection pooling, query caching, and failover.

Conclusion

The possibilities for sidecar containers are quite broad, and they can be used to add a wide range of functionality to your Kubernetes applications, without requiring any changes to the primary container code. Although they are popularly known for logging, this article has shown some other use cases they are known for.