Вопрос или проблема
Начиная с Kubernetes 1.8, похоже, мне нужно отключить своп на моих узлах (или установить --fail-swap-on в false).
Я не могу найти техническую причину, почему Kubernetes настаивает на отключении свопа. Это по причинам производительности? Из соображений безопасности? Почему эта причина не документирована?
Идея Kubernetes заключается в том, чтобы плотно упаковывать экземпляры так, чтобы загрузка была как можно ближе к 100%. Все развертывания должны иметь ограничения по ЦПУ и памяти. Поэтому если планировщик отправляет под на машину, он не должен использовать своп вообще. Вам не нужен своп, так как это замедляет процесс.
Это в основном связано с производительностью.
Кратко: неправильное использование свопа — это просто ленивый хак, который демонстрирует плохое понимание подсистем памяти и отсутствие основных навыков администрирования систем. Проектирование инфраструктурных сервисов и непонимание этих систем неизбежно приведет к неудаче.
Итак, у меня есть некоторые комментарии по этому поводу, это больше напоминает леность, чем функцию или требование. Абсолютно возможно правильно обрабатывать своп, анализировать память и определять, как правильно использовать подсистему памяти без обращения к свопу. Существует множество инструментов, разработанных для этого, и вы можете гарантировать, что процесс не будет использовать своп, довольно легко, так что вопрос производительности неверен. Это просто ленивое кодирование не включения этой инструментировки, и в целом полное отключение свопа будет во вред производительности системы. Ключевое здесь – правильное использование. Я согласен, что перемещение подов на диски повлияет на производительность, однако есть ряд вещей, которые должны быть вынесены на диск.
Кроме того, ядро linux разработано для использования свопа, и полное его отключение приведет к негативным последствиям. Лучший способ справиться с этим – зафиксировать поды в основной памяти и не позволять им обращаться к диску, уменьшить давление на кэш vfs так, чтобы он не использовал своп, если это абсолютно не обязательно, и даже тогда вы можете вызвать сбой процессов с фиксированной памятью из-за недостатка памяти при исчерпании основной памяти.
В зависимости от процессов в контейнерах жесткий сбой контейнера или его завершение OOM-убийцей может привести к довольно катастрофическим последствиям. Я понимаю, что процессы, запущенные в этих контейнерах, должны быть в идеале безсостояниями и эфемерными, но за 20 лет работы с системами я ни разу не видел, чтобы все строго следовали проектированию.
Более того, это не учитывает будущие технологии, такие как энергонезависимая память, и новые системы памяти, такие как Intel XPoint, которые могут использоваться для значительного расширения основной памяти с помощью гибридных дисковых/памятных систем. С такими системами их можно использовать непосредственно в качестве дополнительной основной памяти или использовать своп-файлы для расширения основной памяти с незначительным влиянием на производительность.
Причина этого, насколько я понимаю, заключается в том, что kubelet не предназначен для обработки ситуаций со свопом, и команда Kubernetes не планирует реализовывать это, так как цель состоит в том, чтобы поды укладывались в память хоста.
из этой проблемы GitHub #53533
Поддержка свопа не тривиальна. Гарантированные поды никогда не должны требовать свопа. Поды с бурстом должны получать свои запросы без необходимости в свопе. Поды BestEffort не имеют гарантии. В данный момент kubelet не обладает умением предоставить необходимое количество предсказуемого поведения здесь для подов.
Существует тикет для включения этой функции, вы сможете получить больше информации там
Теперь в версии v1.28 есть бета-поддержка
Ответ или решение
Почему необходимо отключить своп в Kubernetes
С момента выхода Kubernetes версии 1.8 разработчики акцентируют внимание на необходимости отключения свопа на узлах, обслуживающих кластеры. Этот аспект часто вызывает вопросы, относящиеся к его целесообразности и техническим причинам. В данной статье мы рассмотрим основные причины отключения свопа в Kubernetes, а также коснемся аспектов производительности и проектирования.
1. Производительность
Основная причина, по которой Kubernetes требует отключения свопа, связана с производительностью. Kubernetes разрабатывался для эффективной работы с контейнерами, и его архитектура предполагает, что все контейнеры должны быть оптимально размещены в памяти узлов. Когда своп включен, данные могут перемещаться на дисковые устройства, что значительно замедляет доступ к памяти. Это может приводить к искажению предсказуемости работы приложений и повышению времени ответа, что недопустимо в средах с высокими требованиями к производительности, например, в производственной среде.
2. Управление ресурсами
Kubernetes требует четкого управления ресурсами для контейнеров, что включает в себя задание лимитов на использование CPU и памяти. Если своп включен, Kubernetes не сможет гарантировать, что контейнеры будут получать необходимое количество ресурсов, так как системы могут начать использовать своп, что разрушает концепцию надежного управления ресурсами.
При наличии свопа, если память узла будет исчерпана, системы начнут перемещать менее критичные данные на диск, что в конечном итоге повлияет на работу более важных приложений и приведет к непредсказуемым сбоям или замедлениям.
3. Ограничения kubelet
По состоянию на предыдущие версии Kubernetes, kubelet, который отвечает за работу с контейнерами, не был спроектирован для управления сценариями с использованием свопа. Это создает дополнительные сложности в обеспечении предсказуемости работы подов. С точки зрения архитектуры, Kubernetes предполагает, что поды должны полностью помещаться в оперативную память хоста.
Как было упомянуто в обсуждении на GitHub: поддержка свопа требует значительных усилий и сложной логики, что могло бы потребовать переработки существующих механизмов управления ресурсами в Kubernetes.
4. Проблемы с надежностью
Использование свопа может привести к неконтролируемым перегрузкам памяти, особенно в условиях критической нагрузки. Это может вызвать вызов OOM-киллера (Out of Memory Killer), который будет завершать процессы для освобождения памяти, что неприемлемо для систем, работающих в реалиях высоких требований к надежности. В продуктивных системах такие ситуации могут привести к серьезным сбоям и потере данных.
Заключение
Таким образом, отключение свопа в Kubernetes — это не просто рекомендация, а требование, основанное на принципах производительности, управления ресурсами и надежности системы. Хотя в некоторых современных версиях Kubernetes началось тестирование поддержки свопа, основная философия системы остается неизменной — обеспечить максимально эффективную и предсказуемую работу контейнеров. В конечном итоге, правильное управление памятью играет ключевую роль в успешном развертывании и эксплуатации приложений в среде Kubernetes, и понимание этих механизмов критически важно для успешной работы IT-инфраструктуры.