Placement and allocation

The problem

Somebody has to choose which machine runs each container. Chosen by hand, that choice is correct on the day it is made and wrong the first time a machine fills up, a new one is added, or one is drained. Chosen arbitrarily, it puts the database replica and its own standby on the same machine, which is the arrangement that was supposed to be impossible.

How the platform solves it

Placement is decided from the description, on every dispatch, by the same rules for everybody.

You say what matters, not where to put it. A deployment can steer toward nodes carrying a label, away from nodes carrying another, prefer a zone, or — when there is a real reason — name a node outright. The accepted forms are in the deployment reference.

The block compiles into what the scheduler reads. The steering you write is turned into the same label constraints the scorers have always read, so the first-class block and the older hand-written labels are one mechanism rather than two. Writing both forms of the same constraint is refused rather than silently resolved: the platform does not decide which of your two answers you meant.

A tenant’s deployment is placed only on that tenant’s nodes. Placement never crosses the isolation boundary described in tenancy and isolation.

Placement is advisory about capacity, not a reservation. Resource requests inform the choice; they do not fence off memory in advance. What limits a container at runtime is its limits, which are part of what shapes it — change them and the container is replaced.

Not this

This page does not explain how to label a node or how to drain one; those are operational procedures, not properties of a deployment.

It also does not carry the scoring weights or the per-field accepted values. The fields and their rules are generated into the reference.

Where to see it

• The placement block and what each key does: deployment manifest.
• Why a placement was refused: rejections and alterations.