Understanding the Differences Between Sidecar and Co-located Containers in Kubernetes

In Kubernetes, a Pod can host multiple containers that share the same network and volumes. Two common patterns used here are Sidecar and Co-located containers—each serving different purposes.

🔹 Sidecar Containers

Sidecars are supporting containers that enhance the main app—handling things like logging, monitoring, or proxying—without touching the app code.

Since v1.29, Kubernetes allows sidecars to be defined as initContainers with restartPolicy: Always, meaning they start before the main app and continue running with it.

✅ Use Case: Syncing secrets from an external vault.

initContainers:
  - name: vault-sync
    image: hashicorp/vault
    command: ["vault", "agent", "-config=/etc/vault/config.hcl"]
    volumeMounts:
      - name: shared-secrets
        mountPath: /secrets
    restartPolicy: Always

containers:
  - name: my-app
    image: mycompany/app
    volumeMounts:
      - name: shared-secrets
        mountPath: /app/secrets
volumes:
  - name: shared-secrets
    emptyDir: {}        

🧠What it does:

A Vault Agent container pulls secrets from HashiCorp Vault and writes them to a shared volume. The main app reads those secrets from the same volume.

Why it’s a sidecar:

• It supports the app without changing app logic
• Starts before the app (via initContainer)
• Keeps running and can restart if needed

🔸 Co-located Containers: “Built to Collaborate”

Co-located containers are equal partners inside the Pod. They don’t just support—they share responsibility. They often represent tightly integrated micro-processes, like a UI served by one container and a backend running in another.

✅ Use Case: A PDF generator with a lightweight web viewer.

containers:
  - name: pdf-engine
    image: mycompany/pdf-gen
    ports:
      - containerPort: 9000
  - name: pdf-preview-ui
    image: mycompany/pdf-ui
    ports:
      - containerPort: 3000        

What it does:

One container generates PDF files, and another serves a web UI to view/download them. Both work together in the same Pod.

Why it’s co-located:

• Both are essential to the app
• No fixed start order
• Run side-by-side with shared responsibility

🔧 Feature Comparison

🧩 Sidecar Containers

• Role: Supports the main app

• Start Order: Starts before the app (via initContainer)

• Lifecycle: Tied to the main container, but can restart independently

• Examples: Log shippers, secret sync, proxies

🤝 Co-located Containers

• Role: Shares responsibility equally

• Start Order: No guaranteed order

• Lifecycle: Fully independent

• Examples: UI + backend, API + exporter

📌 Final Thoughts

With native sidecar support in Kubernetes v1.29, the pattern is now official and more reliable. But not everything is a sidecar. Sometimes, containers truly share the workload—that’s when you go co-located.

💡 Choose based on intent, not just placement.