Why do container platforms give every workload its own fleet-routable address instead of sharing each host's address?
answer
- reachability across hosts, not isolation
- who owns the port space
- what the receiver sees as the source
- placement stops leaking into config
- one address consumed per workload
basics
~20 sGiving each workload its own fleet-routable address lets any workload dial any other directly, with no port bookkeeping and no rewritten source address, so callers reach a workload rather than the host it happens to sit on.
solid answer
~50 sTwo workloads on different hosts have to reach each other, and a platform can do that in one of two ways: hide them behind the addresses of their hosts and rewrite packets on the way through, or give each workload an address the whole fleet can route to. Container platforms took the second route, and most of the model above it assumes that. Every workload owns the full port space of its own address, so ten replicas can all listen on the same number; the receiving side sees the caller's real workload address, which is what makes identity-based rules and access logs mean anything; and where a replica happens to run stops leaking into how it is configured. The price is that every workload consumes an address from a finite pool, and that the network has to be able to deliver to that address at all.
go deeper
Recall that each workload gets an address of its own and the whole port space that goes with it, which is why two copies of the same service can listen on the same number.
Explain what the flat model removes - port bookkeeping, a rewritten source address, placement leaking into configuration - and what it demands back: one address per workload, and a network able to deliver to it.
Show you have run it. Addresses are ephemeral and finite, reachability is not permission, and a caller that remembers an address breaks the first time a replica is replaced.
Weigh the estate cost: a finite pool shared across every cluster, an address plan the network owners have to agree to, and a per-workload address budget that quietly caps how far the fleet can grow.
## The choice underneath the model A device-telemetry ingester runs thousands of short-lived replicas spread over a large host fleet, and something on another host has to send each one work. A platform can make that possible in one of two ways. The first is to keep the hosts as the only addressable things. A caller targets `host address + port`, the host rewrites the packet and forwards it inward, and the workload never has an address anyone outside the host knows. The second is to give every workload an address of its own that is **routable across the whole fleet** - the caller targets the workload, and nothing along the path rewrites anything. Container platforms overwhelmingly settled on the second, and it is worth being able to say why, because nearly every other piece of workload networking is built on the assumption. ## What the flat model removes - **Port bookkeeping.** Each workload owns the entire port space of its own address. Ten replicas of the ingester on one host can all listen on the same number, and nobody has to keep a registry of which number was handed to which replica. - **A rewritten source address.** The receiver sees the caller's own address rather than the calling host's. Anything that reasons about *who* is calling - per-caller limits, access logs, rules written against workload identity - only means something if that address survives the trip. - **Placement leaking into configuration.** In the host-address model, moving a replica to a different host changes the address and possibly the port that callers must use. With per-workload addresses, placement is the scheduler's business and nobody else's. - **Asymmetry between the two views.** The address a workload believes it has is the address others reach it on. Under translation those differ, and every protocol that puts an address in its own payload - or any process that advertises where it can be found - gets it wrong. | | share the host's address | per-workload routable address | |---|---|---| | what a caller targets | a host and a port | the workload itself | | port numbers | allocated per host, must not collide | free within each workload | | source the receiver sees | the calling host, rewritten | the calling workload, unchanged | | addresses consumed | one per host | one per workload | | what the network must know | nothing extra | how to deliver to a workload address | ## What it demands in return The model is not free, and the two costs are the subject of most of the hard questions about it. 1. **Addresses become a capacity dimension.** One pool is carved up across the fleet, and a workload that cannot get an address does not start - however much processor and memory are free where it would have run. 2. **The network has to be able to deliver to a workload address.** There are two ways to arrange that. Either the fabric is told which host owns which slice of the pool, and it routes to the workload address natively; or the fabric knows nothing about workload addresses, and each sending host wraps the packet inside traffic addressed host-to-host, which the receiving host unwraps. The first needs cooperation from whoever runs the network; the second does not, which is exactly why it is common. ## Two things the model does not give you **Stability.** A workload's address belongs to that instance. Replicas are replaced constantly, the replacement gets a different address, and released addresses are recycled - so a caller that remembers an address will eventually talk to something unrelated. Something stable has to sit in front of the addresses for callers to hold on to. **Permission.** Routable means a packet *can* arrive, not that it *may*. Reachability and authorisation are separate layers, and a flat address space is emphatically the reachability one. ## Why interviewers ask it Because the flat model is the assumption every other answer rests on. A candidate who still pictures containers as processes hiding behind their host's address will get service naming, cross-host traffic, address exhaustion and rule-writing wrong in the same consistent way - and the wrongness is invisible until the fleet is large enough that it costs something.
- What must the network know for one workload to reach another workload on a different host?One of two things. Either the fabric has been told which host owns which slice of the address pool, so it routes to the workload address directly; or it knows nothing about workload addresses at all, and each sending host wraps the packet inside traffic addressed host-to-host, which the receiving host unwraps. The first needs cooperation from whoever runs the network; the second does not.
- Why can a caller not simply remember a workload's address once it has found it?Because the address belongs to that instance, not to the service. Replicas are replaced constantly, and the replacement is handed a different address, often from a different host's range. Released addresses are also recycled after a hold period, so a remembered one can later point at an unrelated workload. Callers need a stable name in front of the addresses to hold on to.
saying these in an interview costs you the question
- Says containers always share their host's address and port space.
- Thinks cross-host traffic must pass through source-address rewriting.
- Believes two replicas on one host must pick different port numbers.
- Assumes a fleet-routable address is reachable from the public internet.
- Treats a workload's address as stable enough for callers to remember.