Placement constraints і preferences

Після модуля ви зможете моделювати topology через node labels, застосовувати обов’язкові constraints і м’які placement preferences та виправляти Pending tasks.

• створювати namespaced labels
• розрізняти eligibility і ranking
• перевіряти spread
• читати scheduler rejection

Node label — operator-controlled metadata у node spec. Він описує zone, rack, storage або capability та відрізняється від Engine labels. Префікс курсу зменшує ризик конфлікту.

Label не перевіряє реальну властивість машини. Оператор відповідає за відповідність metadata інфраструктурі.

Constraint — жорсткий фільтр eligible nodes. Усі constraints мають виконуватися одночасно.

Якщо придатних nodes немає, desired task залишається Pending. Orchestrator запускає його, коли label, availability або spec виправлено.

Preference ранжує eligible nodes, але не забороняє розміщення. spread прагне рівномірно розподілити tasks за значеннями label. Спочатку діють constraints.

Відсутнє значення утворює окрему групу. Preference не є строгою anti-affinity.

Constraint зменшує доступну місткість і failure domains. У перевірці zone=a виключив manager-3, а чотири tasks розподілилися 2+2 між rack r1/r2.

Labels не резервують CPU/RAM і не гарантують унікальний node.

• Документуйте зміст label
• Перевіряйте labels через node inspect
• Спочатку constraints, потім preference
• Порівнюйте фактичний розподіл
• Pending досліджуйте через --no-trunc
• Видаляйте service раніше labels

Позначте дві zones і два rack. Labels мають префікс swarm.m13.

ssh swarm-manager-3 docker node update --label-add swarm.m13.zone=a --label-add swarm.m13.rack=r1 swarm-manager-1
ssh swarm-manager-3 docker node update --label-add swarm.m13.zone=a --label-add swarm.m13.rack=r2 swarm-manager-2
ssh swarm-manager-3 docker node update --label-add swarm.m13.zone=b --label-add swarm.m13.rack=r1 swarm-manager-3
ssh swarm-manager-3 docker node inspect swarm-manager-1 swarm-manager-2 swarm-manager-3 --format '{{.Description.Hostname}} {{json .Spec.Labels}}'

Дозвольте лише zone=a і створіть чотири replicas зі spread за rack. Очікується 2+2 на manager-1/2.

ssh swarm-manager-3 docker service create --detach=true --name swarm-m13-placed --replicas 4 --constraint node.labels.swarm.m13.zone==a --placement-pref spread=node.labels.swarm.m13.rack alpine:3.22 sleep 3600
ssh swarm-manager-3 docker service ps swarm-m13-placed
ssh swarm-manager-3 docker service inspect swarm-m13-placed --pretty

Неіснуюча zone=c дає no suitable node. Замініть constraint на zone=b; task стане Running на manager-3.

ssh swarm-manager-3 docker service create --detach=true --name swarm-m13-pending --replicas 1 --constraint node.labels.swarm.m13.zone==c alpine:3.22 sleep 3600
ssh swarm-manager-3 docker service ps swarm-m13-pending --no-trunc
ssh swarm-manager-3 docker service inspect swarm-m13-pending --pretty

ssh swarm-manager-3 docker service update --detach=false --constraint-rm node.labels.swarm.m13.zone==c --constraint-add node.labels.swarm.m13.zone==b swarm-m13-pending
ssh swarm-manager-3 docker service ps swarm-m13-pending

• constraints not satisfied — labels/spec
• insufficient resources — reservations
• node unavailable — availability/status
• platform mismatch — image/platform

• Чим label відрізняється від властивості?
• Що визначає eligibility?
• Чому spread не anti-affinity?
• Як неповні labels впливають на групи?
• Чому Pending може виправитися?
• Як placement скорочує capacity?

Модуль засвоєно, якщо ви прогнозуєте eligible nodes, отримуєте 2+2 spread і усуваєте Pending зміною spec.

ssh swarm-manager-3 docker service rm swarm-m13-placed swarm-m13-pending
ssh swarm-manager-3 docker node update --label-rm swarm.m13.zone --label-rm swarm.m13.rack swarm-manager-1
ssh swarm-manager-3 docker node update --label-rm swarm.m13.zone --label-rm swarm.m13.rack swarm-manager-2
ssh swarm-manager-3 docker node update --label-rm swarm.m13.zone --label-rm swarm.m13.rack swarm-manager-3
ssh swarm-manager-3 docker service ls