A sidecar process runs beside a primary application component, typically as a second container in the same Kubernetes Pod. It shares the Pod’s lifecycle and local execution context while taking on a supporting concern such as log collection, routing, and enrichment. For observability, a Fluent Bit sidecar lets application code send events locally or leave existing file-based logging largely unchanged. section 4.6 section 4.6.2
The pattern is useful when monitoring needs differ by application. A dedicated sidecar can carry only the inputs, filters, formatters, and routes relevant to its companion service, keeping application-specific configuration separate from other workloads. It can tail files in shared transient Pod storage or receive events over localhost; the latter avoids file mounts and keeps communication within the local host scope. section 4.6.2 section 3.6.6
For Kubernetes log collection, choose a sidecar when its trade-offs fit the workload:
- Use it to modernize established applications with minimal code change: capture existing log files from shared storage, then forward records to centralized processing or backend services. section 3.4 section 11.3.1
- Prefer direct application-to-sidecar delivery when possible. An HTTP logging appender can remove multiline parsing, file-mount, and Kubernetes-storage concerns while making event processing easier to tune. section 11.3.1
- Compare it with a DaemonSet: a node-level Fluent Bit instance collects stdout and stderr for many containers, but shared filtering and routing changes can affect every application on that node. section 4.6.2
- Budget for one Fluent Bit instance per application Pod and keep its image patched consistently across Pods. section 4.6.2
- Plan startup order when sidecars forward through other Fluent Bit instances. Configure retries for unavailable downstream nodes and start concentrators before upstream senders where possible. section 3.6.6
Two-container log-collection Pod
A Pod can run a log-generating container and a Fluent Bit sidecar that mount the same /var/log volume. The application writes two files; Fluent Bit tails each file, assigns source tags, and writes combined output while also emitting records to stdout. Apply the ConfigMap and Pod manifests, then follow the combined output to verify that records arrive as they are written. section 4.6.2
A sidecar has implicit Pod context, which can simplify matching and filtering compared with a node-level collector. It does not automatically distinguish replicated Pod instances, however. Add Pod identity through container environment variables, the Kubernetes downward API, or an enrichment filter when records need instance-specific context. section 4.6.2 section 4.6.3
Figure 3.7 Deployment options for using Fluent Bit and Fluentd. The arrows reflect the flow of forwarded log events. The dashed arrows reflect the ability to forward to secondary connections if a connection fails to respond, giving us a resilient configuration if needed. These options work because the forward plugin works for both services. The right worker uses Fluentd as the concentrator node. App A uses common storage. App D works via a flat file visible within the Pod.
Compare sidecar, shared-storage, and concentrator deployments, including forwarded event paths and optional secondary connections for resilience. section 3.6.6
