Two containers on one host both listen on port 8080 internally, so why can only one publish host port 8080?
answer
- a claim is address plus port
- inside is private, outside is shared
- the collision is on the host side
- map a different host port instead
- fixed host port constrains placement
basics
~20 sA host port is an exclusive claim on a host address, so only one mapping can hold it there. Inside, each container has its own network view, so both processes can hold 8080 without ever meeting.
solid answer
~40 sThe inside and the outside are two different places to claim a number. Each container has a private network view, so `8080` inside container A and `8080` inside container B are claims in separate spaces and cannot collide. A published host port is a claim on the machine's address, and that space is shared by everything on the box, so the second mapping simply fails — the port is taken. The fix is never to rebuild an image on a different port: publish the second workload on a different **host** port pointed at the same container port, or claim it on a different host address. The deeper consequence is on a fleet: a fixed published host port makes the host a scarce resource, so only one instance of that workload can run per machine.
go deeper
Hold on to the two-places idea: the number inside the container is private to it, and the number on the host is shared by everything on the machine. Only the shared one can collide.
Explain that a claim is an address and a port together, so the same number can live on two host addresses, and that the everyday fix is a different host port mapped onto the unchanged container port.
Bring up what a fixed published port does to operations: one instance per machine, a replacement that cannot start before the old one releases the port, and a machine-scoped number space somebody has to allocate.
Decide the estate's stance. Fixed host ports are an allocation problem that grows with the fleet, so say when publishing on the host is allowed at all and what workloads use instead.
## Two different places to claim a number A port number by itself is not a thing anyone owns; a **claim** is a pair — an address and a port — inside one network stack. Containers are given their own network view with their own address, so a process binding `8080` in container A and a process binding `8080` in container B are claiming the number in two separate spaces that never see each other. Neither has to know the other exists, and no coordination is required. A **published host port** is a claim in a space that everything on the machine shares. Only one holder can have a given address-and-port pair there at a time, whether the holder is a container mapping, a process running directly on the host, or something left over from a workload that did not shut down cleanly. The second mapping does not queue, share, or take over — it fails outright. | | claimed inside the container | claimed as a published host port | |---|---|---| | scope of the claim | that container's network view alone | the whole machine, per host address | | who else competes | nothing | every workload and every host process | | effect of a duplicate | none; both run happily | the second mapping fails to come up | | who resolves it | nobody has to | whoever allocates ports on that host | ## What the failure actually is The message is about the host, and it is worth reading it that way: the port on that host address is already in use. Two consequences follow that candidates often get backwards. - It is **not** a defect in the container, the image, or the application. Nothing inside needs to change. - It is **not** resolved by restarting the losing workload; it wins only if the previous holder released the claim in the meantime. - It **is** specific to an address. The same number can be claimed twice on one machine if the two claims are on different host addresses, because the pair differs. ## Three ways out, in the order they are usually reached for 1. **Map a different host port onto the same container port.** Publish the second order API as host `18081` delivering to `8080` inside. The image and the application are untouched; only the deployment's mapping changes. This is the everyday answer. 2. **Claim the same number on a different host address.** Legitimate where a machine holds several addresses and you want a clean split, and brittle where addresses come and go. 3. **Stop publishing on the host at all.** Reach the workloads through the platform's own internal path instead, so nothing competes for the machine's port space. That trades a local, hands-on hop for platform machinery, which is a different subject with its own trade-offs. ## What a fixed published port costs on a fleet On one machine a collision is an annoyance. Across a fleet it becomes a **placement constraint**, and this is the part interviewers are usually fishing for: - At most one instance of that workload can run per machine, so the number of copies you can run is capped by the number of machines, not by how much CPU and memory they have. - Replacing an instance is harder, because a replacement cannot start beside the old one on the same machine and wait to become healthy — the port is still held. The replacement has to wait for the old one to release it, or land elsewhere. - Every workload that publishes a fixed host port is silently claiming a slice of a shared, machine-scoped namespace, which somebody eventually has to allocate — usually a spreadsheet, and eventually a registry of who owns which number. - A machine that already runs something on that number, including a host-level agent that predates the workload, is quietly excluded as a placement target. ## The rule to carry away Inside is private, outside is shared. Duplicate container ports are free and expected; duplicate published host ports are an exclusive resource with exactly one holder per address. Any answer that proposes changing what the application binds in order to resolve a host-side collision has the direction of the problem backwards.
- How can two workloads that both want port 8080 published on one machine coexist?Give them different host ports mapped onto the same container port, or claim the same number on two different host addresses. Rebuilding one of them to listen on a different port inside is the wrong lever — the collision was never in the container.
- What does a fixed published host port do to where a workload may run in a fleet?It becomes a placement constraint: one instance per machine at most, replica count capped by machine count, and a replacement that cannot start beside the instance it replaces because the port is still held. Machines already using that number are excluded outright.
saying these in an interview costs you the question
- Thinks two containers cannot both listen on 8080 inside themselves
- Proposes rebuilding the image on another port to fix a host collision
- Believes a port number can be claimed only once per machine, whatever the address
- Expects the host to share or alternate a contested port between containers
- Treats a fixed published host port as free when deciding where workloads run