Day 6 of 100 Days of K8s with DevOps: Multi-Container Pods & The Sidecar Pattern

In the past few days, we’ve explored Kubernetes Pods, how they work, their lifecycle, logging, and even readiness and liveness probes. But here’s something interesting—what if a Pod needed multiple containers working together to accomplish a task?

That’s exactly what we’re diving into today. Multi-Container Pods open up new possibilities for designing applications, enabling better logging, monitoring, and sidecar patterns to extend functionality without modifying the primary application.

Let’s break it down step by step.

What is a Multi-Container Pod?

By default, most Kubernetes deployments have one container per Pod—that’s the typical setup. However, Kubernetes allows multiple containers to run inside the same Pod.

Why would you want that? Here are some real-world use cases:

? Logging: Your main application runs in one container, while a logging agent runs in another container, collecting and shipping logs.

? Proxy & Security: A microservice runs alongside an Envoy proxy for traffic control.

? Data Processing: One container fetches data, and another processes it before saving it to storage.

? Monitoring: A Prometheus exporter runs next to an application, exposing critical metrics.

Essentially, a Multi-Container Pod is like a mini application stack running inside a single Kubernetes unit.

Understanding the Sidecar Pattern

One of the most common Multi-Container Pod architectures is the Sidecar Pattern.

Think of it like this: Your main application does the core job, while the sidecar helps enhance it without interfering.

For example, in a car, the driver does the actual driving, while the sidecar passenger can assist with navigation, carry extra fuel, or store tools. The same concept applies to Kubernetes!

How is a Sidecar Container Useful?

• Log Aggregation: A sidecar container can collect and send logs to a centralized location (Fluentd, Logstash).
• Security & Proxying: A sidecar container can handle authentication, request filtering, or TLS encryption (Envoy, Istio).
• Data Synchronization: A backup container can periodically sync data to an external database or storage.
• Metrics Collection: A Prometheus exporter can run next to your app to expose metrics.

Instead of modifying your primary application, you just add a supporting container that works alongside it.

Hands-On: Deploying a Multi-Container Pod with a Sidecar Logger

Let’s get practical. We’ll create a Pod with two containers:

1?? An Nginx web server that serves traffic.

2?? A simple logger that captures and stores web requests in a shared location.

YAML Configuration

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
  - name: logger
    image: busybox
    command: ["sh", "-c", "while true; do echo 'Logging app requests' >> /var/log/app.log; sleep 5; done"]
    volumeMounts:
    - name: log-storage
      mountPath: /var/log
  volumes:
  - name: log-storage
    emptyDir: {}        

Breaking It Down

?? Nginx Container: Serves web traffic on port 80.

?? Logger Container: Runs a loop that writes logs to /var/log/app.log.

?? Shared Volume (emptyDir): Both containers can access the same log file.

Deploying and Testing the Multi-Container Pod

Step 1: Deploy the Pod

Run:

kubectl apply -f multi-container-pod.yaml        

Step 2: Verify Pod Status

Check if both containers are running:

kubectl get pods        

Step 3: Check Logs of the Sidecar

Once the pod is up, check the logs from the sidecar container:

kubectl logs multi-container-pod -c logger        

You should see:

Logging app requests
Logging app requests
Logging app requests        

Step 4: Debugging the Multi-Container Pod

If something goes wrong, describe the pod for troubleshooting:

kubectl describe pod multi-container-pod        

This command helps debug issues like CrashLoopBackOff, ImagePullBackOff, or Resource Allocation Errors.

Why Multi-Container Pods Are Powerful

? Optimized Resource Sharing – Instead of running separate Pods, multiple containers can share networking, storage, and memory efficiently.

? Seamless Application Extensions – Add logging, monitoring, or security features without changing the main app.

? Lightweight and Scalable – Ideal for distributed applications that need modular functionality.

However, be mindful that too many containers in a Pod can lead to tight coupling, making updates harder. Always design Multi-Container Pods with a clear purpose.

Conclusion & What’s Next?

In Day 6, we covered:

? What Multi-Container Pods are and why they matter.

? The Sidecar Pattern and how it enhances Kubernetes applications.

? A hands-on example of running Nginx with a logging sidecar.

? Debugging & best practices for multi-container setups.

Tomorrow in Day 7, we’ll take this further by conducting a live session on From Cluster Setup to Application Deployment

Got questions or insights? Drop them in the comments! ??