Ниже описаны минимальные требования к аппаратному обеспечению и инфраструктуре, необходимые для запуска ArcGIS Enterprise on Kubernetes 11.4. Эти требования также относятся к развертыванию в автономной среде.
Поддерживаемые среды
Системные требования и спецификации применяются во всех поддерживаемых средах, за исключением тех случаев, когда это указано. В этой версии поддерживаются следующие среды:
- Red Hat OpenShift Container Platform (RHOS)
- Amazon ElasticKubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Microsoft Azure Kubernetes Service (AKS)
- Rancher Kubernetes Engine (RKE и RKE2)
Рекомендуется отключить автообновление в кластере Kubernetes. Когда в вашем кластере включено автоматическое обновление, узлы будут автоматически обновлены до последней версии Kubernetes, и эти новые версии могут еще не поддерживаться ArcGIS Enterprise.
Внимание:
Чтобы обеспечить полную совместимость и поддержку, перед обновлением ArcGIS Enterprise on Kubernetes убедитесь, что ваша версия Kubernetes соответствует поддерживаемому диапазону.Для каждой среды протестированы и поддерживаются следующие версии:
| Поддерживаемая среда | Поддерживаемая версия Kubernetes |
|---|---|
Управляемые сервисы Kubernetes в облаке (AKS, EKS, GKE) Red Hat OpenShift Container Platform(включая ROSA и ARO) [4.15-4.16] RKE и RKE2 | 1.29 - 1.30 |
Примечание:
ArcGIS Enterprise on Kubernetes поддерживается только на процессорах, имеющих архитектуру x86_64 (64-разрядные). Рабочие узлы должны быть установлены на платформе Linux.
Реестр контейнеров
Изображения контейнеров для ArcGIS Enterprise on Kubernetes доступны из частной организации Docker Hub. Esri предоставит доступ к репозиториям организации тем, кто развертывает ArcGIS Enterprise on Kubernetes. При развертывании в отключенной среде нужно будет передавать образы из частной организации Docker Hub в ваш собственный личный реестр контейнеров, доступный из вашего кластера.
Получение лицензии Esri
Чтобы во время развертывания авторизовать вашу организацию ArcGIS Enterprise, вам потребуется файл лицензии ArcGIS Enterprise on Kubernetes в формате JSON (файл .json). Чтобы получить этот файл лицензии, посетите My Esri с правами "для лицензионных действий".
Рабочие узлы
ArcGIS Enterprise on Kubernetes развертывается с одним из трех архитектурных профилей. Рекомендации в отношении запросов и ограничений ресурсов (ЦПУ и памяти), а также общих требований к вычислительным ресурсам зависят от выбранного профиля. Рекомендации для каждого профиля приведены ниже.
Примечание:
Ниже приведены минимальные требования к узлу для установки программного обеспечения. Требования различаются в зависимости от выбранного архитектурного профиля. Для поддержки масштабирования рабочих нагрузок и включения возможностей в вашей организации требуются дополнительные рабочие узлы.Рекомендуется, чтобы каждый рабочий/агентский узел имел минимум 8 ЦПУ и 32 ГиБ памяти. Чтобы компенсировать загрузку образов контейнеров, связанных с ArcGIS Enterprise on Kubernetes, рекомендуется установить минимальный размер корневого диска 100 ГиБ.
| Архитектурный профиль | Минимальные требования к рабочим/агентским узлам | Общая минимальная загрузка ЦПУ | Общий минимум ГБ |
|---|---|---|---|
Повышенная доступность | 5 | 40 | 160 |
Стандартная доступность | 4 | 32 | 128 |
Разработка | 3 | 24 | 96 |
Модули в развертывании ArcGIS Enterprise on Kubernetes распределяются по рабочим узлам в кластере. Часы рабочих узлов должны быть синхронизированы с общим источником, чтобы время было согласованным внутри кластера. При масштабировании развертывания или добавлении другого развертывания ArcGIS Enterprise в кластер, необходимо соответствующим образом подготовить оборудование. Это может потребовать увеличения максимального количества модулей по умолчанию на узел. Количество изначально создаваемых модулей зависит от профиля архитектуры. По мере горизонтального масштабирования или добавления функций количество модулей увеличивается.
Безопасность
Ниже описаны требования безопасности для ArcGIS Enterprise on Kubernetes.
Контроль доступа на основе ролей
В кластере Kubernetes необходимо включить управление доступом на основе ролей (RBAC). Для развертывания ArcGIS Enterprise on Kubernetes вам не нужны права администратора кластера. Если у вас нет прав администратора кластера, пользователь должен иметь минимальные права для администрирования пространства имен. Вы можете назначить пользователю роль по умолчанию ClusterRole, создав RoleBinding в пространстве имен. Подробнее см. Ресурсы роли RBAC.
Регистрация папки данных
Чтобы опубликовать элементы с использованием файловых данных, например, элементы, опубликованные из файловой базы геоданных на сетевом ресурсе, коллекции листов кэша или локаторы, можно разместить данные в опубликованном местоположении NFS или добавить хранилище данных на основе PV. Чтобы убедиться в том, что ГИС и системные сервисы могут получить доступ к общему расположению соответствующим образом, идентификатор пользователя и группы для запущенных модулей сервисов или других прав на доступ к каталогу должен предоставлять доступ на чтение к общему ресурсу, его подкаталогам и файлам, содержащимся в нем. После регистрации этой папки хранилища данных в организации вы сможете избежать необходимости копирования данных в организацию в процессе публикации. Для серверов NFS вы можете управлять безопасностью на уровне сети или инфраструктуры, разрешая сетевой доступ только к диапазону IP-адресов модулей для экспорта.
Сеть
К сетевым требованиям относятся полное доменное имя (FQDN) и балансировщик нагрузки или обратный прокси, который направляет трафик от клиентов через стандартный порт HTTPS (443) к заданным целевым элементам. Описание каждого из них приведено ниже.
Полное доменное имя
ArcGIS Enterprise on Kubernetes требует полное доменное имя (например, map.company.com). Для создания записи CNAME или A можно использовать существующую службу системы доменных имен (DNS) или интегрировать ее с DNS-службой провайдера облачных услуг, например Amazon Route 53. DNS-запись можно создать после развертывания, но полное доменное имя (FQDN) должно быть указано в процессе развертывания. В этом выпуске полное доменное имя нельзя изменить после развертывания.
Балансировщик нагрузки
Для направления трафика в ваше развертывание ArcGIS Enterprise on Kubernetes можно использовать балансировщик нагрузки. Можно подготовить балансировщики нагрузки как уровня 4, так и уровня 7 из сценария развертывания без какой-либо ручной настройки. Балансировщики нагрузки, интегрированные в ваше развертывание из скриптов развертывания, направляют трафик непосредственно в модуль входящего контроллера NGINX внутри кластера.
Или можно использовать ArcGIS Enterprise on Kubernetes Web Adaptor, чтобы направлять трафик в ваше развертывание, для чего требуется, чтобы входящий трафик отправлялся на рабочие узлы развертывания через определенный порт.
Следующие балансировщики нагрузки уровня 4 могут быть подготовлены из сценария развертывания без ручной настройки:
- Балансировщик нагрузки Azure (общедоступный или внутренний) -- в сценарии развертывания можно указать предварительно подготовленный статический общедоступный IP-адрес и метку DNS.
- Балансировщик сетевой нагрузки AWS (с выходом в интернет или внутренний) — для настройки балансировщика нагрузки при развертывании в автоматическом режиме можно использовать пользовательские аннотации. Дополнительную информацию см. в разделе о настраиваемых аннотациях входящих данных дополнительных свойств развертывания в автоматическом режиме.
Примечание:
Дополнение AWS Load Balancer Controller требуется для создания балансировщиков сетевой нагрузки в общедоступной или частной подсети.
- Балансировщик нагрузки Google Cloud Platform TCP (направленный в интернет или внутренний) -- в сценарии развертывания можно указать предварительно подготовленный статический общедоступный IP-адрес.
- Универсальный балансировщик нагрузки — поддерживает такие решения уровня 4, как MetalLB, Traefik, HAProxy и другие, с которыми организация, возможно, уже знакома и которые используются в ее локальной инфраструктуре. При использовании кластера Kubernetes в управляемом облаке следует выбрать соответствующую опцию интегрированного облака, тогда как для самоуправляемых кластеров опция универсального балансировщика нагрузки добавляет все аннотации, заданные в файле свойств развертывания, как пользовательские аннотации.
Указанные выше балансировщики нагрузки можно настроить с помощью аннотаций исходного объекта Kubernetes Service. Например, можно включить межзональную балансировку нагрузки в балансировщике сетевой нагрузки в AWS или поместить балансировщик нагрузки Azure Blob в определенную группу ресурсов. Файл шаблона deploy.properties, прилагаемый к скрипту развертывания, содержит примеры того, как эти аннотации могут быть заданы во время автоматического развертывания.
Скрипт развертывания можно использовать для использования возможностей балансировки нагрузки уровня 7, таких как брандмауэр веб-приложения, или выполнить требования организации для входа в развернутое приложение с помощью существующего входящего контроллера. Следующие балансировщики нагрузки уровня 7 могут быть развернуты или интегрированы непосредственно из сценария развертывания:
- Балансировщик нагрузки приложения AWS
Примечание:
Надстройка контроллера балансировщика нагрузки AWS требуется для создания балансировщиков нагрузки приложения в общедоступной или частной подсети.
- Шлюз приложений Azure
- Балансировщик нагрузки приложения Google Cloud Platform
RedHat OpenShift предоставляет маршруты, являющиеся интегрированной конструкцией, предназначенной для направления трафика от внешних клиентов к сервисам, существующим внутри кластера. Для этого варианта администратору необходимо создать Маршрут вне скрипта развертывания, поскольку свойства могут различаться в зависимости от требований организации. Объект Route может быть создан из консоли или из YAML и должен использовать сквозное шифрование TLS для проксирования трафика на связанный контроллер входящего трафика, но может использовать режим сквозного или повторного шифрования.
Входящий контроллер, реализованный на уровне кластера, будет использовать эти балансировщики нагрузки для реализации правил входа на уровне кластера для направления входящего трафика в развертывание ArcGIS Enterprise on Kubernetes. Чтобы реализовать эти балансировщики нагрузки из скрипта развертывания перед автоматическим развертыванием, можно изменить файл шаблона YAML в папке layer-7-templates, сохранить его на своей клиентской рабочей станции и указать это местоположение для параметра CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME. Дополнительные сведения см. в разделе Входящие контроллеры уровня кластера.
Примечание:
Для поддержки сервисов Notebook все внешние обратные прокси-серверы или балансировщики нагрузки должны содержать требования, чтобы сеансы оставались открытыми в течение 10 минут.
При использовании самоуправляемого балансировщика нагрузки или обратного прокси, такого как NGINX, для заголовка X-Forwarded-Host должно быть задано значение заголовка Host URL-адреса клиента, чтобы обеспечить правильное направление трафика на URL-адрес вашей организации ArcGIS Enterprise. В NGINX это можно сделать с помощью следующего указания: proxy_set_header X-Forwarded-Host $host;
Примечание:
ArcGIS Enterprise не поддерживает протокол SSL-разгрузки через обратный балансировщик прокси/нагрузки. Если ваша конфигурация использует обратный прокси, он должен быть перенаправлен либо к ArcGIS Web Adaptor, либо напрямую к организации через HTTPS.
Требования к IP
Заблаговременное планирование кластерной сети необходимо для обеспечения успешного развертывания, соответствующих требований к масштабированию и возможности обновления. ArcGIS Enterprise on Kubernetes изначально развертывает 47-66 модулей - в зависимости от профиля архитектуры. Число модулей будет увеличиваться по мере добавления дополнительных возможностей, масштабирования развертывания и в процессе обновления.
Каждому модулю назначается уникальный IP-адрес, и в зависимости от конфигурации сети кластера модули могут получать свои IP-адреса либо из адресного пространства, логически отличающегося от адресного пространства хост-сети (оверлейная сеть), либо из подсети хоста. Например, если вы настроите свой кластер на использование Kubenet в Azure (по умолчанию), модули получат IP-адрес из логически другого адресного пространства и смогут получить доступ к ресурсам Azure с помощью NAT.
Kubernetes поддерживает сетевой интерфейс Container Network Interface (CNI) и такие платформы, как AKS и EKS, которые используют подключаемые плагины CNI для конкретных платформ кластерной сети. Например, кластеры EKS по умолчанию используют Virtual Private Cloud (VPC) CNI. Если кластер настроен с подключаемым плагином CNI, модули будут получать IP-адреса из подсети узла и соответствующего пула IP-адресов, доступных в VPC/VNet.
Если у вас нет достаточного количества доступных в подсетях узла IP-адресов, развертывание либо завершится ошибкой, либо вы не сможете масштабировать развертывание. Например, если кластер EKS настроен с двумя подсетями в каждой и префиксом IPv4-адреса /26 (по 64 доступных IPv4-адреса), то для модулей не может быть более 126 IP-адресов. Хотя вы, возможно, сможете выполнить развертывание ArcGIS Enterprise on Kubernetes в этом кластере, вы не сможете масштабировать развертывание до 80 модулей сервисов объектов, поскольку это требование масштабирования приведет к превышению числа доступных IP-адресов.
Системное хранилище
Для ArcGIS Enterprise on Kubernetes требуются постоянные тома (PV) для системного хранилища, которые могут быть предоставлены динамически с помощью класса хранилища или статически администратором до создания организации. Подробнее о статической подготовке и динамической подготовке.
Рабочие нагрузки ArcGIS Enterprise с отслеживанием состояния включают системы управления реляционными базами данных и базы данных NoSQL. Рекомендуется предоставлять PV на блочных устройствах хранения, которые обеспечивают низкую задержку, таких как тома EBS при использовании EKS, Azure Disks при использовании AKS, Persistent Disks при использовании GKE и тома vSphereVolume или Longhorn при развертывании в самоуправляемые кластеры.
Поскольку в этих PV хранятся данные и настройки вашей организации, вы должны защитить их с помощью строгих политик безопасности. Для PV на основе сетевого файлового хранилища, такого как NFS, Azure Files или GlusterFS, убедитесь, что установлены разрешения для предотвращения несанкционированного доступа. Для блочных хранилищ, таких как EBS, Azure Disk, vSphere Volume и Longhorn, убедитесь, что доступ к томам хранилища ограничен только теми пользователями, которым это необходимо.
Ниже приводится описание объемов хранения и их предназначение:
Примечание:
Требования к постоянным томам заданы для 11.4 и могут отличаться от предыдущих версий.
- В памяти - хранит временные системные ресурсы.
- Пакеты элементов - хранит большие загрузки и пакеты для поддержки рабочих процессов публикации.
- Объект — хранит загруженный и сохраненный контент, размещенные кэши слоев листов, изображений и сцен, а также выходные данные геообработки.
- Очередь - предоставляет хранилище для асинхронных заданий геообработки.
- Реляционный - хранит размещенные векторные данные и административные аспекты, такие как настройки и параметры конфигурации. Для развертывания требуются два.
- Пространственно-временной и индекс - хранят журналы и индексы, а также размещенные векторные данные.
Примечание:
Пространственно-временные размещенные векторные слои не поддерживаются в этой версии.
- Данные показателей использования - хранит данные об использовании сервисов ГИС.
Рассмотрите требования к хранилищу для вашей организации и определите размер для каждого PV соответственно.
Рабочая станция клиента
Скрипты развертывания представляют собой скрипты bash, которые могут запускаться с удаленной рабочей станции клиента. Пользователь, выполняющий скрипты, должен иметь доступ на чтение и запись, чтобы скрипты могли записывать временные файлы ресурсов в подкаталоги.
Примечание:
Из-за известных проблем с совместимостью, эмуляторы Linux не поддерживаются для развертывания ArcGIS Enterprise on Kubernetes.
Следующие операционные системы были протестированы и поддерживаются для запуска скрипта развертывания, скрипта настройки и других упакованных сценариев и инструментов:
- Red Hat Enterprise Linux Server 9
- Red Hat Enterprise Linux Server 8
- AlmaLinux 9
- SUSE Linux Enterprise Server 15
- Ubuntu Server 24.04 LTS
- Ubuntu Server 22.04 LTS
- Oracle Linux 9
- Oracle Linux 8
- Rocky Linux 9
- Rocky Linux 8
Хотя другие не протестированные операционные системы и будут работать, при развертывании и настройке организации могут возникнуть неожиданные проблемы. Если вы столкнулись с проблемой в операционной системе, которая не указана выше, рекомендуется подготовить клиентскую рабочую станцию, соответствующую протестированным операционным системам.
При настройке рабочей станции клиента вам понадобится (ссылки для скачивания предоставляются):
- Kubectl
- Зависящий от среды интерфейс командной строки (CLI)
Kubectl - необходимо для запуска сценария развертывания. Используйте установку и настройку Kubectl, чтобы загрузить инструмент командной строки Kubernetes.
Примечание:
Клиентская версия kubectl должна находиться в пределах одной второстепенной версии серверной версии API Kubernetes. Например, kubectl 1.29 совместим с кластером Kubernetes версий 1.29-1.30.
При управлении развертыванием вы можете использовать инструменты командной строки для конкретной среды. Используйте следующие ссылки для загрузки интерфейса командной строки для конкретной среды:
Сертификат TLS
ArcGIS Enterprise on Kubernetes использует контроллер входящего трафика на основе NGINX. Этот входной контроллер имеет область действия пространства имен и развернут для прослушивания только входящего трафика для пространства имен ArcGIS Enterprise. В сертификате Transport Layer Security (TLS) необходимо указать FQDN (полное доменное имя) в общем имени сертификата и альтернативном имени субъекта. Можно использовать либо сертификат, подписанный ЦС, либо самозаверенный сертификат, но по соображениям безопасности настоятельно рекомендуется использовать сертификат, подписанный ЦС. Это сертификат TLS по умолчанию для контроллера входящего трафика. В сценарии развертывания доступны следующие опции сертификата для применения сертификата TLS для входящего трафика:
- Существующий секрет TLS, содержащий закрытый ключ и сертификат.
- Файл .pfx, содержащий закрытый ключ и сертификат.
- Закрытый ключ и сертификат в формате PEM
- Самозаверенный сертификат
ArcGIS Enterprise on Kubernetes поддерживает использование сертификата TLS для контроллера входящего трафика, который выдается и управляется менеджером сертификатов Kubernetes. Этот сертификат должен храниться в секрете TLS в том же пространстве имен, что и ArcGIS Enterprise. На секрет TLS можно ссылаться либо во время развертывания, либо после создания организации ArcGIS Enterprise.
ArcGIS Pro
- ArcGIS Pro 3.4 — это сопутствующая версия для ArcGIS Enterprise on Kubernetes 11.4. Чтобы воспользоваться новейшими доступными функциями, используйте ArcGIS Pro 3.4.
- Для публикации сервисов в ArcGIS Enterprise on Kubernetes требуется ArcGIS Pro 2.8 или более поздней версии.
- Чтобы получить сервисы из ArcGIS Enterprise on Kubernetes, требуется ArcGIS Pro или более поздней версии.
При регистрации элемента хранилища данных многопользовательской базы геоданных, версия базы геоданных должна быть 10.9.0.2.8 или новее.
Примечание:
Чтобы воспользоваться новейшими доступными функциями, обновите версию базы геоданных до 11.4.0.Более подробную информацию см. в разделе Совместимость клиента и базы геоданных.