A helper container must scrape a worker's endpoint bound to loopback - what must be true of both containers?

seniorshould knowfreq 38%

answer

loopback is the thing being shared
same host is not enough
one address, one port space
port numbers now need deconflicting
still separate containers otherwise

basics

~20 s

They must be placed in one shared network view, not merely on the same host. Sharing the view gives them one interface, one address, one loopback and one port space, so the helper's call to loopback reaches the worker instead of itself.

solid answer

~40 s

Co-location on a host is not enough: each container would still have its own loopback, so the helper's call to the loopback address would reach only the helper. The platform has to place both containers in one shared network view, and then a single interface, address, loopback and port space are held in common. The helper's scrape of the loopback address now arrives on the interface the worker is bound to, and the traffic never leaves the view - the endpoint stays unreachable from anywhere else, which is usually the point. Two costs come with it. The shared port space has to be deconflicted by hand, since both containers can no longer use the same number. And callers outside see one address for the pair, so the two are no longer separately addressable.

Co-location on a host is not enough: each container would still have its own loopback, so the helper's call to the loopback address would reach only the helper. The platform has to place both containers in **one shared network view**, and then a single interface, address, loopback and port space are held in common. The helper's scrape of the loopback address now arrives on the interface the worker is bound to, and the traffic never leaves the view - the endpoint stays unreachable from anywhere else, which is usually the point. Two costs come with it. The shared port space has to be deconflicted by hand, since both containers can no longer use the same number. And callers outside see one address for the pair, so the two are no longer separately addressable.

code

yaml · 10 lines

yaml

workload: search-indexer
sharedNetworkView: true      # one interface, one address,
                             # one loopback, one port space
containers:
  - name: indexer
    listenAddress: loopback   # private: unreachable outside this view
    listenPort: 8080
  - name: status-scraper
    scrapeTarget: loopback:8080
    listenPort: 9100          # must differ from 8080: one port space now

go deeper

for a junior

Remember that loopback only works between containers that share one network view; being scheduled onto the same host does not give them a shared loopback.

for a middle

Explain what a shared view holds in common - one interface, address, loopback and port space - and why that makes a loopback-bound endpoint reachable by the other container and by nothing else.

for a senior

Weigh the arrangement against binding all addresses: the shared view keeps a private endpoint off every reachable interface, at the price of hand-deconflicted ports, one address for the pair and a coupled lifecycle.

for a principal

Decide where this belongs as a standard: helpers that exist only for one workload share its view, while anything that other teams call, scale or release independently keeps its own address and its own port budget.

What sharing a view actually means

The default is one network view per container. A platform can instead place several containers in one view, and the containers then hold in common exactly the things a view contains:

one interface, and therefore one address that outside callers use for the pair;
one loopback, so localhost in either container means the same place;
one port space, so a number bound by one is unavailable to the other;
one set of routes, and one place where inbound and outbound rules apply.

Everything else stays separate. The containers still have their own filesystems, their own images, their own processes and their own resource ceilings - sharing a view is a networking arrangement, not a merge.

Why co-location alone does not do it

Two containers scheduled onto the same host, each with its own view, are as far apart on the network as two containers on different hosts. Each has its own loopback; the helper's call to the loopback address is delivered to the helper's own stack and refused. The host they happen to share is not part of the path at all.

This is the single most common wrong answer on this material, and the reason is that 'same machine' is exactly the property that used to be sufficient.

Before and after

	Separate views, same host	One shared view
Call to the loopback address	reaches the caller itself	reaches whichever container bound it
Reaching the worker's private endpoint	impossible without changing the bind	works as-is
Port 8080 in both containers	fine, two port spaces	second bind fails, one port space
Address seen by outside callers	one each	one for the pair

Why this arrangement is chosen

The alternative to sharing a view is to make the worker bind all addresses so the helper can call it by address. That works, and it is strictly worse for a private endpoint: the moment it is bound to all addresses it is reachable by anything that can route to the container, which in a permissive network is every workload around it. A status, metrics or profiling endpoint exposed that way is a real information leak, and closing it again means a permission rule, which is more machinery than the problem needs.

Sharing the view keeps the endpoint on loopback. The traffic never touches an interface anything else can reach, no rule is needed to protect it, and there is nothing to misconfigure later.

What it costs

Three costs, all of them real:

Manual port deconfliction. One port space between the containers means every listener needs a distinct number, including ones added later. A helper added months afterwards can break a worker's start-up simply by choosing a number that is already taken.
One identity to callers. The pair share an address, so nothing outside can address the two halves separately, and rules written against that address apply to both.
A coupled lifecycle and blast radius. The view is created and destroyed as a unit, so the containers start and stop together, and a networking problem with the view is a problem for both.

Checking the arrangement actually has the property

If someone claims a helper is successfully scraping a loopback-bound endpoint, three things must all hold, and it is worth naming them explicitly:

the worker is bound to the loopback address and is listening on the number the helper scrapes;
both containers are in one shared network view, not merely on one host;
the two containers' listening ports do not repeat a number, or one of them never started.

