Это перевод статьи Frank Denneman vSphere Supervisor Namespace. Публикуется с разрешения автора.

vSphere 7 с Kubernetes позволяет кластеру vSphere запускать и управлять контейнерами аналогично виртуальным машинам (vSphere Pods). Две предыдущие статьи этой серии посвящены первоначальному размещению vSphere Pod и управлению вычислительными ресурсами отдельных vSphere Pod. В этой статье описывается управления вычислительными ресурсами vSphere Supervisor Namespace. Cormac Hogan рассмотрел особенности подсистемы хранения Supervisor Namespace в своей (отличной) серии блогов.

Supervisor кластер

Supervisor Namespace

Не только vSphere Pod могут использовать ресурсы, предоставляемые Supervisor Namespace. Внутри Namespace могут быть размещены как vSphere Pod, так и виртуальные машины. Как правило, виртуальные машины, размещенные в Namespace, будут работать под управлением Tanzu Kubernetes Grid Cluster (TKG). Тем не менее, вы также можете свободно развертывать любые другие виртуальные машины в Namespace. Namespace позволяют управлять ландшафтами приложений на более высоком уровне абстракции. Если у вас есть приложение, состоящее из виртуальных машин, на которых выполняется традиционные приложения и к ним добавляются новые службы, работающие в контейнерах, вы можете сгруппировать эти сущности в одном пространстве имен. Назначьте соответствующее вычислительные ресурсы и ресурсы хранения этому пространству имен и мониторить приложение целиком. Мы хотим перейти от индивидуального управления сотнями или тысячами виртуальных машин к управлению небольшой группой пространств имен. (т.е. переход на новый уровень управления рабочими нагрузками).

Пространство имен по умолчанию (Default Namespace)

Как видите, эта новая сущность обозначается новой иконкой. Summary страница в правой части экрана показывает состояние, разрешения (еще не настроены), настроенную политику хранения, а также доступный объем и потребление вычислительных ресурсов. В нижней части экрана показано, были ли развернуты Pod или кластеры TKG. В этом примере работают три Pod.

Управление вычислительными ресурсами

Limits

Reservations

Резервирование ресурсов необходимо для защиты рабочих нагрузок от конкуренции за ресурсы. Это можно сделать двумя способами. vAdmin может установить резервирование по умолчанию для каждого контейнера, или запросы ресурсов должны быть указаны в YAML файле. Если vAdmin устанавливает резервирование по умолчанию для каждого контейнера, каждый контейнер, развернутый в этом пространстве имен, будет настроен с этими параметрами. Разработчик может указать Requests или Limits для каждого контейнера отдельно в YAML файле рабочей нагрузки. Основываясь на комбинации заданных Requests и Limits, Kubernetes автоматически назначает класс QoS контейнерам внутри Pod. И на основе классов QoS также происходит высвобождение ресурсов. Существует три класса качества обслуживания (QoS) в Kubernetes, BestEffort, Burstable и Guaranteed.

Классы Burstable и Guaranteed содержат Requests в запросе. В Burstable классе QoS Limits превышает Requests. Класс QoS Guaranteed требует, чтобы для Requests и Limits были установлены в одинаковое значение. Это означает, что относительный приоритет пространства имен определяет, получат ли BestEffort рабочие нагрузки или незащищенная параметром Requests часть Burstable рабочих нагрузок, необходимые ресурсы, во время борьбы за ресурсы. Этот относительный приоритет определяется параметром Shares, назначенным пространству имен.

Shares

Пространства имен используют пулы ресурсов, настроенные на обычный уровень приоритета. Любой объект, развернутый в пространстве имен, также получает обычный приоритет, и его нельзя изменить. Как описано в статье “Scheduling vSphere Pods”, контейнер представляет собой набор процессов и не содержит аппаратной конфигурации. Он просто описывает количество циклов CPU и объем памяти, который он хочет иметь, и то, каким должен быть верхний предел потребления ресурсов. vSphere интерпретирует Requests и Limits и задает размер (CPU и память) vSphere Pod (CRX), и DRS может назначить Shares на основе этой конфигурации. Поскольку в Pod может быть развернуто несколько контейнеров, сумма всех Requests и Limits контейнеров используется для задания виртуального оборудования модуля vSphere Pod.

В BestEffort рабочих нагрузках отсутствуют какие-либо Requests и Limits, поэтому используется размер по умолчанию, равный 1 vCPU и 512 MB. С точки зрения Shares это означает, что vSphere Pod с одним контейнером получит 1000 Shares CPU и 5120 Shares памяти. Burstable класс QoS имеет заданный Requests или заданные Requests и Limits. Если какой-либо параметр больше размера по умолчанию, этот показатель используется для определения размера контейнера (см. изображение ниже). Если Pod манифест содержит несколько контейнеров, добавляется самый большой параметр каждого из контейнеров, и результат используется для выбора размера vSphere Pod. Например, Pod содержит два контейнера, каждый с Requests и Limits, превышающими размер контейнера по умолчанию. CPU Limits превышает CPU Request. В результате vSphere использует сумму обоих CPU Limits и добавляет небольшой Overhead для компонентов, отвечающих за жизненный цикл Pod, конфигурацию Pod и взаимодействие с vSpherelet. Аналогичный расчет делается и для памяти.

