Оскільки Kubernetes 1.8, здається, мені потрібно відключити своп на своїх вузлах (або встановити --fail-swap-onна false).
Я не можу знайти технічну причину, чому Kubernetes наполягає на тому, щоб своп був відключений. Це з причин ефективності? Причини безпеки? Чому причина цього не документально підтверджена?
Відповіді:
Ідея кубернетів полягає в тому, щоб щільно упакувати екземпляри до максимально 100% використання. Усі розгортання повинні бути закріплені обмеженнями процесора / пам'яті. Отже, якщо планувальник відправляє стручок на машину, він ніколи не повинен використовувати своп. Ви не хочете міняти місцями, оскільки це сповільнить справи.
Це головним чином для продуктивності.
Причина цього, наскільки я розумію, полягає в тому, що кубелет не розроблений для обміну ситуаціями із свопом, а команда Kubernetes не планує цього реалізовувати, оскільки мета полягає в тому, щоб стручки повинні вміщуватися в пам'яті хоста.
Підтримка swap нетривіальна. Гарантовані стручки ніколи не потребують заміни. Бурливі стручки повинні задовольняти їх запити, не вимагаючи заміни. Стручки BestEffort не мають гарантії. Зараз в кубелеті не вистачає розумних можливостей, щоб забезпечити потрібну кількість передбачуваної поведінки тут поперек стручків.
TL; DR неправильно використовує своп - це лише ледачий хак, що демонструє слабке розуміння підсистем пам'яті та відсутність основних навичок адміністрування систем. Проектування інфраструктурних служб та нерозуміння цих систем неминуче закінчиться.
Отже, у мене є якийсь коментар до цього, це здається мені скоріше лінню, ніж характеристикою чи вимогою. Абсолютно можливо правильно обмінятися свопом, проаналізувати пам'ять та визначити, як правильно використовувати підсистему пам'яті, не натискаючи на своп. Навколо цього побудовано багато інструментів, і ви можете гарантувати, що процес не буде використовувати своп досить легко, тому точка продуктивності неправильна. Це просто ліниве кодування, щоб не застосовувати цей прилад, і загалом повне видалення свопів буде на шкоду продуктивності системи. Ключовим тут є його правильне використання. Я погоджуся, що заміна стручків на диски вплине на продуктивність, однак є ряд речей, які слід замінити на диск.
Крім того, ядро Linux призначене для використання своп, і повністю його відключення матиме негативні наслідки. Кращим способом впоратися з цим було б зафіксувати стручки в основній пам'яті і не дозволяти їм переходити на диск, знижувати тиск кешу vfs, щоб він не мінявся, якщо це абсолютно не потрібно, і навіть тоді ви могли б викликати закріплені процеси на вийти з ладу MALLOC у випадку, якщо основна пам'ять вичерпана.
Залежно від процесів у контейнерах, які зазнали важкої несправності контейнера або вбивства його вбивцею OOM, це може призвести до досить катастрофічних результатів. Однак я розумію, що процеси, що протікають у цих контейнерах, в ідеалі повинні бути бездержавними та ефемерними, але за 20 років роботи систем я не один раз бачив, щоб усі дотримувались наміченого дизайну в письмі в 100% часу.
Крім того, це не враховує майбутніх технологій, таких як енергонезалежна пам'ять, і новіші системи пам'яті, такі як intel xpoint, які можна використовувати для істотного розширення основної пам'яті за допомогою гібридних систем диска / пам'яті. За допомогою таких типів систем вони можуть використовувати їх безпосередньо як додаткову основну пам'ять або використовувати файли swap для розширення основної пам'яті з незначним впливом на продуктивність.
Існує квиток, щоб його знову ввімкнути, ви там отримаєте більше розуміння