Размещение модуля
В Kubernetes новые и нераспределенные модули автоматически распределяются по узлам, которые соответствуют их требованиям. Когда в вашем кластере есть разные типы узлов, может быть важно осуществлять контроль над узлами, на которых распределяются модули. Существует четыре инструмента, которые можно использовать для управления размещением модуля:
Надписи узлов применяются к узлу для указания информации о нем. Надпись может быть ключом или парой ключ/значение.
Привязка узлов применяется к модулю, чтобы ограничить запуск этого модуля на узлах с указанной надписью.
Taints (ограничения) применяются к узлу, чтобы предотвратить распределение модулей на этом узле.
Tolerations (допуски) применяются к модулю, чтобы позволить этому модулю игнорировать указанные taints.
Чтобы узнать больше о надписях узлов, привязке узлов, тайнах и разрешениях в целом, обратитесь к документации Kubernetes. Для получения информации о применении привязки узлов и допусков к модулям в ArcGIS Enterprise on Kubernetes см. Управлять размещением модуля.
Преимущества
Надписи узлов и привязка узлов гарантируют, что модуль распределяется на соответствующем узле. Taints и tolerations гарантируют, что на узле распределены только соответствующие модули. Использование их в сочетании помогает улучшить изоляцию, оптимизировать распределение ресурсов и эффективно соответствовать требованиям соответствия внутри вашего кластера Kubernetes:
Изолируйте рабочие нагрузки со специальными требованиями — используйте метки и правила привязки узлов, чтобы гарантировать, что определенные модули будут запланированы на выделенных узлах. Используйте запреты, чтобы пометить узлы с определенными характеристиками, такими как высокие требования к процессору или памяти, в качестве предназначенных для рабочих нагрузок ArcGIS. Примените разрешения к сервисным модулям, чтобы гарантировать их планирование на узлах с необходимыми ресурсами.
Оптимизация распределения ресурсов — применяйте запреты к узлам с ограниченными ресурсами, чтобы предотвратить перегрузку ресурсов, и задавайте разрешения для сервисных модулей, чтобы добиться соответствия ограничениям ресурсов на этих узлах. Объедините привязку узлов с ограничениями и допусками, чтобы гарантировать, что сервисные модули будут запланированы только на тех узлах, которые могут удовлетворить их потребности в ресурсах.
Планирование на основе геолокации — для приложений, требующих локальности данных или соблюдения определенных правил, используйте привязку узлов для планирования сервисных модулей на основе географического расположения узлов. Запретите узлы, основываясь на их физическом местоположении или правилах суверенитета данных и примените разрешения к сервисным модулям, чтобы быть уверенным в том, что они запланированы на узлах и соответствуют требуемым ограничениям местоположения.
Автоматическое масштабирование улучшает использование привязки узлов и допусков за счет динамической регулировки количества модулей в зависимости от требований рабочей нагрузки. Такое динамическое масштабирование гарантирует эффективное планирование модулей на узлах, которые соответствуют определенным требованиям или содержат необходимые ресурсы, оптимизируя распределение ресурсов. Сочетая автоматическое масштабирование с привязкой узлов и разрешениями, кластеры Kubernetes могут достичь улучшенного использования ресурсов, производительности и масштабируемости, адаптируясь к колебаниям рабочей нагрузки при соблюдении ограничений и предпочтений узлов. Подробнее об автоматическом масштабировании см. в разделе Масштабирование сервисов.
Управление размещением модуля
Рекомендуется применять надписи узлов до привязки узлов. Это предотвращает зависание модулей в состоянии ожидания, поскольку узлы еще не имеют соответствующей надписи. Аналогично, рекомендуется применять разрешения до применения тайн к узлам. Это гарантирует, что вы избежите непреднамеренного удаления модулей, которые еще не имеют соответствующих допусков, что приведет к перебоям в работе ваших сервисов.
В большинстве сред вы можете группировать рабочие нагрузки, используя пулы или группы узлов. Рекомендуется применять метки и запреты к группам узлов, а не к отдельным узлам.
В ArcGIS Enterprise on Kubernetes вы можете использовать ArcGIS Enterprise Manager для настройки привязки узлов и разрешений для следующих развертываний:
Конфигурация привязки узлов
Чтобы настроить правило привязки узлов, задайте следующие значения:
Тип — Тип привязки узлов. Доступны следующие типы:
Предпочитаемое (
PreferredDuringSchedulingIgnoredDuringExecution) — Модуль предпочитает быть распределенным на узле, который удовлетворяет правилу.Обязательный (
RequiredDuringSchedulingIgnoredDuringExecution) — модуль должен быть запланирован на узле, который удовлетворяет правилу.
Ключ — ключ метки узла или аннотации, которому должно соответствовать правило.
Оператор — оператор для правила. Ниже перечислены доступные операторы:
В — метка узла или аннотация должны быть в списке указанных значений.
Не в — метка узла или аннотация не должны быть в списке указанных значений.
Существует — узел должен содержать указанную метку или аннотацию.
Не существует — узел не должен содержать указанную метку или аннотацию.
Значение — список значений, которые необходимо сопоставить с меткой узла или аннотацией. Недоступно, если выбран оператор Существует или Не существует.
Конфигурация разрешений
Чтобы настроить разрешение, задайте следующие значения:
Эффект — эффект запрещения, которому должно соответствовать разрешение. Ниже следуют доступные эффекты:
Не планировать — новые модули не планируются для запрещенного узла без соответствующего разрешения.
Предпочитать не планировать — новые модули стараются избегать планирования на запрещенном узле без соответствующего разрешения, но это не гарантируется.
Не выполнять — любые модули без соответствующего допуска удаляются сразу же после запрета узла. Новые модули не планируются для запрещенного узла без соответствующего разрешения.
Ключ — ключ запрещения, которому должно соответствовать разрешение.
Оператор — оператор, используемый для разрешения. Ниже перечислены доступные операторы:
Равно — модуль разрешает запрет с указанным ключом и значением.
Существует — модуль разрешает любой запрет с указанным ключом и значением.
Значение — значение запрета, которому должно соответствовать разрешение, если для операции установлено равенство. Недоступно, если выбран оператор Существует.
Примечание:
Рабочие нагрузки сервисов растрового анализа и блокнотов, которые должны выполняться на узлах с поддержкой GPU, требуют определенных настроек привязки узлов и разрешений. Для получения дополнительной информации об этих настройках см. Настройка узлов с поддержкой графического процессора для работы с растровым анализом и Просмотр и редактирование сред выполнения для сервисов блокнотов.
Сценарии
Чтобы лучше понять, какую пользу управление размещением модулей в сервисах может принести вашей организации, рассмотрите следующие сценарии.
Сценарий 1: Сезонный всплеск трафика для публичных картографических сервисов
Публичная организация сталкивается со значительным увеличением трафика во время местного фестиваля. Пользователи, получающие доступ к веб-карте для получения информации о событиях, сталкиваются с задержками из-за высокой нагрузки на базовый картографический сервис. Для решения этой проблемы администратор организации делает следующее:
Добавляет надпись с ключом/значением high-performance: true к узлам с высокими ресурсами CPU и памяти.
Применяет правила привязки узлов для приоритизации распределения модулей сервиса карт на узлах с высокими ресурсами CPU и памяти. Это гарантирует, что сервис карт сможет справиться с резким увеличением трафика:
Тип — Предпочитаемое
Ключ — высокая производительность
Оператор — существует
Значение — true
Применяет допуск к модулям для критически важного сервиса карт, позволяя им распределяться на узлах, помеченных для высокопроизводительных рабочих нагрузок.
Эффект—NoSchedule
Ключ—workload
Оператор — равно
Значение—high-performance
Помечает высокопроизводительные узлы с помощью workload=high-performance:NoSchedule, чтобы предотвратить распределение менее критичных модулей без соответствующего допуска на этот узел. Это гарантирует наличие места на высокопроизводительных узлах для распределения модулей для сервисов, связанных с событием.
Сценарий 2: Обработка данных для мониторинга окружающей среды
Экологическое агентство выполняет серию геопространственных анализов для отслеживания изменений землепользования. Анализ требует значительных вычислительных ресурсов, и для этой цели агентство выделило узлы с графическими процессорами. Чтобы обеспечить эффективную работу геопространственного анализа без конкуренции за ресурсы с другими сервисами, администратор организации:
Добавляет надпись с ключом/значением gpu: true к узлам с включенным GPU.
Применяет правила привязки узлов для распределения модулей анализа только на узлах GPU:
Тип — обязательное
Ключ — gpu
Оператор — In
Значение — true
Применяет допуск к модулям анализа, позволяя им распределяться на помеченных узлах GPU:
Эффект—NoSchedule
Ключ—workload
Оператор — равно
Значение—high-resource
Помечает узлы GPU с помощью workload=high-resource:NoSchedule, чтобы предотвратить распределение менее ресурсоемких модулей без соответствующего допуска на этот узел. Это гарантирует, что дорогие компьютеры с поддержкой GPU используются только для модулей анализа, которым они нужны.
Сценарий 3: Оптимизация ресурсов для опубликованных сервисов объектов
Городской ГИС департамент располагает многочисленными сервисами объектов, которые используются не так часто, но в совокупности создают нагрузку на развертывание одной сервиса. Кластер содержит премиальные узлы для обеспечения гарантированного качества сервиса для высокоприоритетных сервисов и узлы с более низкой доступностью ресурсов для низкоприоритетных сервисов. Чтобы гарантировать, что эти сервисы пространственных объектов с низким приоритетом предпочтительно планируются на менее дорогих узлах, администратор организации:
Настраивает узлы с меньшей доступностью ресурсов с помощью ключа resource-constrained.
Применяет правила привязки узлов для модулей сервисов объектов, чтобы приоритизировать планирование на узлах с меньшей доступностью ресурсов:
Тип — Предпочитаемое
Ключ — resource-constrained
Оператор — DoesNotExist
Применяет разрешения для модулей сервисов объектов, чтобы гарантировать, что они могут быть запланированы на запрещенных узлах, несмотря на ограничения:
Эффект—PreferNoSchedule
Ключ — resource-constrained
Оператор — существует
Помечает узлы с меньшей доступностью ресурсов с помощью resource-constrained:PreferNoSchedule.
Сценарий 4: Предотвращение нарушения работы хранилища данных во время масштабирования кластера
Национальное правительство придерживается такой модели использования сервисов, при которой они активно используются в дневное время. Эта модель требует большого количества кластерных узлов для поддержки всех реплик модулей, необходимых для этих сервисов. Поскольку сервисы не используются в ночное время, организация хотела бы сократить количество узлов, чтобы сэкономить на затратах на облачные вычисления. Однако завершение работы узлов, на которых запущены модули хранилища данных, управляемые системным состоянием, создает риск нарушения работы ArcGIS Enterprise. Чтобы предотвратить это потенциальное разрушение, администратор организации:
Создает отдельную группу узлов.
Добавляет надпись с ключом/значением data-store: true к каждому узлу в группе.
Применяет правила привязки узлов, чтобы гарантировать, что модули запланированы на узлах этой группы
Тип — обязательное
Ключ — data-store
Оператор — In
Значение — true
Применяет разрешение к модулям хранилища данных с сохранением состояния, позволяя им работать на запрещенных узлах хранилища данных:
Эффект—NoSchedule
Ключ—workload
Оператор — равно
Значение — data-store
Помечает узлы хранилища данных с помощью workload=data-store:NoSchedule, чтобы предотвратить планирование на узле модулей, не фиксирующих состояние, без соответствующего разрешения. Это гарантирует наличие места на узлах хранилища данных для планирования всех модулей хранилища данных с сохранением состояния.
Не уменьшает объем группы узлов хранилища данных при масштабировании кластерных узлов ночью. Поскольку все модули хранилища данных с сохранением состояния находятся в этой группе узлов, на них не влияет уменьшение масштаба других групп узлов.