Configuring Kubernetes Sidecar Containers for Auxiliary Processes

Configuring Kubernetes Sidecar Containers for Auxiliary Processes

We place multiple containers in one Kubernetes Pod — they share the network and can mount common volumes. This is the basis of the sidecar pattern: an auxiliary process lives next to the main application without modifying its image. We handle cross-cutting tasks — log collection, traffic proxying, secret synchronization. This approach isolates configuration, simplifies updates, and reduces infrastructure overhead. With 50 pods each having two sidecars, CPU load can reach 10 cores just for auxiliary processes, so proper resource planning yields up to 40% CPU savings. This pattern is described in Kubernetes documentation.

Why sidecar is better than DaemonSet for some tasks?

Logging. The main application writes logs to a file in /var/log/app/. We place a Fluentd sidecar that reads the same volume via emptyDir and sends logs to Elasticsearch. A DaemonSet with Fluentd on each node reads /var/log/containers/, but parsing is uniform for all pods. Sidecar provides fine-tuning for a specific service's log format — without workarounds and with delivery guarantees.

Envoy/Istio proxy. Service mesh is built on the sidecar pattern: Istio injects istio-proxy (Envoy) automatically via MutatingAdmissionWebhook when the namespace is labeled istio-injection: enabled. The application is unaware of mutual TLS auth, circuit breaking, and tracing — the proxy handles everything. We configure this in 1-2 days.

Configuration synchronization. Git-sync sidecar (registry.k8s.io/git-sync/git-sync:v4.2.1) clones a repository into emptyDir and watches for changes. The main application reads configs from this volume. Configuration updates without pod restart — critical for services with zero downtime requirement.

How to set up a sidecar for log collection?

Step-by-step instructions:

1. Create a ConfigMap with Fluent Bit configuration: specify input from file, output to Elasticsearch or Loki.
2. Add a second container in the pod spec with the fluent/fluent-bit image, mount the same emptyDir volume with logs.
3. Set resources: requests 50m CPU / 64Mi memory, limits 100m CPU / 128Mi memory.
4. Verify log delivery with kubectl logs -c log-shipper.

Here is a typical manifest:

spec:
  containers:
    - name: app
      image: myapp:v3.1.0
      volumeMounts:
        - name: app-logs
          mountPath: /var/log/app
    - name: log-shipper
      image: fluent/fluent-bit:3.0
      volumeMounts:
        - name: app-logs
          mountPath: /var/log/app
          readOnly: true
        - name: fluent-bit-config
          mountPath: /fluent-bit/etc
      resources:
        requests:
          cpu: "50m"
          memory: "64Mi"
        limits:
          cpu: "100m"
          memory: "128Mi"
  volumes:
    - name: app-logs
      emptyDir: {}
    - name: fluent-bit-config
      configMap:
        name: fluent-bit-config

Key resource point: sidecar containers are summed when scheduling the pod. Fluentd is memory-hungry — without limits, it can easily consume 500+ MiB on a node at high log volume. Always set limits. In our projects, we use 128Mi for Fluent Bit — sufficient even at 10,000 logs/second.

Managing sidecar lifecycle

The sidecar starts simultaneously with the main container, creating a race: the application may try to write logs before Fluent Bit is up. For critical cases, use postStart hook on the main container or switch to a native sidecar (since version 1.29).

Native sidecar is declared in spec.initContainers with restartPolicy: Always:

spec: initContainers: - name: log-shipper image: fluent/fluent-bit:3.0 restartPolicy: Always # ... 

This guarantees that the sidecar starts before the main container and restarts on failure without affecting the main container.

When should you use a native sidecar?

Native sidecar solves the startup race and Job pod hanging. If the sidecar performs critical initialization (e.g., loading configs from a repo), use it. It terminates gracefully along with the main container, preventing "zombie" pods.

Comparison of sidecar and DaemonSet for log collection

Typical pitfalls

Job pod hanging. The sidecar does not terminate when the main container of a Job finishes. The pod stays in Running status because Fluentd or another sidecar keeps running. Solution: either native sidecar (terminates correctly) or shareProcessNamespace: true and signal the sidecar process from the main container on completion.

Resource consumption. With 50 pods each having two sidecars (100m CPU per sidecar), that's 10 CPU cores just for auxiliary processes. Factor this into capacity planning. We recommend using resource profiles and HPA.

Debugging complexity. Viewing logs from multiple containers in one pod is cumbersome. Use kubectl logs <pod> -c <container> or tools like Stern.

Checklist of common mistakes:

• Forgetting limits — sidecar consumes unexpectedly high memory.
• Using regular sidecar in a Job — pod hangs.
• Not setting readOnly: true on the shared volume — sidecar could corrupt data.
• Not factoring sidecar into HPA — autoscaling sums all containers of the pod.
• Not setting restartPolicy: Always in native sidecars — container won't restart on failure.

How to calculate resources for sidecar?

Recommended starting values:

What is included in implementing the sidecar pattern?

Each stage is delivered turnkey. Leave a request — we will assess your project, show example configurations, and help avoid typical mistakes. Get a consultation: just describe the task.

Timelines and cost

One type of sidecar (logging or git-sync) — 1-2 days for design and test. Service mesh with Istio — up to 1 week. Cost is calculated individually based on complexity and number of services. Average resource savings when switching from DaemonSet to sidecar — up to 40% CPU.

Order an audit of your current infrastructure — we will identify bottlenecks and propose the optimal solution.