Несколько крупных узлов или много мелких?
Фото Ла-Реля Пасхи на Unsplash Управление кластером Kubernetes — это не та задача, где есть одно правильное решение на все случаи жизни.
Способов оптимизации кластера множество, и главное здесь — обеспечить стабильную и отказоустойчивую работу приложений.
Как инженеры по надежности сайтов и DevOps, вы должны учитывать потребности приложений, которые будут работать в кластере, и учитывать различные факторы при его проектировании.
Выбор правильного размера узла имеет решающее значение для разработки масштабируемых приложений.
Иметь много мелких узлов или несколько крупных — это две крайности.
Для кластера, которому требуется всего 24 ГБ памяти и 12 процессоров, лучше ли выбрать 12 машин по 1 процессору/2 ГБ или две по 6 процессоров/12 ГБ? Здравый смысл подсказывает нам, что ответ лежит где-то посередине, но давайте посмотрим на факторы, которые могут повлиять на наше решение.
Прежде чем сделать выбор, давайте рассмотрим особенности обеих крайностей.
Отказоустойчивость
Кубернетес предоставляет возможность реализовать отказоустойчивость приложений «из коробки» при наличии как минимум 2 рабочих узлов.Однако, когда речь идет о выборе между несколькими крупными узлами и множеством мелких, нужно понимать, что нас ждет. Если у нас есть две большие рабочие ноды и одна из них выйдет из строя, то мы потеряем половину всех ресурсов кластера.
Если не обеспечить 100% резерв ресурсов, это приведет к катастрофе, так как оставшийся узел не сможет выдержать двойную нагрузку.
Наличие большого количества работников снижает эти риски на n. Например, если у вас в кластере 10 узлов и один отключится, то вы потеряете только 10% всей мощности кластера.
Победители: множество мелких узлов
Сложность управления
При наличии большего количества узлов вам придется заботиться о большем количестве серверов, обновлять и обслуживать их.Уменьшив количество узлов, их легче обслуживать.
В качестве DevOps и SRE вы можете использовать такие инструменты, как Анзибль или Кукольный упростить эти процессы за счет автоматизации.
Если вы используете управляемый кластер Kubernetes, ваш облачный провайдер будет исправлять и обновлять узлы за вас.
В результате при современных инструментах этот момент не дает существенного преимущества.
Победители: нет
Легко распределять контейнеры
Kubernetes оценивает множество параметров при выделении контейнеров.Некоторые из них — количество доступных ресурсов на узле, запросы ресурсов и ограничения для контейнеров.
Имея больше ресурсов на каждом узле Kubernetes, легче найти узлы для перемещения модулей, чем если бы у вас было много небольших узлов.
Победители: несколько крупных узлов
Автоматическое горизонтальное масштабирование узлов
Многие облачные провайдеры обеспечивают автоматическое горизонтальное масштабирование рабочих процессов Kubernetes. Если у вас большие узлы, то масштабировать их может быть неудобно.Например, если вы добавите третий узел в кластер из двух узлов, вы увеличите емкость кластера на целых 33%, а для кластера из 10 узлов добавление одного узла увеличит доступные ресурсы на 9%.
Победители: множество мелких узлов
Простота обслуживания
Узлы кластера Kubernetes не могут работать непрерывно, и их необходимо останавливать для обновлений ОС, обновлений версий Kubernetes и другого обслуживания.Если у вас несколько рабочих узлов, их сложнее обновить без остановки приложений; также, если один узел будет отключен, нагрузка на другие значительно увеличится и это тоже может привести к простою.
Чего не обязательно произойдет, если у вас много узлов: вы можете обновлять один узел за раз, и Kubernetes легко перенесет ваши приложения на другие свободные узлы.
Победители: множество мелких узлов
Загрузка на кубелет
Kubelet отвечает за взаимодействие с базовой средой выполнения контейнера (движком контейнера) для запуска приложений на рабочих узлах.Если вы запускаете много контейнеров на одном узле, что типично для кластеров с большими узлами, это может перегрузить кубелет, поскольку ему придется обрабатывать больше контейнеров.
Kubelet оптимизирован для управления только определенным ограниченным количеством контейнеров, а многие облачные провайдеры ограничивают количество контейнеров, которые можно запустить на одном рабочем узле.
Поэтому наличие нескольких крупных узлов не всегда является правильным решением, если вы планируете запускать множество небольших контейнеров.
Победители: множество мелких узлов
Загрузка системы
И наоборот, многие узлы нагружают ваши главные узлы, поскольку им необходимо взаимодействовать со многими рабочими узлами.Kubernetes не оптимизирован для работы с более чем 500 узлами в кластере (хотя пишут, что могут управлять до 5000 узлами).
Поэтому нужно быть осторожным при добавлении новых узлов в кластер и оптимизировать их размер в зависимости от их количества.
В большинстве случаев такое большое количество узлов не требуется, но их часто можно встретить в сборках для высокопроизводительных приложений.
Победители: несколько крупных узлов
Выбор размера узла
Ну а выбор, как всегда, зависит от многих факторов! Истина где-то посередине, и не стоит выбирать ни одну крайность.Вот несколько правил, которым я следую, и они мне очень помогают. Вам необходимо ответить на вопросы ниже, чтобы найти свой лучший размер.
Какие типы приложений вы используете?
Вы запускаете микросервисы из нескольких контейнеров, которые занимают мало места, или из нескольких монолитов, которым требуются гигабайты оперативной памяти и целые ядра ЦП? База данных? Или все вместе?Можно ли группировать приложения?
Можете ли вы разделить приложения по категориям в смешанных средах? Например, если вы запускаете микросервисное приложение, работающее с базой данных MySQL, вы разделяете его компоненты на группы приложений и баз данных.Аналогично, если вы запускаете одновременно монолиты и микросервисы, например стек ELK для мониторинга кластера, вы можете разместить его компоненты в разных группах.
Для простоты я назвал только три категории, но вы можете создать столько, сколько захотите.
Максимальное количество ресурсов для каждой категории
Если вы можете группировать приложения по категориям, то после этого вам нужно понять, сколько максимально ресурсов может потребоваться для одного приложения из каждой категории.
Например, если вы используете микросервисы, монолиты и базы данных в кластере, вам необходимо принять максимальную стоимость за экземпляр БД, микросервис или монолит.
Подсчитайте количество заявок в каждой категории
Следующий шаг — найти запланированное количество заявок в каждой категории.Например, у вас может быть 8 баз данных MySQL, 200 микросервисов и 9 монолитов.
Запишите их.
Не переусердствуйте.
Kubernetes предназначен для масштабирования, и вы всегда можете использовать автоматическое масштабирование кластера у некоторых поставщиков.
Или вы можете добавить узел вручную позже.
Поместите каждую категорию в отдельный пул узлов.
Лучший способ оптимизировать узлы — создать пул узлов для каждой категории.
Большинство кластеров Kubernetes работают с разными пулами узлов, а гетерогенные узлы можно подключать к самоуправляемым кластерам.
Повышайте отказоустойчивость
Для обеспечения отказоустойчивости в каждом пуле необходимо иметь как минимум два узла.Kubernetes рекомендует использовать максимум 110 контейнеров на узел.
Существуют также системные контейнеры, которые работают на узлах, так что имейте это в виду.
Возможно, вам придется согласовать это значение с вашим поставщиком облачных услуг, поскольку они могут предоставлять различные уровни ограничения количества модулей, работающих на узле.
Идея состоит в том, чтобы не выходить за рамки.
Сопоставьте свои узлы с контейнерами для оптимального управления ресурсами.
Если мы ожидаем падения одного узла за раз, то мы должны выделить лишние ресурсы каждому узлу, чтобы при его падении ресурсы из упавшего узла могли перейти на них.
Настройте свои контейнеры и узлы для наилучшего управления ресурсами.
Например, если у нас 20 контейнеров, лучше всего было бы распределить по 4 пода на каждый узел, тогда нам нужно иметь 20% ресурсов, доступных на каждом узле, а не 100%, как если бы у нас было только 2 узла.
Как я пришел к этой цифре? Просто извлеките квадратный корень из количества контейнеров и округлите в меньшую сторону.
Это даст вам максимальное количество контейнеров, которое должно быть на вашем узле.
Учитывайте нагрузку от самого Kubernetes
Учтите тот факт, что системные компоненты Kubernetes также будут потреблять некоторое количество процессора и памяти на каждом узле, поэтому в действительности вам будет доступно меньше ресурсов, чем доступно на узле.Проверьте эти параметры у своего облачного провайдера и добавьте узлы к своим ресурсам.
Подведение итогов
Учитывая все вышеперечисленное, для поиска оптимальных значений необходимо сделать следующее: Количество контейнеров на узел = квадратный корень из количества контейнеров, округленный до ближайшего целого числа, при условии, что количество контейнеров на узел не превышает рекомендуемое значение.
Количество узлов = Количество контейнеров/Количество контейнеров на узел Резерв ресурсов = Количество контейнеров на узел * Максимальное количество ресурсов на контейнер/(Количество узлов — Максимально допустимое количество отключенных узлов) Ресурсы узла = максимальное количество ресурсов, необходимое контейнеру * количество контейнеров на узле + резерв ресурсов + требования к ресурсам компонентов системы Kubernetes.
Пример
Чтобы понять, как это работает, давайте рассмотрим пример.Допустим, нам нужны два пула узлов:
- Микросервисы — на каждый контейнер требуется 200 микросервисов с процессором 0,1 и 100 МБ ОЗУ.
- Базы данных — на каждый контейнер требуется 20 баз данных PostgreSQL с 2 ЦП и 4 ГБ ОЗУ.
Для пула микросервисов: Ближайшее наименьшее целое число в квадрате = 196. Количество контейнеров на узел = sqrt(196) = 14 Количество узлов = 200/14 = 14,28 ~ 15 Максимально допустимое количество простаивающих узлов = 1. Запас ресурсов = 14 * (0,1 ядра + 100 МБ ОЗУ)/(15–1) = 0,1 ядра + 100 МБ ОЗУ Ресурсы узла = (0,1 ядра + 100 МБ ОЗУ) * 14 + 0,1 ядра + 100 МБ ОЗУ + 0,5 ядра + 500 МБ ОЗУ = 2 ядра + 2 ГБ ОЗУ Для пула базы данных: Ближайшее наименьшее целое число в квадрате = 16. Количество контейнеров на узел = sqrt(16) = 4 Количество узлов = 20/4 = 5 Максимально допустимое количество простаивающих узлов = 1. Запас ресурсов = 4 * (2 ядра + 4 ГБ ОЗУ)/(5–1) = 2 ядра + 4 ГБ ОЗУ Ресурсы узла = (два ядра + 4 ГБ ОЗУ) * 4 + 2 ядра + 4 ГБ ОЗУ + 0,5 ядра + 0,5 ГБ ОЗУ = 10,5 ядра + 20,5 ГБ ОЗУ Таким образом, для пула микросервисов вам понадобится 15 рабочих узлов с 2 ядрами и 2 ГБ ОЗУ каждый, а для пула базы данных — 5 рабочих узлов с 10,5 ядрами и 20,5 ГБ ОЗУ каждый.
Для простоты вы можете округлить числа до ближайшей доступной большей конфигурации машины.
Заключение
Проектирование кластера Kubernetes — это скорее искусство, чем точная наука.Хотя приведенные выше правила весьма полезны, они остаются рекомендациями, и лучший способ изучить их — спроектировать свой кластер и оптимизировать его по мере того, как вы узнаете больше.
Теги: #ИТ-инфраструктура #Администрирование серверов #Kubernetes #DevOps #sre #архитектура #контейнеры #ресурсы
-
Лазерные Принтеры Играют В Детектив
19 Oct, 24 -
Yolov5 Для Распознавания Марок Автомобилей
19 Oct, 24 -
Винил: Новое – Это Хорошо Забытое Старое
19 Oct, 24 -
Как Я Поймал Хакера
19 Oct, 24 -
Мобильный Безлимит От Мегафон
19 Oct, 24 -
Как Пропал Ноутбук Ашманова И Другие Курьезы
19 Oct, 24
