Sidecar Pattern and Volume Sharing

From Pod-Scoped Storage to Shared Storage

In the previous lesson, we learned that emptyDir volumes exist at the Pod level, not at the container level. This means the volume survives container restarts but is deleted when the Pod itself is deleted. That Pod-level lifecycle naturally leads to an interesting question: if a volume belongs to the Pod rather than to any individual container, can multiple containers within the same Pod access that volume? The answer is yes, and this capability unlocks a powerful architectural pattern called the sidecar pattern . In this lesson, we'll explore how multiple containers can mount and share the same volume, enabling them to collaborate by reading and writing shared data. We'll see a practical example in which an Nginx web server writes access logs, and a separate monitoring container reads those logs in real time.

The Sidecar Pattern

The sidecar pattern is a design approach in which you run a helper container alongside your main application container within the same Pod. Think of it like a motorcycle sidecar — it's attached to the main vehicle and travels with it, but it serves a different purpose. The sidecar container typically handles auxiliary tasks that support the main application without being part of the core business logic. Common examples include log processors that collect and forward logs to a central system, metrics collectors that gather performance data and send it to monitoring tools, and proxy containers that handle authentication or protocol translation. This pattern is powerful because it achieves separation of concerns without introducing network overhead. Your main application container can focus purely on its core functionality — serving web requests, processing data, or running business logic — while the sidecar handles cross-cutting concerns like logging, monitoring, or security. Because both containers run in the same Pod, they share the same network namespace and can access the same volumes, making communication extremely efficient. There's no need for network calls between containers; they can simply read and write files to a shared directory. The sidecar pattern also promotes reusability. You can build a generic log-forwarding sidecar once and then attach it to any application that writes logs to a standard location. You don't need to modify your application code to add logging infrastructure — you just add the sidecar container to your Pod specification. This keeps your application containers lean and focused while still providing rich operational capabilities.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Example: Nginx Writing Logs, Sidecar Reading Them

Let's look at a concrete example that demonstrates the sidecar pattern in action. We'll create a Pod with two containers: an Nginx web server that writes access logs, and a Busybox container that reads those logs in real time.

Note: This example is intentionally simplified for teaching purposes. In standard Kubernetes deployments, Nginx is typically configured to write logs to stdout and stderr rather than to files, and cluster-level logging tools collect those streams directly from container output. The file-based approach shown here is a useful illustration of volume sharing, but it is not a typical production logging pattern.

Here's the complete Pod specification:

YAML

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
    - name: app
      image: nginx:1.25
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx
    - name: sidecar
      image: busybox:1.35
      command: ['sh', '-c', 'touch /var/log/nginx/access.log && tail -f /var/log/nginx/access.log']
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx
  volumes:
    - name: shared-logs
      emptyDir: {}

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
    - name: app
      image: nginx:1.25
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx
    - name: sidecar
      image: busybox:1.35
      command: ['sh', '-c', 'touch /var/log/nginx/access.log && tail -f /var/log/nginx/access.log']
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx
  volumes:
    - name: shared-logs
      emptyDir: {}

Let's break this down section by section. First, look at the volumes definition at the bottom:

YAML

  volumes:
    - name: shared-logs
      emptyDir: {}

  volumes:
    - name: shared-logs
      emptyDir: {}

This creates a single emptyDir volume named shared-logs at the Pod level. Remember from previous lessons that emptyDir creates an empty directory when the Pod starts and deletes it when the Pod is removed. This volume will be shared between both containers in the Pod.

Now let's examine the first container, which we're calling app:

YAML

    - name: app
      image: nginx:1.25
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

    - name: app
      image: nginx:1.25
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

This container runs Nginx version 1.25. The volumeMounts section tells Kubernetes to mount the shared-logs volume at /var/log/nginx inside this container. This is significant because /var/log/nginx is where Nginx naturally writes its access and error logs. By mounting our volume there, we're capturing those logs into shared storage instead of letting them go into the container's ephemeral filesystem.

