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