A reservation is an accounting entry against the node, and the scheduler does that subtraction before it looks at anything the container is doing. On the 5.772 GiB test node, Service A's 3.463 GiB reservation leaves 2.309 GiB that Swarm is still willing to promise [15]. Service B asked for 2.886 GiB [6]. It is short by 0.577 GiB, so the task sits at Pending with "no suitable node (insufficient resources on 1 node)" [15][7]. Runtime consumption is not an input to that comparison. `docker stats` will keep agreeing with you about the 480 KiB for as long as you keep asking it [5][13].
The size of the gap is the part worth carrying around. Service A's reservation is roughly 7,565 times the memory the container actually used [16]. After the fix, the node has 80% of its memory committed while the two lab containers together consume about 960 KiB, on the order of 0.016% of capacity [17]. Both numbers are correct at once, and only one of them decides placement.
What has to be true for this to transfer. The reproduction script derives reservations as percentages of whatever the node reports, so the 110% failure and the 80% success reproduce on a node of any size [3]. The 480 KiB does not transfer: it is a property of an Alpine container sleeping in a loop [2], and your service will idle wherever it idles. If your reservations came from a real measurement rather than a percentage, the arithmetic is unchanged. The number to argue about is still the declared reservation, because that is the only one the filter reads.
Two things in the documentation make this deliberate rather than surprising. `--reserve-memory` is not a runtime cap, and `--limit-memory` is the flag that enforces a maximum a task may consume [10]. And the pending behaviour is documented per node: if no node has enough memory available to satisfy a service's reservation, the task stays pending [11]. My reading of that phrasing is that a reservation is not divisible across hosts, so adding capacity helps only when a single node can hold the whole declared figure. The lab had one node, so it cannot settle that on its own [1].
The failure mode the author points at is the one that costs real money. If infrastructure scaling and workload scheduling read different signals, an external autoscaler whose scale-out rule watches host CPU utilization and host runtime memory sees a quiet host [14]. The scheduler, meanwhile, is refusing work on commitments nobody is using. Nothing scales out, and nothing gets placed. Fixing it took one reservation change from 50% to 20%, with no memory added, no node added, no daemon restart, and no change to the application [8][9].
