Kubernetes offers powerful ways to orchestrate applications, and one of its most versatile features is the ability to run multiple containers within a single Pod. This isn’t just about bundling; it’s about enabling containers to share resources and work together seamlessly, much like microservices collaborating in a cohesive unit. Among these multi-container patterns, the Sidecar Pattern stands out for its elegance and utility.

This guide will walk you through a practical demonstration of the Sidecar Pattern. We’ll deploy a Kubernetes Pod containing two containers: a primary NGINX web server and a “sidecar” container that continuously monitors and logs NGINX’s access activities.

🎯 What We’re Building: NGINX with a Log-Forwarding Sidecar

Our objective is to create a multi-container Pod that includes:
* A main container running NGINX to serve web traffic.
* A sidecar container (using busybox) designed to tail the NGINX access logs and print them to its own standard output, effectively mimicking a lightweight log forwarder.

This setup perfectly illustrates how a sidecar can extend or enhance the core functionality of a main application container without modifying the application itself.

🧩 Step 1: Defining Our Multi-Container Pod with a Shared Volume

The magic behind sidecars sharing data lies in Kubernetes volumes. Both our NGINX and sidecar containers will mount a shared emptyDir volume, allowing NGINX to write logs to it and the sidecar to read from it.

Create a file named nginx-sidecar-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-sidecar-pod
  labels:
    app: nginx-sidecar
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
      - containerPort: 80
    volumeMounts:
      - name: shared-logs
        mountPath: /var/log/nginx
  - name: sidecar-logger
    image: busybox
    command: ["/bin/sh", "-c"]
    args:
      - |
        echo "📜 Sidecar started. Monitoring /var/log/nginx/access.log...";
        tail -n+1 -F /var/log/nginx/access.log
    volumeMounts:
      - name: shared-logs
        mountPath: /var/log/nginx
  volumes:
    - name: shared-logs
      emptyDir: {}

How It Works:
* Both nginx and sidecar-logger containers share the shared-logs volume, mounted at /var/log/nginx in each.
* NGINX writes its access logs to /var/log/nginx/access.log.
* The sidecar-logger container uses tail -F to continuously stream content from this shared log file to its stdout.
* Kubernetes’ built-in log aggregation will then collect logs from both containers.

🚀 Step 2: Exposing Our NGINX Service

To make our NGINX server accessible, we’ll create a Kubernetes Service.

Create nginx-sidecar-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: nginx-sidecar-service
spec:
  selector:
    app: nginx-sidecar
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

🚀 Step 3: Deploying to Kubernetes

Now, let’s apply our configurations to the Kubernetes cluster:

kubectl apply -f nginx-sidecar-pod.yaml
kubectl apply -f nginx-sidecar-service.yaml

You should see output similar to:

pod/nginx-sidecar-pod created
service/nginx-sidecar-service created

🔍 Step 4: Verifying the Pod Status

Confirm that our Pod is running with two containers:

kubectl get pods -o wide

Expected output will show 2/2 under the READY column, indicating both containers are operational:

NAME                READY   STATUS    RESTARTS   AGE   IP           NODE
nginx-sidecar-pod   2/2     Running   0          20s   10.32.0.18   gke-mycluster-default-pool-xxxx

🧪 Step 5: Generating Some NGINX Logs

To see our sidecar in action, let’s generate some traffic to the NGINX server. We’ll use a temporary busybox Pod to make a request.

First, run the curl-pod:

kubectl run curl-pod --image=busybox -it --rm -- /bin/sh

Inside the busybox shell, hit the NGINX endpoint:

wget -qO- http://nginx-sidecar-pod
exit

🪵 Step 6: Observing Sidecar Logs

Finally, let’s check the logs from our sidecar-logger container:

kubectl logs nginx-sidecar-pod -c sidecar-logger

You will see output similar to this, confirming the sidecar is successfully forwarding NGINX access logs:

📜 Sidecar started. Monitoring /var/log/nginx/access.log...
10.32.0.19 - - [07/Nov/2025:12:45:34 +0000] "GET / HTTP/1.1" 200 615 "-" "Wget" "-"

Congratulations! You have successfully implemented and demonstrated the Sidecar Pattern, where a helper container actively monitors and processes output from its main counterpart.

🧹 Cleanup (Optional)

To remove the resources from your cluster:

kubectl delete svc nginx-sidecar-service
kubectl delete pod nginx-sidecar-pod

🧭 Architectural Visualization

Here’s a simple diagram to illustrate the architecture:

+-------------------------------------------------------+
|                Pod: nginx-sidecar-pod                 |
|-------------------------------------------------------|
|  [ nginx container ]        [ sidecar-logger ]        |
|  /var/log/nginx <--- shared emptyDir volume ---> /var/log/nginx |
+-------------------------------------------------------+

In this setup:
* nginx serves web traffic and writes logs to the shared volume.
* sidecar-logger reads and outputs those logs from the same shared volume.

This pattern is incredibly powerful for tasks like log forwarding, secret management, configuration updates, and more, allowing for modularity and separation of concerns within your Pods.

---

Latchu | Senior DevOps & Cloud Engineer

☁️ AWS | GCP | ☸️ Kubernetes | 🔐 Security | ⚡ Automation
📌 Sharing hands-on guides, best practices & real-world cloud solutions