You cannot compare single and multi-container pods until you know what a pod really is.

Containers need a home

A container is a sealed package holding an application and everything it needs to run. Kubernetes, however, does not run containers directly on its own. It wraps them inside a small unit called a pod, and the pod is the smallest thing Kubernetes can create, schedule and delete.

What a pod provides

A pod is like a tiny shared apartment. Everything inside lives at one address, can use the same storage and is placed on one machine. Specifically, all containers in a pod share these things.

One pod, one container, one job.

The most common pod in the world has exactly one application container inside it. When people say “one container per pod,” they mean this. The pod acts as a thin wrapper that gives Kubernetes something to manage, while the container does all the real work.

Why it is the default

Several containers, one shared home, one shared purpose.

A multi-container pod holds a main application container plus one or more helper containers. The word that matters is “helper.” The extra containers exist to support the main one, not to be independent applications. They are so tightly connected to the main container that separating them would be awkward or wasteful.

The test for “tightly connected”

Containers belong in one pod when all of the following are true.

graph TD
  subgraph POD["One Pod with one IP address"]
    M["Main application container"]
    H["Helper container"]
    V[("Shared volume")]
    M -->|localhost| H
    M --- V
    H --- V
  end
  U["Other pods and users"] --> POD
        

Sharing is what makes multi-container pods powerful and also what makes them risky.

Talking over localhost

Because all containers share one network identity, one container can call another simply by using localhost and a port number. No discovery, no external addresses and no network hops are involved. This is very fast and very simple.

Passing files through a shared volume

A volume is a folder that the pod provides. If both containers mount it, a file written by one appears instantly for the other. A common use is a helper that downloads fresh content into the folder while the main container serves it.

Port collisions

Since the network is shared, two containers in the same pod cannot listen on the same port. If both try to use the same one, the second will fail. Planning ports is therefore part of designing a multi-container pod.

Separate but linked lifecycles

Each container has its own image, its own version and its own resource settings. Each has its own health checks and is restarted individually if it crashes. But all of them are placed, started and removed as part of one pod.

Multi-container pods are not random. Engineers have named a handful of proven designs.

graph LR
  subgraph SC["Sidecar"]
    A1["App"] --- A2["Log shipper"]
  end
  subgraph AM["Ambassador"]
    B1["App"] --> B2["Proxy to remote service"]
  end
  subgraph AD["Adapter"]
    C1["App custom output"] --> C2["Translator to standard format"]
  end
        

The most popular multi-container pattern, named after the little seat attached to a motorcycle.

A sidecar rides alongside the main container and gives it extra abilities without changing its code. The main application stays simple and focused on its own business, while the sidecar handles chores that many applications share.

Typical sidecar jobs

Newer sidecar support

For a long time, sidecars were just ordinary containers, which caused awkward moments such as a sidecar starting after the app or stopping before it finished its work. Newer versions of Kubernetes added native support for sidecar containers, so helpers can be started before the main container and stopped after it. Check which features your version supports.

Three more helpers, each with a distinct personality.

The ambassador

An ambassador speaks to foreign lands on your behalf. Suppose your application must connect to a remote database that needs special secure connection steps. Instead of teaching the application those steps, you place an ambassador container in the pod. The application simply talks to localhost, and the ambassador takes care of the complicated trip, including credentials and encryption.

The adapter

An adapter is a translator. Imagine every application reports its health in a different style, but your monitoring tool expects one standard style. The adapter reads the main container’s custom output and converts it into the standard form, so every application looks the same to the monitoring system.

The init container

Init containers are the setup crew that arrives before the show. They run one at a time, in order, and each must finish successfully before the next begins. Only after all of them are done do the main containers start. Typical jobs include waiting for a database to become reachable, fetching files, or preparing folders and permissions.

sequenceDiagram
  participant K as Kubelet
  participant I1 as Init container 1
  participant I2 as Init container 2
  participant M as Main container
  participant S as Sidecar
  K->>I1: Start
  I1-->>K: Finished successfully
  K->>I2: Start
  I2-->>K: Finished successfully
  K->>M: Start main container
  K->>S: Start sidecar
  M-->>K: Running
  S-->>K: Running
        

