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