Sidecar Container Pattern for Log Forwarding

The Sidecar Pattern

The sidecar pattern adds a helper container to your pod that augments the main application container. The most common use case is log forwarding: the application writes logs to a shared volume, and a sidecar container reads and forwards them.

Key Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-logging
  labels:
    app: "web"
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: app
          image: my-app:latest
          ports:
            - name: http
              containerPort: 8080
          volumeMounts:
            - name: logs
              mountPath: /var/log/app
        - name: log-forwarder
          image: fluent/fluent-bit:latest
          volumeMounts:
            - name: logs
              mountPath: /var/log/app
              readOnly: true
          resources:
            requests:
              cpu: "25m"
              memory: "32Mi"
            limits:
              cpu: "100m"
              memory: "64Mi"
      volumes:
        - name: logs
          emptyDir: {}

How It Works

1. Both containers share an emptyDir volume mounted at /var/log/app
2. The application container writes log files to this directory
3. The log forwarder container (Fluent Bit, Fluentd, or Vector) reads these files and forwards them to Elasticsearch, CloudWatch, or another logging backend
4. Because they are in the same pod, they share the same lifecycle — when the pod is deleted, both containers stop

Resource Allocation

The sidecar should use minimal resources since its job is just to read and forward data. Typical values:

• Fluent Bit: 25m CPU, 32Mi memory (very lightweight)
• Fluentd: 100m CPU, 128Mi memory (heavier, more plugins)
• Vector: 50m CPU, 64Mi memory (Rust-based, efficient)

Alternatives

• DaemonSet log collector: Run one log collector per node instead of per pod (more efficient at scale)
• Application-level logging: Send logs directly from the application to the logging backend (no sidecar needed)
• stdout/stderr: Write to stdout and let the container runtime handle log collection (simplest approach)