If the scrape works while the containers are in separate views, then the endpoint is not really on loopback - it is bound to all addresses and reachable by anything else that can route there, which is a different situation with a different risk.

When not to do it

Where the helper is genuinely a service of its own - called by other workloads, scaled on its own, released on its own schedule - sharing a view is the wrong tool, because it fixes the helper's address, lifecycle and port budget to the worker's. Sharing a view is for the case where the helper exists only to serve this one workload and needs to see what only that workload can see.

## What sharing a view actually means The default is one network view per container. A platform can instead place several containers in **one** view, and the containers then hold in common exactly the things a view contains: - one **interface**, and therefore one **address** that outside callers use for the pair; - one **loopback**, so `localhost` in either container means the same place; - one **port space**, so a number bound by one is unavailable to the other; - one set of routes, and one place where inbound and outbound rules apply. Everything else stays separate. The containers still have their own filesystems, their own images, their own processes and their own resource ceilings - sharing a view is a networking arrangement, not a merge. ## Why co-location alone does not do it Two containers scheduled onto the same host, each with its own view, are as far apart on the network as two containers on different hosts. Each has its own loopback; the helper's call to the loopback address is delivered to the helper's own stack and refused. The host they happen to share is not part of the path at all. This is the single most common wrong answer on this material, and the reason is that 'same machine' is exactly the property that used to be sufficient. ## Before and after | | Separate views, same host | One shared view | |---|---|---| | Call to the loopback address | reaches the caller itself | reaches whichever container bound it | | Reaching the worker's private endpoint | impossible without changing the bind | works as-is | | Port 8080 in both containers | fine, two port spaces | second bind fails, one port space | | Address seen by outside callers | one each | one for the pair | ## Why this arrangement is chosen The alternative to sharing a view is to make the worker bind all addresses so the helper can call it by address. That works, and it is strictly worse for a private endpoint: the moment it is bound to all addresses it is reachable by anything that can route to the container, which in a permissive network is every workload around it. A status, metrics or profiling endpoint exposed that way is a real information leak, and closing it again means a permission rule, which is more machinery than the problem needs. Sharing the view keeps the endpoint on loopback. The traffic never touches an interface anything else can reach, no rule is needed to protect it, and there is nothing to misconfigure later. ## What it costs Three costs, all of them real: 1. **Manual port deconfliction.** One port space between the containers means every listener needs a distinct number, including ones added later. A helper added months afterwards can break a worker's start-up simply by choosing a number that is already taken. 2. **One identity to callers.** The pair share an address, so nothing outside can address the two halves separately, and rules written against that address apply to both. 3. **A coupled lifecycle and blast radius.** The view is created and destroyed as a unit, so the containers start and stop together, and a networking problem with the view is a problem for both. ## Checking the arrangement actually has the property If someone claims a helper is successfully scraping a loopback-bound endpoint, three things must all hold, and it is worth naming them explicitly: - the worker is bound to the **loopback address** and is listening on the number the helper scrapes; - both containers are in **one shared network view**, not merely on one host; - the two containers' listening ports **do not repeat** a number, or one of them never started. If the scrape works while the containers are in separate views, then the endpoint is not really on loopback - it is bound to all addresses and reachable by anything else that can route there, which is a different situation with a different risk. ## When not to do it Where the helper is genuinely a service of its own - called by other workloads, scaled on its own, released on its own schedule - sharing a view is the wrong tool, because it fixes the helper's address, lifecycle and port budget to the worker's. Sharing a view is for the case where the helper exists only to serve this one workload and needs to see what only that workload can see.

What breaks when a third container joins a view whose ports are already in use?
Its bind fails at start-up with the number already claimed, because the view has one port space. Either the newcomer is renumbered or an existing listener is, and that coordination cost is permanent - every future addition has to know what the others already hold.
If the worker bound all addresses instead, would the shared view still be needed?
Not for reachability - the helper could then call the worker by address from its own view, given a route and permission. But the endpoint would also be reachable by every other workload that can route there, so the shared view is what lets it stay private while remaining scrapeable.
What is still not shared between two containers in one network view?
Everything that is not networking: each keeps its own filesystem, its own image, its own processes and its own resource ceiling. The shared view changes who can reach whom, not what either container is made of.

saying these in an interview costs you the question

Thinks running on the same host is enough for loopback
Assumes both containers keep independent port spaces
Believes a shared view merges them into one container
Says the helper can reach a loopback bind over the network
Overlooks that callers now see one address for both

A helper container must scrape a worker's endpoint bound to loopback - what must be true of both containers?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What sharing a view actually means

Why co-location alone does not do it

Before and after

Why this arrangement is chosen

What it costs

Checking the arrangement actually has the property

When not to do it

▾common follow-ups3 questions

▾red flags5 flags

What sharing a view actually means

Why co-location alone does not do it

Before and after

Why this arrangement is chosen

What it costs

Checking the arrangement actually has the property

When not to do it

answer

go deeper