Плагин YARN ищет очереди и имена приложений в них и управляет политиками доступа к тому, что решает YARN: отправке приложений в очереди, администрированию очередей и администрированию кластера. Идентификатор плагина и тип сервиса — yarn. Сервисный плагин работает на сервере GrantForge; политики применяет агент YARN, установленный в ResourceManager.
Интеграционные тесты Testcontainers в репозитории покрывают ResourceManager Hadoop 3.2.4, собранный из проверенного по SHA-512 выпуска Apache, 3.3.6, 3.4.3 и 3.5.0, а также ResourceManager 3.4.3 с Kerberos; это не сертифицирует все остальные версии.
Установка
Дистрибутив содержит плагин в plugins/yarn. Убедитесь в Управление платформой → Плагины, что yarn включён; после обновления заново просканируйте каталог плагинов. Плагин обращается к ResourceManager через собственный клиент YARN из Hadoop на основе затенённого клиента Hadoop 3.5.0 в отдельном загрузчике классов.
Добавление сервиса данных
- Откройте Права на данные → Сервисы данных, добавьте сервис и выберите Apache Hadoop YARN (
yarn). - Введите клиентский адрес ResourceManager или адреса всех ResourceManager кластера высокой доступности.
- Выберите способ входа пользователя для поиска, укажите его, проверьте подключение и сохраните сервис. Проверка выполняет вход и описывает кластер: сколько в нём NodeManager и сколько очередей.
Параметры носят собственные имена Hadoop и могут быть скопированы из yarn-site.xml. Пользователь для поиска позволяет GrantForge находить ресурсы; он отделён от пользователей, отправляющих приложения. Успешная проверка подключения не означает, что отправка уже подчиняется политикам.
| Параметр | Назначение |
|---|---|
yarn.resourcemanager.address |
Обязательно: ResourceManager, host или host:port, порт по умолчанию 8032; несколько через запятую для кластера высокой доступности, между которыми клиент переключается |
hadoop.security.authentication |
simple (по умолчанию): имя пользователя; kerberos: принципал с keytab или паролем |
username |
Обязательный пользователь для поиска; с Kerberos — полный принципал, например grantforge@EXAMPLE.COM |
password |
Kerberos: пароль принципала, если keytab не указан; хранится в зашифрованном виде |
keytab |
Kerberos: путь к keytab принципала, доступный для чтения на сервере GrantForge |
kerberos.kdc |
Kerberos: KDC realm принципала, host[:port], через запятую; пустое значение использует krb5.conf сервера |
yarn.resourcemanager.principal |
Kerberos: принципал ResourceManager, по умолчанию yarn/_HOST@ и realm принципала для поиска |
hadoop.rpc.protection |
authentication (по умолчанию), integrity или privacy, как в кластере |
timeout |
Сколько может длиться запрос, по умолчанию 30000, диапазон 1..600000 миллисекунд; собственный клиент YARN повторял бы попытки четверть часа |
Сервис определяется ровно своими параметрами: никакие core-site.xml или yarn-site.xml сервера GrantForge не читаются. Параметры Kerberos отклоняются при простой аутентификации; Kerberos требует пароль или keytab. ResourceManager, отклоняющий вход, например потому что ожидает Kerberos, сообщается как отклонённый вход.
Kerberos
С kerberos GrantForge выполняет вход принципала через собственный механизм входа Hadoop, из keytab или с паролем, сохраняет этот вход и обновляет его из keytab; больше ничему на сервере GrantForge не нужны параметры Kerberos. Realm, чьи KDC указаны в kerberos.kdc, объявляются для всего сервера GrantForge, как это делают плагины HDFS, Hive, Kafka, HBase и Trino, так что несколько сервисов могут одновременно использовать разные realm.
Ресурсы и типы доступа
| Уровень | Сопоставление | Типы доступа |
|---|---|---|
queue |
Шаблон, с учётом регистра; путь очереди от корня, например root.sales.etl |
submit_app, admin_queue |
application |
Шаблон, с учётом регистра; под очередью; имя приложения | submit_app |
cluster |
Единственное значение * |
admin: администрирование YARN, например перезагрузка очередей, узлов и меток узлов |
admin_queue включает submit_app, поскольку администраторы очереди могут отправлять в неё.
Как и в YARN, разрешение на очередь распространяется на очереди под ней: submit_app на root.sales позволяет отправлять в root.sales.etl. Проверка решается в каждой очереди пути начиная с корня, и запрет в любой из них её отклоняет; так политика может разрешить root.sales и запретить root.sales.adhoc. Под очередью уровень приложения указывает, к каким приложениям относится разрешение: submit_app на root.hr с приложением payroll-* принимает только приложения, чьё имя начинается с payroll-, в root.hr и очередях под ней.
В значениях политик * соответствует любому числу символов, а ? — одному. Редактор политик предлагает очереди по пути или по собственному имени, если вводится оно, независимо от планировщика кластера, а также имена приложений, которые ResourceManager ещё помнит в очередях, указанных в политике.
Адреса клиентов
Элемент политики может действовать только для некоторых клиентов: его условие Адреса клиентов (ip-range) принимает адреса, диапазоны вроде 10.1.0.0/16 и имена хостов, как собственные списки хостов Hadoop. За прокси, например веб-прокси YARN или маршрутизатором, клиентом считается первый адрес, переданный прокси. Адреса и диапазоны лучше имён хостов, которые требуют разрешения имени клиента. YARN спрашивает о своём администрировании без адреса клиента, поэтому на cluster условие никогда не выполняется.
Пример политик
Допустим, в кластере есть очереди root.sales.etl, root.sales.adhoc и root.hr. Создайте в одном сервисе данных следующие включённые политики доступа:
| Ресурсы | Правило |
|---|---|
queue=root.sales |
Разрешить submit_app группе analysts |
queue=root.sales.adhoc |
Запретить submit_app пользователю alice |
queue=root.hr, application=payroll-* |
Разрешить submit_app пользователю bob |
queue=root.sales |
Разрешить admin_queue пользователю carol |
queue=root |
Разрешить submit_app группе etl-robots из 10.0.0.0/8 |
cluster=* |
Разрешить admin группе yarn-admins |
Когда агент применит новый снимок, участники analysts смогут отправлять в root.sales.etl и root.sales.adhoc, а alice — только в root.sales.etl; bob отправляет приложения расчёта зарплаты в root.hr и ничего больше; carol отправляет в очереди продаж и завершает их приложения; участники etl-robots отправляют в любые очереди, но только из внутренней сети; а участники yarn-admins перезагружают очереди.
Применение политик
Сервисный плагин управляет политиками и ищет ресурсы. Для их применения нужен агент YARN в каждом ResourceManager. Развёртывание и проверки описаны в агенте YARN.