Нашел для себя интересный момент в работе Kubernetes: по умолчанию kubeadm откажется поднимать кластер, если включен swap и потребует его отключения перед тем как продолжить.

Эта штука может понадобиться, когда наш под потребляет больше оперативной памяти, чем ожидали. Представим, что у нас настроен региональный кластер с тремя зонами, в котором есть под, потребляющий на пиках более 30 гб. Без swap нужны ноды на более 40 гб в каждой из трёх зон. С тремя продакшен кластерами и десятью тестовыми это уже 25+ нод и расходы на инфраструктуру улетают в космос. Без swap kubelet убьет под с OOMKilled, а с ним он сможет какое-то время прожить. Этот механизм может ещё пригодится в edge-node, где без swap ворклоады вообще не запустятся. Но есть нюанс: перекладывание данных на диск это I/O операция и из-за этого кластер может тормозить.

Но есть пару технических нюансов:
— Если swap включен, то при нехватке памяти под будет записан на диск, а это вызовет деградацию перформанса всей VM или сервера, особенно, при rolling update.
— Если swap отключен, kubelet не поднимет под и в его описании напишет — Insufficient memory. Дальше ответственность за правильный scheduling подод ложится на инженеров через механизмы распределения нагрузки. А с v1.22 в k8s появилась поддержка swap в альфа-режиме, а с v1.28 — в бета. То есть теперь kubelet может быть запущен на ноде с включенным swap, если указать это в конфиге.

Опять же технические нюансы:
— swap доступен только Pod с Burstable QoS
— Guaranteed, BestEffort и высокоприоритетные Pods использовать его не могут
— объём swap рассчитывается автоматически, пропорционально memoryRequest
По сути swap как бы включён, но использовать его может только часть ворклоадов — и то не в полном объёме.

В итоге всё сводится к вопросу trade-off: swap иногда может спасти с сэкономить ресурсы, но может тормозить и снижать изоляцию подов, особенно если неправильно приготовить

На почитать:
— Swap Linux Improvements
— Swap memory management
— Performing a Rolling Update