vSphere Supervisor Namespace

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

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

Supervisor кластер

Кластер vSphere превращается в Supervisor кластер после включения Kubernetes. Три Control plane виртуальные машины будут развернуты и размещены в кластере vSphere, а ESXi хосты в кластере будут выступают в качестве Worker node (поставщика ресурсов) для кластера Kubernetes. vSpherelet запускается на каждом ESXi хосте для управления и связи с vSphere Pod. Дополнительная информация о среде исполнения контейнеров для ESXi доступна в статье “Первоначальное размещение vSphere Pod”.

Supervisor Namespace

После запуска Supervisor кластер представляет собой единый пул вычислительных ресурсов. Скорее всего, вы захотите разделить кластер на более мелкие пулы ресурсов. Использование пространства имен (Namespace) превращает Supervisor кластер в многопользовательскую платформу. Для настоящей многопользовательской среды требуется модель безопасности. Пространства имен позволяют vAdmin контролировать, какие именно пользователи (разработчики) имеют доступ к этому пространству имен. Политики хранения, связанные с пространством имен, предоставляют различные типы и классы для (persistent) хранения для рабочих нагрузок.

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

Image for post
Image for post

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

Вычислительные ресурсы предоставляются пространству имен vSphere DRS с помощью пулов ресурсов (Resource Pool). Этот пул ресурсов не предоставляется напрямую, vAdmin взаимодействует с пулом ресурсов через пользовательский интерфейс пространства имен. На скриншоте ниже вы можете увидеть Workload Domain Cluster (WLD) с включенным vSphere с Kubernetes. Внутри Supervisor кластер автоматически создается пул ресурсов “Namespaces”, и три Control Plane виртуальные машины Supervisor кластера развертываются непосредственно в Namespaces пуле ресурсов. (Я рассмотрю это позже). Мы с Cormac создали пару пространств имен, и пространство имен «frank-ns» сейчас выделено на скриншоте.

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

Image for post
Image for post

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

С помощью традиционного пула ресурсов vAdmin может устанавливать Reservation, Shares и Limits для CPU и памяти, чтобы гарантировать и ограничивать потребление вычислительных ресурсов. Supervisor Namespace не предоставляет такие настройки. Namespace позволяет vAdmin устанавливать Limits и Requests (Reservation) для каждого контейнера.

Image for post
Image for post

Limits

vAdmin может установить Limits на ресурсы CPU или памяти для всего пространства имен. Таким образом, разработчик может развернуть рабочие нагрузки в пространстве имен, не рискуя использовать все вычислительные ресурсы Supervisor кластера. Помимо Limits пула ресурсов, vAdmin также может установить ограничения по умолчанию для каждого контейнера. Namespaces автоматически применит эти ограничения для каждой рабочей нагрузки, независимо от запроса ресурсов, указанной в YAML файле контейнерной рабочей нагрузки. Кроме того, vAdmin также может указывать ограничения для объектов. Для пространства имен можно указать максимальное количество Pod, что в конечном итоге ограничивает общее количество потребляемых ресурсов всеми сущностями, развернутыми в пространстве имен.

Image for post
Image for post

Reservations

Supervisor Namespace не предоставляет возможность установить резервирование на уровне пространства имен. Однако пул ресурсов настроен с расширяемым резервированием, что позволяет пулу ресурсов запрашивать незарезервированные ресурсы у его родителя. Эти незарезервированные ресурсы необходимы для удовлетворения запроса на резервируемые ресурсы для рабочих нагрузок. Пул ресурсов “Namespaces” — это родительский пул ресурсов, в котором развернуты все пространства имен. Пул ресурсов “Namespaces” настроен с незарезервированными ресурсами, и в результате он будет запрашивать ресурсы у своего родительского объекта, который является корневым пулом ресурсов — кластером.

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

Image for post
Image for post

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

Shares