Relative Priority During Sibling Rivalry

В пуле ресурсов “Namespaces” присутствует несколько объектов. Два пространства имен и три Control plane виртуальные машины. Резервирование не защищает ни один из объектов, и, таким образом, каждый объект должен бороться со своей Shares, если он хочет получить часть из 126,14 GB. Каждая Control plane виртуальная машина сконфигурирована с 24 GB, 245 760 Shares соответственно. Оба пула ресурсов имеют 163 840 Shares процессора. Всего в ресурсном пуле “Namespaces” 1 064 960 Shares, как показано в пользовательском интерфейсе, каждая Control plane виртуальная машина владеет 23,08% от общего количества Shares, тогда как оба пула ресурсов владеют 15,38%. В худшем случае это означает, что пул ресурсов “Namespaces” разделит 126,14 GB между пятью объектами (Siblings). Каждая Control plane виртуальная машина имеет право использовать 23,08% из 126,14 GB = 29,11 GB. Так как она не может использовать больше, чем ее сконфигурированное виртуальное оборудование, она сможет использовать максимум 24 GB (и свой Overhead). Оставшиеся 5 GB будут возвращены обратно в пул ресурсов и будут распределены среди объектов, которым это требуется. В этом случае все три Control plane виртуальные машины потребляют 72 GB (3 x 24 GB), а 54,14 GB будут распределены между пространством имен «frank-ns» и пространством имен «vmware-system-reg…» (Harbor).

Требования к ресурсам объектов в каждом пространстве имен могут быстро превысить относительный приоритет пространства имен среди его дочерних элементов (Siblings). Подразумевается, что будет развернуто еще больше пространств имен, что еще больше ослабит относительный приоритет среди нижележащих дочерних элементов. Такое поведение показано на следующем скриншоте. Cormac развертывает новые рабочие нагрузки. Он создал пространство имен для своих собственных vSphere Pod и развернул кластер TKG и кластер Cassandra. Все развернуто в собственном пространстве имен.

Как видите, мое пространство имен “frank-ns” потеряло свой приоритет. Shares была снижена с 15,38% до 10,53%. Я могу ожидать, что мои BestEffort и Burstable deployment не получат столько же ресурсов, сколько они могли бы получить раньше, если возникнет нехватка ресурсов. То же относится и Control plane виртуальным машинам. Теперь они имеют право на 15,79% от общего объема памяти. Это означает, что Control plane виртуальная машина может получить 19,92 GB (15,79% из 126,14 GB).

Проектное решение

Зарезервированные ресурсы

Интересно отметить, что в ситуации когда несколько Burstable рабочих нагрузок разворачиваются внутри пространства имен. Used Reservation ресурсного пула “Namespaces” показывает, что зарезервировано 36,75 GB. Тем не менее, глядя на таблицу видно, что ни одно из пространств имен или виртуальных машин не показывает резервацию ресурсов. Это связано с тем, что в этом столбце отображается резервирование, настроенное непосредственно для самого объекта. И никакой пул ресурсов, созданный для пространства имен, не будет настроен с резервированием. Обратите внимание, что он не будет суммировать резервирование vSphere Pod или виртуальных машин, которые выполняются внутри пула ресурсов!

В Summary пространства имен отображается емкость и использование ресурсов пространства имен. В этом примере показана сводная страница “Cormac-ns”. Видно, что это пространство имен “потребляет” 3,3 GHz и 4,46 GB.

Эти цифры являются сочетанием Reservation (Requests) и фактического использования. Это можно увидеть, рассматривая каждый отдельный контейнер. Summary “cassandra-0” Pod показывает, что выделен 1 CPU и 1 GB, модуль потребляет некоторое количество памяти и циклов CPU.

Метаданные модуля показывают, что этот модуль имеет Guaranteed класс QoS. При просмотре файла YAML мы видим, что Requests и Limits ресурсов CPU и памяти идентичны. Настройки ресурсов процессора показывают 500m, m обозначает millicpu. 1000 millicpu равны 1 vCPU, в этом YAML файле говорится, что этому контейнеру достаточно и половины ядра. Однако vSphere не может выделить половину ядра. Планировщик vSphere может управлять потреблением в GHz, но этот параметр используется для определения конфигурации CRX (vSphere Pod). Поэтому vSphere Pod сконфигурирован с минимальным количеством 1 vCPU, и это указано на странице Capacity and Usage.

Scalable Shares

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

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