What is a sidecar container. What would be a good example

Excellent observation 👍 — you’re right:

👉 In Kubernetes, there is no special keyword like sidecar: true in YAML.

A “sidecar container” is just another container in the same Pod. The sidecar pattern is a design convention, not a separate resource type.

Let’s break this down:

⸻

🔹 1. Why a Sidecar Works Without Special YAML

• Pod = group of containers that share resources.

• All containers inside a Pod:

• Share the same network namespace (same IP address & ports).

• Can communicate over localhost.

• Can share volumes mounted into each container.

So when you run a container to assist the main app (logging, proxying, syncing, etc.), we call it a sidecar — by convention.

In the YAML:

spec:

  containers:

    - name: main-app

      ...

    - name: sidecar-log-reader

      ...

Both are just containers. The “sidecar” role comes from its purpose, not from Kubernetes magic.

⸻

🔹 2. How Sidecar Containers Work

A sidecar works by sharing Pod-level resources with its “main” container:

• Shared filesystem → via emptyDir, configMap, secret, or persistentVolume.

• Shared networking → can connect via localhost:<port> to the main container.

• Shared lifecycle → sidecars start and stop when the Pod does.

That’s why in the log example:

• The main container writes logs to /var/log/app.log on a shared volume.

• The sidecar container tails the same file (because it mounts the same volume).

⸻

🔹 3. Access Rights of a Sidecar Container

Within a Pod:

1. Filesystem

• Only shared volumes (emptyDir, PVC, configMap, etc.) are accessible across containers.

• Sidecar cannot see the main container’s entire root filesystem unless explicitly shared.

• Example: both mount /var/log → both see the same files.

2. Network

• All containers in the Pod share the same IP and network namespace.

• They can talk over localhost, e.g., curl http://localhost:8080.

• But each container still has its own process namespace — they don’t see each other’s processes.

3. Lifecycle

• If the Pod restarts, both restart together.

• There’s no “parent/child” relationship — all containers are siblings in a Pod.

4. Security Context

• Access is further controlled by:

• Kubernetes security policies (PodSecurityPolicy, PodSecurityAdmission).

• Container user IDs (run as root vs non-root).

• Volume permissions.

So, a sidecar container only has as much access as you give it via volumes, ports, and security context.

⸻

🔹 4. Key Insight

A sidecar is not a privileged child — it’s just a peer container in the same Pod, given access to the same sandbox (network, volumes, lifecycle).

We call it a sidecar only because it assists the main container.

⸻

✅ Example:

• Logging sidecar → ships logs from main container’s shared volume.

• Proxy sidecar (like Envoy in Istio) → intercepts main container’s network traffic.

• Data loader sidecar → fetches config files into a shared volume before main starts.