Sidecar container pattern in Kubernetes - Commands & Configuration

Introduction

Sometimes an application needs helper tasks like logging or data syncing that run alongside it. The sidecar container pattern solves this by running a small helper container inside the same pod as the main app, sharing resources and network.

When you want to add logging or monitoring to an app without changing its code

When you need to sync files or data between the app and external storage

When you want to inject configuration or secrets dynamically alongside the app

When you want to add a proxy or network helper to manage traffic for the app

When you want to share a cache or database connection helper with the main app

Config File - sidecar-pod.yaml

sidecar-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: example-sidecar-pod
spec:
  containers:
  - name: main-app
    image: nginx:1.23.3
    ports:
    - containerPort: 80
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/nginx
  - name: sidecar-logger
    image: busybox:1.36
    command: ["sh", "-c", "tail -f /var/log/nginx/access.log"]
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/nginx
  volumes:
  - name: log-volume
    emptyDir: {}

This YAML defines a pod with two containers: main-app running nginx, and sidecar-logger running busybox to watch nginx logs.

They share a volume log-volume to exchange log files.

This setup lets the sidecar container help the main app without changing the app itself.

Commands

This command creates the pod with both the main app and the sidecar container running together.

Terminal

kubectl apply -f sidecar-pod.yaml

Expected Output

pod/example-sidecar-pod created

Check that the pod is running and both containers are ready.

Terminal

kubectl get pods

Expected Output

NAME                 READY   STATUS    RESTARTS   AGE

example-sidecar-pod   2/2     Running   0          10s

View the logs output from the sidecar container to verify it is working as expected.

Terminal

kubectl logs example-sidecar-pod -c sidecar-logger

Expected Output

No output (command runs silently)

→

-c - Specify the container name inside the pod to get logs from

Key Concept

If you remember nothing else from this pattern, remember: a sidecar container runs alongside your main app in the same pod to provide helper functions without changing the app.

Common Mistakes

Defining the sidecar container in a separate pod instead of the same pod

Sidecar containers must be in the same pod to share storage and network; separate pods cannot share these resources directly.

Always define the sidecar container inside the same pod spec as the main container.

Not sharing volumes between main and sidecar containers when they need to exchange files

Without shared volumes, containers cannot access each other's files, breaking the helper functionality.

Use shared volumes in the pod spec and mount them in both containers.

Trying to access sidecar container logs without specifying the container name

Pods with multiple containers require specifying which container's logs to view; otherwise, kubectl returns an error.

Use the -c flag with kubectl logs to specify the sidecar container.

Summary

Create a pod with both main and sidecar containers defined together.

Use shared volumes to let containers exchange files or data.

Use kubectl commands to deploy the pod and check logs from the sidecar container.