tocdepth

2

Резервирование ресурсов и планирование размера рабочих узлов

На каждом узле Managed Kubernetes развернуты системные компоненты, которые позволяют узлу работать как часть кластера.

Системные компоненты используют ресурсы узла — процессорные ядра и оперативную память, поэтому можно наблюдать различие между общим объемом ресурсов узла и доступным объемом для рабочих нагрузок. Разница связана с тем, что Managed Kubernetes резервирует заранее определенное количество ресурсов для работы системы и надежности узла.

Посмотреть ресурсы узла, зарезервированные для системных компонентов можно, выполнив команду:

kubectl describe node <название_узла>

В ответе в разделе Capacity отображается общее количество ресурсов на узле, в Allocatable — доступные ресурсы.

Правила резервирования ресурсов

Для каждого узла можно заранее рассчитать количество резервируемых Managed Kubernetes ресурсов и доступных, чтобы запланировать рабочую нагрузку.

Резервирование vCPU

Для системных компонентов Managed Kubernetes резервирует виртуальные CPU для каждого узла по следующим правилам:

  • 6% от первого ядра;

  • 1% от второго ядра;

  • 0.5% от третьего и четвертого ядра;

  • 0.25% от любого последующего количества ядер свыше четырех.

Резервирование RAM

Для системных компонентов Managed Kubernetes резервирует оперативную память для каждого узла по следующим правилам:

  • 255 МиБ для виртуальной машины с оперативной памятью менее 1 ГиБ;

  • 25% от первых 4 ГиБ оперативной памяти;

  • 20% от следующих 4 ГиБ (до 8 ГиБ);

  • 10% от следующих 8 ГиБ (до 16 ГиБ);

  • 6% от следующих 112 ГиБ (до 128 ГиБ);

  • 2% оперативной памяти свыше 128 ГиБ.

Managed Kubernetes также резервирует дополнительные 100 МиБ оперативной памяти на каждом узле, чтобы обработать вытеснение подов (eviction).

Резервирование эфемерного хранилища

Managed Kubernetes резервирует часть хранилища под эфемерное. Эфемерное хранилище необходимо для kubelet во время вытеснения подов (eviction) и для других системных компонентов, работающих на узле. Оставшийся объем хранилища можно использовать, например, для записи логов.

Размер зарезервированного эфемерного хранилища (RES) вычисляется по формуле:

RES = 10% * S + min(50% * S, 6 ГиБ + 35% * S, 100 ГиБ)

Где S — объем хранилища, указанный при создании группы узлов.

Пример расчета

Пользователь планирует создать в кластере группу узлов с пятью рабочими узлами и хранилищем — 20 ГиБ. Конфигурация каждого узла — 8 vCPU и 16 ГиБ RAM.

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

Примечание

В примере для измерения оперативной памяти и объема хранилища используются гибибайты (ГиБ) и мебибайты (МиБ). Однако в личном кабинете используются гигабайты (ГБ). Это означает, что при расчетах для ваших значений могут быть некоторые различия.

Количество vCPU для работы системных компонентов:

Правило

vCPU

Итого

6% от первого ядра

1

0.06 * 1 = 0.06

1% от второго ядра

1

0.01 * 1 = 0.01

0.5% от третьего и четвертого ядра

2

0.005 * 2 = 0.01

0.25% от любого последующего количества ядер свыше четырех

4

0.0025 * 4 = 0.01

Итого:

0.06 + 0.01 + 0.01 + 0.01 = 0.09

Доступные vCPU для рабочих нагрузок:

8 – 0.09 = 7.91

Количество оперативной памяти для работы системных компонентов:

Правило

RAM

Итого

25% от первых 4 ГиБ оперативной памяти

4

0.25 * 4 = 1

20% от следующих 4 ГиБ (до 8 ГиБ)

4

0.2 * 4 = 0.8

10% от следующих 8 ГиБ (до 16 ГиБ)

8

0.1 * 8 = 0.8

Итого:

0.1 + (0.25 * 4) + (0.2 * 4) + (0.1 * 8) = 2.7 ГиБ

Доступная RAM для рабочих нагрузок:

16 – 2.7 = 13.3 ГиБ

Для рабочих нагрузок пользователю доступно 7.91 vCPU и 13.3 ГиБ на каждом узле, если он выберет конфигурацию 8 vCPU и 16 ГиБ RAM.

Эфемерное хранилище:

0.1 * 20 + min(0.5 * 20, 6 + 0.35 * 20, 100) = 2 + min(10, 13, 100) = 2 + 10 = 12 ГиБ

Доступный объем хранилища:

20 – 12 = 8 ГиБ

Рекомендации для планирования

Чтобы обеспечить надежную работу вашего кластера:

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

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

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

    Большое количество маленьких узлов хорошо подходит для высокодоступных рабочих нагрузок, которые не требуют больших ресурсов. Автоматическое масштабирование узлов является более гибким, поскольку для уменьшения масштаба требуется удалить меньшее количество подов.

  • Рассчитайте доступные ресурсы для выбранной конфигурации, используя информацию из предыдущих разделов. Сравните это с ресурсами и накладными расходами, которые вам нужны.

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

    Если выбранная вами конфигурация слишком мала — рассмотрите возможность использования конфигурации большего размера, чтобы снизить риск сбоев в работе.

Запустили Evolution free tier
для Dev & Test
Получить