How do you decide whether two processes belong in the same Kubernetes Pod or in two separate Pods? Give the criteria you apply and what each choice costs you.

## Why this is a judgement call The Pod is not just a packaging convenience; it is the boundary at which Kubernetes makes four decisions simultaneously: 1. **Scheduling** - the Pod is placed as a unit and its resource requests are the *sum* of its containers, so a fat companion can make the Pod unschedulable on smaller nodes. 2. **Scaling** - replicas multiply the whole Pod. You cannot have more of container B than of container A within one Pod. 3. **Rollout** - changing any container's image produces a new Pod template hash and rolls the whole thing. 4. **Failure and lifecycle** - containers share the sandbox, the grace period and eviction. QoS class is computed across the Pod, so one container without limits changes the eviction risk for all of them. A decision to co-locate accepts coupling on all four axes in exchange for three benefits only: `localhost` networking (no hop, no discovery), shared volumes, and atomic co-lifecycle. ## The criteria I actually apply **Scaling ratio.** The sharpest test. If two components have different load profiles - an API server and an image resizer - they must scale independently, which means separate Pods and separate Deployments. **Communication substrate.** Do they *require* a shared filesystem or shared network namespace? A log shipper tailing files, a proxy intercepting the app's loopback traffic, a helper that must observe a local socket - those are impossible across Pods without extra machinery. Two services talking HTTP are not: a Service plus a network hop is the normal answer. **Fate sharing.** Ask: "if the main container is gone from this node, is the companion still useful here?" If not, co-locate. A warm-cache loader for *this* instance shares fate; a shared cache does not. **Release independence and ownership.** If two teams ship on different cadences, one Pod forces their release trains together and makes rollbacks ambiguous. A platform-owned agent versioned with the app is a fine co-tenant - though a per-node DaemonSet is usually the better home for a fleet-wide agent, since one instance per node beats one per Pod for footprint. **Resource and isolation cost.** Each co-located container adds to the Pod's requests, competes inside the Pod's limits, and can push the Pod into a worse QoS class or off smaller nodes. High-memory companions are the usual regret. **Blast radius.** A companion in CrashLoopBackOff keeps the Pod permanently not-fully-healthy, and its OOM can tip the node into memory pressure. Ask what the failure of the *lesser* component should do to the *greater* one; if the honest answer is "nothing", separate them. ## The two failure modes **Over-packing** - bundling an app, its database and a queue into one Pod because "they are the same product". The result is an unscalable, unrollable monolith with a shared blast radius, which silently loses you the reason Kubernetes was adopted. **Under-packing** - splitting a helper that genuinely needs the app's files or loopback into its own Pod, then reinventing the sharing with a network filesystem, a hostPath or a shared PVC. That trades a simple co-location for a distributed-systems problem. ## How I would answer as an architect State the decision rule crisply - *co-locate only for fate sharing plus a physical need for a shared namespace or filesystem; otherwise separate* - then name what is given up in each direction, and finish with the platform-level standard: a small approved catalogue of co-tenant patterns (log/metrics agent, local proxy, file-sync helper) with capped resource requests, and everything else as its own workload. A rule, its costs, and a governance answer is what separates a principal answer from a list of patterns.