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 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.

Sharing a volume between multiple containers is straightforward once you understand the structure. You define the volume once at the Pod level in the volumes section, giving it a name like shared-logs or cache-volume. Then, in each container that needs access to that volume, you add a volumeMounts entry that references the volume by name and specifies where to mount it inside that container. The key insight is that you're mounting the same volume into multiple containers — Kubernetes doesn't create separate copies of the data.

Each container can mount the shared volume at a different path if that makes sense for your use case. For example, the main application might mount the volume at /var/log/app while the sidecar mounts it at /logs. Both paths point to the same underlying storage, so a file written to /var/log/app/access.log in the first container will appear as /logs/access.log in the second container. However, in many cases, it's simpler to use the same mount path in all containers, especially when you're working with applications that expect files at specific locations.

The most important characteristic of shared volumes is that changes are immediately visible to all containers. When one container writes a file, appends to a log, or modifies data, the other containers see those changes right away. There's no synchronization delay or replication process — it's truly shared storage. This makes shared volumes perfect for scenarios in which containers need to collaborate in real time, like our upcoming example in which a sidecar needs to monitor logs as they're being written.

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:

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

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.

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:

You should see confirmation that the Pod was 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:

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:

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

The sidecar pattern leverages Kubernetes' ability to run multiple containers in a single Pod and share volumes between them. By mounting the same volume into multiple containers, you enable those containers to collaborate through shared files without any network communication or complex coordination. This pattern is particularly powerful for separating concerns — your main application container focuses on business logic while sidecar containers handle auxiliary tasks like log processing, metrics collection, or protocol adaptation.

In the upcoming practice exercises, you'll create your own multi-container Pods with shared volumes, experimenting with different sidecar scenarios and seeing firsthand how this architectural pattern simplifies complex operational requirements.