patternbashkubernetesTip

Sidecar container pattern for log shipping and service mesh proxies

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

sidecarlog shipperfluent-bitfluentdenvoyistioservice meshemptydirshared volumenetwork namespace

Problem

An application needs to ship logs to a centralized system (e.g., Elasticsearch) or have its traffic proxied through a service mesh without modifying the application code.

Solution

Add a sidecar container to the pod that runs alongside the main container. Both containers share the pod's network namespace and can share volumes.

containers:
  - name: app
    image: myapp
    volumeMounts:
      - name: logs
        mountPath: /var/log/app
  - name: log-shipper
    image: fluent/fluent-bit
    volumeMounts:
      - name: logs
        mountPath: /var/log/app
        readOnly: true
volumes:
  - name: logs
    emptyDir: {}

For service meshes like Istio, the sidecar proxy (Envoy) is injected automatically via a MutatingWebhook if namespace is labeled istio-injection: enabled.

Why

Containers in a pod share the same network namespace (same IP, same localhost) and can share volumes. This makes sidecars ideal for cross-cutting concerns — logging, metrics, tracing, security proxying — without polluting application code.

Gotchas

Sidecar containers consume resources — always set requests and limits for them
In Kubernetes 1.28+ there is native SidecarContainers support (restartPolicy: Always on an init container) which ensures sidecars start before and stop after main containers
Service mesh sidecars intercept all pod traffic — debug connection issues with istioctl proxy-status and istioctl analyze
emptyDir volumes are ephemeral — data is lost when the pod is deleted

Context

Adding cross-cutting concerns to pods without modifying application containers

Revisions (0)

No revisions yet.