Limits, reservations і місткість

Після модуля ви зможете розрізняти reservations і limits, пояснювати scheduler capacity, розпізнавати OOM та обчислювати N−1 headroom.

• резервувати CPU/RAM для placement
• обмежувати runtime consumption
• діагностувати insufficient resources
• інтерпретувати exit 137

Reservation повідомляє scheduler мінімальну місткість task. Вона віднімається з планованих ресурсів node, навіть якщо процес їх не використовує. Це admission model, а не попереднє виділення RAM.

Scheduler не бачить усю зовнішню нагрузку OS, тому потрібен експлуатаційний запас.

Limit задає cgroup ceiling. CPU limit обмежує процесор, memory limit призводить до OOM kill. 128 MiB allocation за 32 MiB limit дала exit 137.

Exit 137 означає SIGKILL, але без inspect, kernel log і metrics не доводить OOM.

Кожен node повідомляє 4 CPU і 6207012864 байт RAM. Для чотирьох reservations по 4 GiB доступні лише три slots.

N−1 вимагає розмістити workload на двох nodes із запасом для OS, Engine, updates і сплесків. Reservations визначають admission.

• Вимірюйте allocatable і baseline
• Reservation задавайте за сталим мінімумом
• Limit перевіряйте тестом
• OOM запускайте з restart none
• Не створюйте pressure на кількох nodes
• Чекайте завершення update

Зафіксуйте advertised resources і поточне навантаження. Scheduler та free в OS відповідають на різні питання.

ssh swarm-manager-3 docker node inspect swarm-manager-1 swarm-manager-2 swarm-manager-3 --format '{{.Description.Hostname}} cpus={{.Description.Resources.NanoCPUs}} memory={{.Description.Resources.MemoryBytes}}'
ssh swarm-manager-3 docker stats --no-stream

Чотири tasks резервують по 4 GiB. Очікуються 3/4 та insufficient resources on 3 nodes; sleep майже не витрачає RAM.

ssh swarm-manager-3 docker service create --detach=true --name swarm-m14-reserved --replicas 4 --reserve-memory 4G --limit-memory 5120M alpine:3.22 sleep 3600
ssh swarm-manager-3 docker service ps swarm-m14-reserved --no-trunc
ssh swarm-manager-3 docker service inspect swarm-m14-reserved --pretty

Зменште reservation до 1 GiB і limit до 2 GiB. Після update сервіс досягне 4/4.

ssh swarm-manager-3 docker service update --detach=false --reserve-memory 1G --limit-memory 2G swarm-m14-reserved
ssh swarm-manager-3 docker service ps swarm-m14-reserved

Task на manager-1 виділяє 128 MiB за limit 32 MiB. Очікуються Failed та exit 137 без restart loop.

ssh swarm-manager-3 docker service create --detach=true --name swarm-m14-oom --replicas 1 --constraint node.hostname==swarm-manager-1 --limit-memory 32M --restart-condition none python:3.13-alpine python -c 'a=bytearray(128*1024*1024);print(len(a))'
ssh swarm-manager-3 docker service ps swarm-m14-oom --no-trunc
ssh swarm-manager-1 docker ps -a --filter label=com.docker.swarm.service.name=swarm-m14-oom

ssh swarm-manager-3 docker service inspect swarm-m14-reserved --pretty
ssh swarm-manager-3 docker service ps swarm-m14-reserved --no-trunc
ssh swarm-manager-1 docker inspect $(ssh swarm-manager-1 docker ps -aq --filter label=com.docker.swarm.service.name=swarm-m14-oom)
ssh swarm-manager-1 journalctl -u docker --since today

• Pending — scheduler/reservation
• OOMKilled або 137 — memory investigation
• CPU throttling — latency без kill
• host pressure — OS та сусідні workloads

• Reservation виділяє RAM наперед?
• Що обмежує limit?
• Чому 137 не завжди OOM?
• Що визначає admission?
• Як рахувати N−1?
• Чому limits не є гарантіями?

Модуль засвоєно, якщо ви відтворюєте 3/4 Pending без навантаження, виправляєте budget і безпечно підтверджуєте OOM.

ssh swarm-manager-3 docker service rm swarm-m14-reserved swarm-m14-oom
ssh swarm-manager-3 docker service ls
ssh swarm-manager-3 docker node ls