A table makes the differences easy to scan.

If two things need to grow at different speeds, they must not share a pod.

Kubernetes scales pods, not individual containers inside them. When you ask for more copies, Kubernetes duplicates the whole pod with all its containers. That is perfect when the helper is needed once per application copy, as with a log shipper. It is a disaster when the two containers have different needs.

An example that goes wrong

Imagine a website container and a database container in the same pod. Traffic doubles and you add another pod. Now you have two databases, each with different data, and visitors bounce between them and see inconsistent information. The two parts should have been in different pods so the website could scale while the database stayed as one carefully managed service.

flowchart TD
  Q1{"Must the containers run on the same machine?"}
  Q1 -->|No| S1["Use separate pods"]
  Q1 -->|Yes| Q2{"Do they need to scale together in equal numbers?"}
  Q2 -->|No| S1
  Q2 -->|Yes| Q3{"Do they start and stop together?"}
  Q3 -->|No| S1
  Q3 -->|Yes| M1["Use one multi-container pod"]
        

Every extra container has a cost, even a small one.

Each container in a pod can state how much processing power and memory it needs, and the maximum it may use. The scheduler adds up the needs of all containers to decide which machine can host the pod. A sidecar that asks for very little still adds to the total, and across hundreds of pods those small amounts become large.

Each container is watched separately, but the pod is judged as a whole.

Kubernetes can check each container’s health separately. If one container crashes, Kubernetes restarts that container, not the whole pod, following the pod’s restart rules. However, a pod is only considered ready to receive traffic when all of its containers are ready. So a helper that never becomes ready can keep an otherwise healthy application out of service.

This is why helpers should be simple and reliable. A fragile sidecar can make a strong application look weak.

More containers mean more places to look.

In a single-container pod, asking for the pod’s logs gives you one clear stream. In a multi-container pod, you must name which container you want, otherwise you may see the wrong output or be asked to choose. Many beginners waste time reading a helper’s logs when the problem is in the main container, or the other way round.

Sharing a pod means sharing some trust.

Because containers in a pod share a network and may share files, they must trust one another. A compromised helper could read files meant for the main container or intercept local traffic. Kubernetes therefore encourages careful choices when adding helpers.

Useful when justified, harmful when overused.

Mistakes that appear again and again in real clusters.

Where you will meet both kinds of pod in everyday systems.

Typically single-container

Typically multi-container

Habits that keep pods simple and healthy.

Not at all, as long as they are truly a team that must share a machine, scale together and live together. It is wrong only when the containers are independent services.

There is no small fixed limit that matters in practice, but good design keeps it to a main container and a few helpers. Very large pods are a sign that something should be split.

Not by default. Each container has its own filesystem from its image. They share files only through volumes that you deliberately mount in both.

No. They share one network space, so each container must choose a different port.

An init container runs first, finishes and disappears. A sidecar keeps running alongside the main container for the whole life of the pod.

Kubernetes restarts the failed container, not the entire pod, according to the restart policy. But the pod may be marked not ready until all containers are healthy.

You change the pod’s template through its controller, and Kubernetes replaces pods with new ones. In practice the new pods start with the new set of containers.

Usually not. They often scale at different rates and are updated by different teams, so separate pods connected by a Service is the better design.

Each extra container adds to the pod’s resource needs, so the total cost is higher, especially when a helper is attached to a very large number of pods.

Ask three questions: must they run on the same machine, must they scale in equal numbers, and must they start and stop together? If any answer is no, use separate pods.

A pod is a shared home for containers. The single-container pod is the simple, flexible default, and it suits the great majority of applications. The multi-container pod is a specialist design for a main application and its close helpers, such as sidecars, ambassadors, adapters and init containers, which share a network, storage and life. The choice comes down to how tightly the containers are bound together. When they must sit on the same machine, scale in equal numbers and start and stop together, share a pod. In every other case, give each its own.