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