1

Scenario #2: Multi-container Pod (Sidecar pattern) for logging in Kubernetes

This one will show how multiple containers in a single Pod can share data and work together, just like microservices collaborating closely inside one unit.

🎯 Goal

Create a multi-container Pod with:

  • One main container running NGINX
  • One sidecar container that tails NGINX access logs and prints them to its own stdout (mimicking a log forwarder)

This demonstrates the Sidecar Pattern — where an auxiliary container extends or supports the main container’s function.

🧩 Step 1: Create YAML for Multi-Container Pod

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 containers share a volume (emptyDir) at /var/log/nginx.
  • NGINX writes logs to /var/log/nginx/access.log.
  • The sidecar container continuously tails that file and outputs to its stdout.
  • Kubernetes logs aggregation will show both containers’ logs.

🚀 Step 2: Create YAML for 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: Apply the YAML

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

✅ Output:

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

1

2

🔍 Step 4: Verify the Pod

kubectl get pods -o wide

Expected:

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

Notice there are two containers inside one Pod.

🧪 Step 5: Generate Logs

Run a temporary busybox Pod and hit the NGINX endpoint a few times:

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

Inside the shell:

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

🪵 Step 6: Check Sidecar Logs

Now check the sidecar container’s logs:

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

You’ll see output like:

📜 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" "-"

🎉 You’ve just demonstrated the Sidecar pattern — where a helper container monitors and reacts to another container’s output.

4

🧹 Cleanup (Optional)

5

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

🧭 Architecture Visualization

+-------------------------------------------------------+
|                Pod: nginx-sidecar-pod                 |
|-------------------------------------------------------|
|  [ nginx container ]        [ sidecar-logger ]        |
|  /var/log/nginx <-- shared emptyDir volume --> /var/log/nginx |
+-------------------------------------------------------+
  • nginx → serves traffic and writes logs
  • sidecar-logger → reads and outputs those logs

🌟 Thanks for reading! If this post added value, a like ❤️, follow, or share would encourage me to keep creating more content.

— Latchu | Senior DevOps & Cloud Engineer

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

Similar Posts