Начиная с Kubernetes 1.8, кажется, мне нужно отключить свопинг на моих узлах (или установить --fail-swap-on к false).
Я не могу найти техническую причину, по которой Kubernetes настаивает на отключении свопа. Это из соображений производительности? Причины безопасности? Почему причина этого не задокументирована?
Идея кубернетов состоит в том, чтобы плотно упаковать экземпляры, чтобы максимально использовать их на 100%. Все развертывания должны быть связаны с ограничениями ЦП / памяти. Поэтому, если планировщик отправляет модуль на машину, он никогда не должен использовать подкачку. Вы не хотите менять местами, так как это замедлит работу.
Это в основном для производительности.
TL; DR неправильное использование свопа - это просто ленивый прием, демонстрирующий плохое понимание подсистем памяти и отсутствие фундаментальных навыков системного администрирования. Разработка инфраструктурных сервисов и непонимание этих систем обречены на провал.
Итак, у меня есть некоторые комментарии по этому поводу, для меня это больше похоже на лень, чем на функцию или требование. Совершенно возможно правильно обработать своп, проанализировать память и определить, как правильно использовать подсистему памяти, не затрагивая своп. Существует множество инструментов, построенных вокруг этого, и вы можете гарантировать, что процесс не будет использовать своп достаточно легко, поэтому точка производительности неверна. Это просто ленивое кодирование, чтобы не вставлять эти инструменты, и в целом полное удаление свопа будет в ущерб производительности системы. Ключ здесь в правильном использовании. Я согласен с тем, что замена модулей на диски повлияет на производительность, однако есть ряд вещей, которые должен быть выгруженным на диск.
Кроме того, ядро Linux предназначено для использования подкачки, и полное ее отключение приведет к негативным последствиям. Лучшим способом справиться с этим было бы закрепление модулей в основной памяти и не позволять им переключаться на диск, уменьшить давление кеш-памяти vfs, чтобы он не менялся, если это не является абсолютно необходимым, и даже тогда вы можете вызвать закрепленные процессы в выход из строя MALLOC в случае исчерпания основной памяти.
В зависимости от процессов в контейнерах, наличие жесткого отказа контейнера или его уничтожение убийцей OOM может привести к довольно плачевным результатам. Однако я понимаю, что в идеале процессы, выполняемые в этих контейнерах, должны быть эфемерными и не иметь состояния, но за 20 лет работы систем я ни разу не видел, чтобы все следовали намеченному дизайну в 100% случаев.
Кроме того, это не учитывает будущие технологии, такие как энергонезависимая память, и новые системы памяти, такие как Intel xpoint, которые можно использовать для значительного расширения основной памяти с помощью гибридных систем диск / память. В системах такого типа они могут использовать их непосредственно в качестве дополнительной основной памяти или использовать файлы подкачки для расширения основной памяти с незначительным влиянием на производительность.
Причина этого, насколько я понимаю, в том, что kubelet не предназначен для обработки ситуаций подкачки, и команда Kubernetes не планирует реализовывать это, поскольку цель состоит в том, чтобы поды помещались в памяти хоста.
из Эта проблема
Поддержка свопа нетривиальна. Гарантированные стручки никогда не должны требовать замены. Запросы пакетных модулей должны удовлетворяться без необходимости подкачки. На капсулы BestEffort не распространяется гарантия. Кубелету сейчас не хватает сообразительности, чтобы обеспечить нужное предсказуемое поведение в разных модулях.
Есть билет, чтобы включить его снова, вы получите больше информации там