Now look at the second container, the sidecar:

YAML

    - name: sidecar
      image: busybox:1.35
      command: ['sh', '-c', 'touch /var/log/nginx/access.log && tail -f /var/log/nginx/access.log']
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

    - name: sidecar
      image: busybox:1.35
      command: ['sh', '-c', 'touch /var/log/nginx/access.log && tail -f /var/log/nginx/access.log']
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

This container runs Busybox, a lightweight Linux environment. The command field specifies what this container should do: first run touch /var/log/nginx/access.log to ensure the log file exists before attempting to read it, then run tail -f on that file to continuously display any new lines appended to it. The touch step is important here — because both containers start at roughly the same time, the log file might not exist yet when the sidecar starts up. Creating it explicitly prevents the tail command from failing and causing a restart loop. Notice that this container also mounts the shared-logs volume at the same path: /var/log/nginx. This means when the sidecar reads from /var/log/nginx/access.log, it's reading the exact same file that Nginx is writing to in the app container.

The beauty of this setup is that both containers are completely independent. The Nginx container doesn't know or care that another container is reading its logs. The sidecar container doesn't need any special permissions or configuration from Nginx. They're simply two containers that happen to share a directory, and that shared directory enables them to collaborate.

Proving the Sharing Works

Let's run through the commands to create this Pod and verify that the volume sharing actually works. Save the YAML above to a file called pod-sidecar-sharing.yaml, then create the Pod:

Shell

kubectl apply -f pod-sidecar-sharing.yaml

kubectl apply -f pod-sidecar-sharing.yaml

You should see confirmation that the Pod was created:

text

pod/app-with-sidecar created

pod/app-with-sidecar created

Wait a few seconds for both containers to start. You can check the Pod status with kubectl get pods — you should see 2/2 in the READY column, indicating both containers are running. Now let's generate a log entry by writing directly to the Nginx access log:

Shell

kubectl exec -it app-with-sidecar -c app -- sh -c 'echo "New Request" >> /var/log/nginx/access.log'

kubectl exec -it app-with-sidecar -c app -- sh -c 'echo "New Request" >> /var/log/nginx/access.log'

This command uses kubectl exec to run a command inside the app container (notice the -c app flag specifying which container). We're using echo to append the text "New Request" to the access log file. In a real scenario, Nginx would write these log entries automatically when it receives HTTP requests, but for our demonstration, manually writing to the file is simpler and proves the same point.

Now here's the key test: let's read the logs from the sidecar container, not from the app container:

Shell

kubectl logs app-with-sidecar -c sidecar

kubectl logs app-with-sidecar -c sidecar

The kubectl logs command shows the output from a container. The -c sidecar flag tells it to show logs from the sidecar container specifically. You should see output that includes:

text

New Request

New Request

This proves that the volume is truly shared. We wrote data in the app container, and we can read that same data from the sidecar container. The sidecar's tail -f command is continuously monitoring the log file, so any new entries appear immediately in its output. If you run the echo command multiple times and then check the sidecar logs again, you'll see all the entries you added.

To clean up, delete the Pod:

Shell

kubectl delete -f pod-sidecar-sharing.yaml

kubectl delete -f pod-sidecar-sharing.yaml

You'll see:

text

pod "app-with-sidecar" deleted

pod "app-with-sidecar" deleted

Remember from the previous lesson that deleting the Pod also deletes the emptyDir volume and all its contents. The log entries we created are now gone. This is expected behavior for emptyDir — it's temporary storage that exists only while the Pod is running.

From Pod-Scoped Storage to Shared Storage

The Sidecar Pattern

Join the 1M+ learners on CodeSignal

The Mechanics of Volume Sharing

Example: Nginx Writing Logs, Sidecar Reading Them

Proving the Sharing Works

Summary and Practice Preview