Выбор размера нод

Что ж, выбор зависит от множества факторов, как всегда! Истина где-то посередине и не стоит выбирать ни одну из крайностей.

Вам нужно ответить на вопросы ниже, чтобы найти свой оптимальный размер.

Какой тип приложений вы запускаете?

Вы запускаете микросервисы из множества контейнеров, которые занимают мало места, или несколько монолитов, требующих гигабайты оперативной памяти и целые ядра CPU? Базы данных? Или все вместе?

Можно ли объединить приложения в группы?

Для смешанных окружений, можете ли вы разделить приложения по категориям? Например, если вы запускаете микросервисное приложение, которое работает с БД MySQL, вы разделяете его компоненты на группы приложений и баз данных. Аналогично, если вы запускаете вместе и монолиты и микросервисы, как ELK стек для мониторинга кластера, вы можете разместить его компоненты по разным группам. Для простоты я назвал только три категории, но вы можете создать столько, сколько хотите.

Максимальное количество ресурсов для каждой категории

Если вы можете сгруппировать приложения по категориям, то после этого вам нужно понять сколько максимум ресурсов может потребоваться на одно приложение из каждой категории. Например, если вы запускаете микросервисы, монолиты и БД в кластере, вам нужно взять максимальные затраты на один инстанс БД, микросервис или монолит.

Посчитать количество приложений в каждой категории

Следующий шаг это найти планируемое количество приложений в каждой из категорий. У вас может быть, например, 8 БД MySQL, 200 микросервисов и 9 монолитов. Запишите их. Не перебарщивайте. Kubernetes спроектирован для масштабирования и вы всегда можете использовать автоматическое масштабирование кластера у некоторых провайдеров. Либо, вы можете добавить ноду вручную позже.

Поместите каждую категорию в отдельный пул нод

Лучший способ оптимизировать ноды это создать пул нод под каждую категорию. Большинство Kubernetes кластеров работают с различными пулами нод и разнородные ноды можно подключать к самостоятельно управляемым кластерам.

Заложите отказоустойчивость

Нужно иметь минимум две ноды в каждом пуле для достижения отказоустойчивости. Kubernetes рекомендует максимум 110 контейнеров на ноду. Так же есть ещё системные контейнеры, которые запущены на нодах, так что имейте это ввиду.

Может вам придется согласовать это значение с вашим облачным провайдером, так как они могут предоставлять разного уровня жесткости ограничения на количество подов, запущенных на ноде. Идея в том, чтобы не вылезать за лимит.

Подгоните свои ноды под контейнеры для оптимального управления ресурсами

Если мы ожидаем падение одной ноды за раз, то должны заложить избыток ресурсов на каждой ноде так, чтобы при падении на них могли переехать ресурсы с упавшей ноды.

Подгоните ваши контейнеры и ноды для лучшего возможного управления ресурсами. Например, если у нас есть 20 контейнеров, лучше всего будет распределить по 4 пода на одну ноду, тогда нам нужно иметь в запасе 20% ресурсов на каждой ноде, вместо 100% как если бы у нас было всего 2 ноды.

Как мы пришли к этой цифре? Просто возьмите квадратный корень от количества контейнеров и округлите в меньшую сторону. Это даст вам максимальное количество контейнеров, которое должно быть у вас на ноде.

Учтите нагрузку от самого Kubernetes

Учтите тот факт, что системные компоненты Kubernetes так же будут потреблять какое-то количество CPU и памяти на каждой ноде, поэтому на самом деле вам будет доступно меньше ресурсов, чем есть на ноде. Уточните эти параметры у вашего облачного провайдера и добавьте к ресурсам ноды.

*️⃣2/3: продолжение следует :)

#лонгрид