Sidecar process
The sidecar pattern deploys an auxiliary process or component alongside a primary application to provide supporting functionality separately from the application’s core code.
Effective Platform Engineering
A sidecar proxy is a proxy deployed alongside an application workload to handle communication without requiring application-code changes.
- How it is used
- Moves service-communication behavior into a proxy alongside the workload, avoiding application-code changes.
- How deep it goes
- Defines proxy behavior and compares per-pod with shared placement, but does not show individual proxy configuration.
- Examples
- Uses web-token validation, connection retries, and encryption between proxies as configuration examples.
- What you can do after
- Operate/configure it through a service mesh to apply communication behavior without changing application code.
Read how Effective Platform Engineering explains sidecar process →
Google Anthos in Action
A sidecar is a container deployed alongside a main container in the same Pod to provide supporting functionality such as proxying.
- How it is used
- Adds logging, monitoring, backups, or service-mesh traffic handling alongside a Kubernetes workload without changing its application logic.
- How deep it goes
- Defines the pattern, explains proxy responsibilities, and gives injection and verification steps; does not show a complete sidecar manifest.
- Examples
- Uses logging and backup sidecars, a web-server/database scaling contrast, and namespace-labeling and Pod-readiness commands.
- What you can do after
- Operate/configure it by enabling Anthos Service Mesh injection, restarting workloads, and checking that Pods contain both containers.
Logs and Telemetry
The sidecar pattern deploys a supporting process alongside a primary application component so they share a lifecycle and execution context.
- How it is used
- Collects application-specific observability events locally in a Pod before routing them to centralized backends.
- How deep it goes
- Explains Kubernetes deployment, shared files, localhost delivery, DaemonSet trade-offs, context injection, and forwarding startup behavior.
- Examples
- Demonstrates a two-container Pod that tails two shared log files and writes combined output.
- What you can do after
- Operate/configure it to collect application logs through shared storage or local endpoints and route them onward.
Kubernetes in Action, Second Edition
The sidecar pattern places a complementary process in a separate container alongside a primary application process in the same pod.
- How it is used
- Extends a primary application through a complementary container in the same pod, without changing application code.
- How deep it goes
- Works through proxy testing and container logs, then explains native-sidecar startup, restart, and shutdown; does not detail proxy internals.
- Examples
- Uses an Envoy HTTPS proxy, curl and log checks, and a traffic-meter native-sidecar manifest.
- What you can do after
- Build it from scratch with a Pod manifest, then operate it using kubectl port-forward and container-specific logs.
Read how Kubernetes in Action, Second Edition explains sidecar process →
Authorization in Action
A sidecar is a separately deployed component or proxy that runs alongside a primary service to provide supporting functionality.
- How it is used
- Enforces authorization on internal service-to-service calls that bypass an API gateway.
- How deep it goes
- Explains the request path through mTLS, context collection, Cedar evaluation, and forwarding, without detailing mesh configuration.
- Examples
- Uses Docs sending documents to Search, denying indexing for documents classified as Legal.
- What you can do after
- Evaluate/understand where sidecars enforce per-hop authorization and why they complement gateway enforcement.
Podman in Action: Secure, rootless containers for Kubernetes, microservices, and more
A sidecar container is an additional co-located container that supports or monitors a primary container or its execution environment.
- How it is used
- Supports or monitors a primary application by running alongside it in a tightly coupled Podman pod.
- How deep it goes
- Explains shared namespaces, cgroups, volumes, and a complete Podman creation and startup workflow.
- Examples
- Demonstrates a ubi8 sidecar rewriting shared HTML while a myapp web server serves the resulting timestamps.
- What you can do after
- Apply it via Podman CLI to create, populate, start, and inspect a pod containing a primary container and sidecar.
Acing the Certified Kubernetes Administrator Exam, Second Edition
The sidecar pattern runs a supporting process alongside a primary application process, typically within the same pod.
- How it is used
- Supports log collection and other close-coupled assistance for a primary application within one pod.
- How deep it goes
- Explains shared namespaces, shared volumes, manifest changes, and kubectl verification, but does not detail broader sidecar architectures.
- Examples
- Uses a busybox log sidecar, an emptyDir volume, Pod YAML, and kubectl logs output showing individual or combined container logs.
- What you can do after
- Apply it via kubectl by creating a two-container Pod, sharing storage, and inspecting each container's logs.
Designing Deep Learning Systems: A guide for software engineers
A container deployed alongside a primary application container to provide supporting functionality such as adaptation, proxying, or initialization.
- How it is used
- Deploys alongside model servers to adapt requests, prepare models, and preserve an existing prediction API.
- How deep it goes
- Explains container responsibilities, shared storage, request flow, model registration, and scaling, but does not provide deployment configuration.
- Examples
- Uses TorchServe and Triton pods with proxy containers that download, register, and serve models from shared repositories.
- What you can do after
- Operate/configure an adapter-proxy container that integrates a model server without changing public inference interfaces or external model storage.
Read how Designing Deep Learning Systems: A guide for software engineers explains sidecar process →
Secure APIs
A sidecar is a container-application pattern in which a secondary process runs alongside a primary application to provide supporting functionality.
- How it is used
- Uses a neighboring process to collect logs and provide supporting functionality for containerized applications.
- How deep it goes
- Defines the pattern and explains its logging flow, but does not detail sidecar implementation or orchestration configuration.
- Examples
- Illustrates a log collector agent running beside an application container and forwarding standard-output streams for analysis.
- What you can do after
- Operate/configure a container logging arrangement that collects application output beside the primary service.
Kafka for Architects
The sidecar pattern deploys an auxiliary component alongside a primary service component to provide supporting functionality without embedding it in the service.
- How it is used
- Separates service business logic from reusable cross-cutting communication and infrastructure concerns.
- How deep it goes
- Explains containers, proxy traffic flow, responsibilities, reuse, and centralized configuration without covering implementation details.
- Examples
- Uses a two-container microservice and service-mesh traffic routed through a sidecar proxy.
- What you can do after
- Operate/configure sidecar responsibilities through a service-mesh control plane.
LLMs in Production
A sidecar is a companion component deployed alongside a primary application to perform supporting processing or communication.
- How it is used
- Moves LLM monitoring and log processing out of the inference path to protect production latency.
- How deep it goes
- Explains the same-pod logging pattern and its latency rationale, but does not detail alternative sidecar configurations.
- Examples
- Uses whylogs, LangKit, fluentd, WhyLabs, and Prometheus in a Kubernetes logging arrangement.
- What you can do after
- Operate/configure parallel monitoring for an LLM service using a Kubernetes sidecar and logging tools.
Related concepts
- service meshused by · A service mesh is an infrastructure layer that manages communication and cross-cutting concerns such as traffic control, security, and observability between distributed services.
- poduses · A Kubernetes Pod is the smallest deployable unit in Kubernetes, grouping one or more co-located containers that share networking and other resources.
- containerkind of · A software container is an isolated execution environment that packages an application and its dependencies while sharing the host operating system kernel.
- Istiopart of · Istio is an open-source service mesh platform that provides traffic management, security, and observability for service-to-service communication.
- automatic sidecar injectionproduced by · Automatic sidecar injection is the admission-time addition of a proxy sidecar to newly created pods based on cluster configuration.
- NVIDIA Triton Inference Serviceuses · NVIDIA Triton Inference Server is open-source software for deploying and serving machine-learning models through standardized interfaces across frameworks and hardware backends.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.