skip to content

When a scheduler places several containers as one co-located group, what do those members share?

level: juniorimportance: must knowfreq 62%

answer

  1. one unit, not one container
  2. the same host is the precondition
  3. one address between all members
  4. loopback reachable, one port space to divide
  5. placed, replaced and deleted together

basics

~20 s

Members of a co-located group share one host, one network address and port space, and a scratch area every member can mount. The group is also what the platform places, replaces and deletes — never one member on its own.

solid answer

~40 s

Three things are shared, and one consequence follows from them. The members land on the **same host**, which is what makes the rest possible. They share a single **network address and port space**, so they reach one another over the loopback address with no name lookup, and no two members may bind the same port. They share a **scratch area** that each member mounts, which is how a file written by one is read by another. The consequence is granularity: the group is what the scheduler places, what a changed spec replaces and what a delete removes. A crashed member can still be restarted in place on the same host, but no member is scheduled, upgraded or removed on its own.

code

yaml · 9 lines
yaml
unit: search-indexer
sharedScratch: /work              # one area, mounted by every member
members:
  - name: indexer
    image: indexer@<digest>
    listenPort: 8080
  - name: synonym-refresher
    image: refresher@<digest>
    listenPort: 9100              # must differ: one address, one port space

go deeper

for a junior

Be able to name the three shared things — host, network address and port space, scratch area — and say that the group is placed and deleted as one object.

for a middle

Explain why the three imply one another: the same host makes a shared address possible, and a shared address makes the port space a group-wide resource the members must divide between them.

for a senior

Show where the granularity costs you in production: every member restarts when any member's image changes, so a busy main process pays for a helper's release cadence.

for a principal

Frame it as a packaging standard. What earns a place in a group is what genuinely needs the shared address or the shared scratch area; everything else buys coupled restarts for nothing.

## The unit a scheduler actually places A cluster scheduler does not place containers one at a time. The smallest thing it places is a **group**: one or more containers declared together, landing on one host, and treated from then on as a single object. A group with exactly one member is the ordinary case, and most workloads are exactly that; a group with several members is how you express containers that genuinely have to sit next to each other. Co-location here is a guarantee, not a preference or a scheduling hint. The members are promised the same host, because the things they share are only possible on one machine. ## The three things members share - **One host.** Every member runs on the same machine. This is the precondition for the other two, and it also bounds the group: the scheduler has to find a single machine with room for all of the members at once, so a group cannot be larger than one host can hold. - **One network address and one port space.** The group, not the member, is what is reachable. Members call one another on the **loopback** address and an agreed port, so the call never leaves the host and no name resolution is involved. The other side of that coin is that the port space is a group-wide resource: two members cannot both bind the same port, exactly as two processes on one machine cannot. - **A scratch area both can see.** The group declares a scratch area, each member mounts it at a path of its own choosing, and a file written by one member is readable by another. That is the file-level channel between members, and it belongs to this instance of the group. What is *not* shared matters just as much, because it is where the intuition that a group is 'one machine running several services' breaks: | Shared by every member | Private to each member | |---|---| | the host the group is placed on | its own root filesystem, from its own image | | the network address and its port space | its own command and arguments | | the declared scratch area | its own resource reservation and ceiling | | placement, replacement and deletion | its own exit code and in-place restarts | ## Granularity: the platform acts on the group The practical consequence is that three operations happen to the group as a whole: 1. **Placement.** The scheduler evaluates the group once and picks one host for all of its members. There is no outcome in which two members land in different places. 2. **Replacement.** A change to any member's declared image or settings produces a **new group instance**. The platform starts a replacement and removes the old one; it does not swap a member inside a running group. 3. **Deletion.** Removing the workload removes every member. There is no per-member delete. The one thing that does happen at member granularity is an **in-place restart**: when a member's process exits, the node agent starts that member again on the same host while the rest of the group keeps running, and the group keeps its address and its scratch area. That is the distinction to be precise about — a member can be restarted, but no member is scheduled, upgraded or removed on its own. ## Where this bites in practice - Two components that each default to the same listening port cannot be co-located until at least one of them makes the port configurable. - A helper whose image changes weekly imposes a weekly restart on every other member of its group, including a process with an expensive cold start. - Anything written into the shared scratch area is gone once the group is replaced, so the area is a handoff channel, not storage. - Callers must not cache the group's address across a replacement, because a new instance is reachable at a new one. - A member cannot be scaled on its own: adding capacity means more copies of the whole group, helper and all. ## The rule to carry away A member earns its place in a group when it genuinely needs the shared address or the shared scratch area — when it has to be reachable as the same thing, or has to read and write the same files, as the main workload. Everything else co-located for convenience buys coupled restarts and a divided port space and returns nothing. Platforms differ in how much else they let members share and in what they call the declaration, but the granularity is the same everywhere: the group is the unit.

  • Do members of a co-located group need name resolution to reach each other?
    No. They share one address, so a member calls another on the loopback address and an agreed port; nothing leaves the host and no lookup happens. A name would only resolve back to the group's own address, adding a resolution step to a call that is already local.
  • If one member crashes, does the whole group move to another host?
    No. The node agent restarts that member in place while the others keep running, and the group keeps its address and its scratch area. The group is placed somewhere else only when the group itself is lost or replaced — the host fails, or a changed spec produces a new instance.
  • Is a group with a single member a special case?
    No, it is the common case. Most workloads declare one member, and the group is still what gets placed, replaced and deleted. That is why the granularity rules read identically whether a workload has one member or four — multi-member groups only make the rules visible.

saying these in an interview costs you the question

  • Thinking every member gets its own network address
  • Expecting two members to bind the same port
  • Treating the group as one machine running several services
  • Believing the platform can upgrade one member alone
  • Assuming the shared scratch area survives the group