DRS назначает Shares для объектов в кластере, чтобы определить относительный приоритет при борьбе за ресурсы. Чем больше Shares, тем выше приоритет получения запрошенных ресурсов. Это невероятно динамичный (и элегантный) метод удовлетворения потребностей активных объектов. Виртуальная машина или пул ресурсов могут иметь заданные Shares, но если этот объект не испытывает проблем с получением ресурсов, то Shares не участвуют в игре. Как правило, для определения Shares, назначаемым объектам, мы рассматриваем наихудший сценарий. В таком упражнении мы рассчитываем Shares, считая что каждый объект активен на 100% — идеальный шторм. DRS назначает каждому объекту Shares. DRS присуждает Shares на основе настроенных ресурсов объекта. Количество vCPU и объем памяти умножается на Shares. Уровень приоритета (Low, Normal, High) объекта определяет коэффициент Shares. Уровни приоритета имеют соотношение 1:2:4. Обычным приоритетом является приоритет по умолчанию, и каждому vCPU присуждается 1000 CPU Shares. На каждый MB памяти выделяется 10 Shares. Например, виртуальная машина с конфигурацией 2 vCPU, которой назначен нормальный уровень приоритета, получает 2000 Shares (2 vCPU x 1000). Если виртуальная машина настроена с высоким уровнем приоритета, она получит 4000 Shares (2 vCPU x 2000). Хотя пул ресурсов не может выполнять рабочую нагрузку сам по себе, DRS должен назначить Shares для этой сущности, чтобы определить относительный приоритет. Рассмотрим внутреннее представление DRS для пула ресурсов с виртуальной машиной 4 vCPU, 16GB. В результате пул ресурсов с обычным приоритетом, независимо от количества содержащихся в нем объектов, получит 4000 Shares CPU и 163840 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. Аналогичный расчет делается и для памяти.

Image for post
Image for post

Relative Priority During Sibling Rivalry

Почему размеры vSphere Pod так интересны? DRS в vSphere 7 оснащена новой функцией, называемой Scalable shares, и использует конфигурации CPU и памяти дочерних объектов для правильной трансляции относительного приоритета пулов ресурсов относительно его дочерних элементов. Пул ресурсов является родителем объектов, развернутых внутри. Это означает, что во время конфликта ресурсов пул ресурсов будет запрашивать ресурсы у своего родителя, пула ресурсов “Namespaces”, а он, в свою очередь, будет запрашивать ресурсы у своего родителя — корневого пула ресурсов (Supervisor Cluster). На каждом уровне существуют другие объекты, делающие то же самое во время идеального шторма. Это означает, что нам приходится иметь дело с соперничеством дочерних объектов (Siblings).

Image for post
Image for post

В пуле ресурсов “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).

Image for post
Image for post

Требования к ресурсам объектов в каждом пространстве имен могут быстро превысить относительный приоритет пространства имен среди его дочерних элементов (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).

Image for post
Image for post

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

Я хотел бы рассмотреть возможность применения резервирования для Control plane виртуальных машин или создания пула ресурсов и установки резервирования на его уровне. Если резервирование будет установлено на уровне объекта виртуальной машины, это будет влиять на Admission Control и операции перезапуска HA (достаточно ли незарезервированных ресурсов, оставшихся после одного или нескольких сбоев хостов в кластере?).

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

Доступный объем незарезервированных ресурсов в пуле ресурсов “Namespaces” уменьшается, когда в одном из пространств имен развернута Guaranteed или Burstable рабочая нагрузка. Пулы ресурсов, созданные для пространства имен, настроены как “Expandable” и поэтому запрашивают эти ресурсы у своего родителя. Если родительский ресурс имеет эти доступные ресурсы, он предоставит их дочерним объектам и немедленно пометит их как зарезервированные. Пространство имен будет владеть этими ресурсами, пока пространство имен существует. Как только Guaranteed или Burstable рабочая нагрузка будет уничтожена, зарезервированные ресурсы возвращаются к родительскому объекту. Зарезервированные ресурсы, когда они используются, не могут быть распределены другими рабочими нагрузками на основе их Shares.

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

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

Image for post
Image for post

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

Image for post
Image for post

Метаданные модуля показывают, что этот модуль имеет 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.

Image for post
Image for post

Scalable Shares

Причина, по которой это интересно, заключается в том, что Scalable Shares могут вычислять новое значение Shares на основе количества vCPU, общей конфигурации памяти всех объектов в пуле ресурсов. Как эта новая функциональность ведет себя в такой сложной структуре пулов ресурсов — тема следующей статьи.

Written by

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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store