Системные требования
На этой странице перечислены минимум аппаратного обеспечения и инфраструктура, необходимые для запуска ArcGIS Enterprise on Kubernetes при развертывании в подключенной среде или автономной среде.
Поддерживаемые среды
Системные требования и спецификации применяются во всех поддерживаемых средах, за исключением тех случаев, когда это указано. В этой версии поддерживаются следующие среды:
Примечание:
ArcGIS Enterprise on Kubernetes поддерживается только на процессорах с архитектурой x86_64 (64 бита). Рабочие узлы должны быть на базе Linux.
Рекомендуется отключить автоматическое обновление в вашем кластере Kubernetes. Когда в вашем кластере включено автоматическое обновление, узлы будут автоматически обновляться до последней версии Kubernetes, и эти будущие версии могут еще не поддерживаться в ArcGIS Enterprise.
Внимание:
Чтобы обеспечить полную совместимость и поддержку, убедитесь, что ваша версия Kubernetes находится в поддерживаемом диапазоне перед обновлением ArcGIS Enterprise on Kubernetes.
Для каждой среды протестированы и поддерживаются следующие версии:
|
Поддерживаемая среда |
Поддерживаемая версия Kubernetes |
|---|---|
|
Управляемые службы Kubernetes в облаке (AKS, EKS, GKE) Red Hat OpenShift (самоуправляемый Kubernetes engine, ROSA и ARO) [4.20-4.21] RKE2 VMware Tanzu |
1.33 — 1.35 |
Реестр контейнеров
Образы контейнеров для ArcGIS Enterprise on Kubernetes доступны из частной организации Docker Hub. Esri предоставит доступ к репозиториям этой организации тем, кто развертывает ArcGIS Enterprise on Kubernetes.
При использовании реестра контейнеров вашей организации вам нужно будет подготовить его с помощью образов Esri. Это требуется при развертывании в автономной среде.
Получение лицензии Esri
Для авторизации вашей организации ArcGIS Enterprise во время развертывания вам потребуется файл лицензии ArcGIS Enterprise on Kubernetes в формате JSON (файл .json). Чтобы получить этот файл лицензии, посетите My Esri, имея права на выполнение действий с лицензиями.
Рабочие узлы
Рекомендуется, чтобы каждый рабочий узел/узел агента имел корневой диск размером минимум 200 ГиБ. При необходимости обратитесь к администратору кластера для увеличения системных ресурсов для рабочих узлов/узлов агентов.
Модули в развертывании ArcGIS Enterprise on Kubernetes распределены по рабочим узлам в кластере. Часы рабочих узлов должны быть синхронизированы с общим источником, чтобы время было согласованным внутри кластера.
При масштабировании развертывания или добавлении другого развертывания ArcGIS Enterprise в кластер необходимо соответствующим образом подготовить узлы. Это может потребовать увеличения максимального количества модулей по умолчанию на узел.
Требования к ресурсам
Общее количество CPU и памяти, необходимое для ArcGIS Enterprise on Kubernetes, зависит от числа реплик модулей, а также от запросов и ограничений ресурсов, заданных для этих модулей.
Если вы обновляете существующую организацию до этого выпуска, общие требования к ресурсам основываются на числе реплик модулей, а также на запросах и ограничениях ресурсов, которые вы настроили. Если вашего текущего распределения ресурсов достаточно для удовлетворения ваших потребностей, вы можете использовать тот же уровень распределения ресурсов после обновления.
Для новых развертываний начальные требования к ресурсам зависят от выбранных архитектурных профилей. В следующей таблице перечислены минимальные требования к ресурсам для установки программного обеспечения и настройки новой организации. Вам может потребоваться выделить дополнительные ресурсы сверх этих минимальных значений для поддержки масштабирования рабочих нагрузок и включения возможностей в вашей организации.
|
Стандартная производительность |
Повышенная производительность |
|
|---|---|---|
|
Среды разработки и тестирования |
|
|
|
Стандартная высокая доступность |
|
|
|
Улучшенная высокая доступность |
|
|
* Стандартная конфигурация модуля для сочетания стандартной доступности и стандартной производительности покрывается вашей лицензией.
Число узлов, необходимое для выполнения этих требований, зависит от размера узла. Например, при использовании узла размером 8 vCPU и 32 ГиБ памяти, сочетание стандартной производительности и стандартной высокой доступности потребует минимум 10 узлов. Использование узлов с 16 vCPU и 32 ГиБ памяти потребует минимум 5 узлов для этого же сочетания профилей.
При интеграции с облачными сервисами для объектных или реляционных хранилищ требования к ресурсам приложения снижаются на следующие величины, в зависимости от профиля доступности:
|
Архитектурный профиль |
Хранилище объектов |
Реляционное хранилище |
|---|---|---|
|
Улучшенная высокая доступность |
4 vCPU/ 64 ГиБ |
1 vCPU/ 4 ГиБ |
|
Стандартная высокая доступность |
1.5 vCPU/ 24 ГиБ |
1 vCPU/ 4 ГиБ |
|
Среды разработки и тестирования |
0.5 vCPU/ 8 ГиБ |
1 vCPU/ 4 ГиБ |
Безопасность
В следующих разделах описаны требования безопасности для ArcGIS Enterprise on Kubernetes.
Контроль доступа на основе ролей
В кластере Kubernetes необходимо включить управление доступом на основе ролей (RBAC). Для развертывания ArcGIS Enterprise on Kubernetes вам не нужны права cluster-admin. Если у вас нет прав cluster-admin, вы должны обладать как минимум административными правами. Вы можете назначить пользователю роль по умолчанию ClusterRole, создав RoleBinding в пространстве имен. Подробнее см. Ресурсы роли RBAC.
Поддержка SELinux
Модуль Security-Enhanced Linux (SELinux) поддерживается на рабочих узлах, на которых запущен ArcGIS Enterprise on Kubernetes. Поскольку по умолчанию политикой SELinux может запрещаться доступ ArcGIS к внутренним компонентам, администраторам может понадобиться обновить политику SELinux. Для этого переключите временно режим политики SELinux на permissive. Это приведет к записи превышений политики, например действий ArcGIS по доступу к внутренним ресурсам, но при этом такие действия будут разрешены. Администраторы могут зафиксировать эти нарушения и изменить конфигурацию политики SELinux, чтобы разрешить их, прежде чем сбросить режим политики на enforced.
Регистрация папки данных
Для публикации элементов с использованием файловых данных, таких как элементы, опубликованные из файловой базы геоданных на сетевом ресурсе, коллекции листов кэша или локаторы, вы можете разместить данные в общей папке NFS или добавить хранилище данных папки на основе PV. Чтобы ГИС и системные сервисы могли соответствующим образом получить доступ к общему ресурсу, идентификатор пользователя и ID группы для запущенных модулей сервисов или другие права доступа к каталогам должны обеспечивать права доступа на чтение к общему ресурсу, его подкаталогам и содержащимся в них файлам. После регистрации этой папки хранилища данных в организации вы сможете избежать необходимости копирования данных в организацию в процессе публикации. Для серверов NFS вы можете управлять безопасностью на уровне сети или инфраструктуры, разрешая сетевой доступ только к диапазону IP-адресов модулей для экспорта.
Сеть
К сетевым требованиям относятся полное доменное имя (FQDN) и балансировщик нагрузки или обратный прокси, который направляет трафик от клиентов через стандартный порт HTTPS (443) к заданным целевым элементам. Описание каждого из них приведено ниже.
Полное доменное имя
Для ArcGIS Enterprise on Kubernetes требуется FQDN (например, map.company.com). Для создания записи CNAME или A можно использовать существующую службу системы доменных имен (DNS) или интегрировать ее с DNS-службой провайдера облачных услуг, например Amazon Route 53. DNS-запись можно создать после развертывания, но полное доменное имя (FQDN) должно быть указано в процессе развертывания. В этом выпуске полное доменное имя нельзя изменить после развертывания.
Примечание:
Надстройка AWS Load Balancer Controller требуется для создания сетевого балансировщика нагрузки или балансировщика нагрузки приложений для кластера Amazon EKS.
Балансировщик нагрузки
Вы можете использовать балансировщик нагрузки для перенаправления трафика в ваше развертывание ArcGIS Enterprise on Kubernetes. Можно подготовить балансировщики нагрузки как уровня 4, так и уровня 7 из сценария развертывания без какой-либо ручной настройки. Балансировщики нагрузки, интегрированные в ваше развертывание из скриптов развертывания, направляют трафик непосредственно в модуль входящего контроллера NGINX внутри кластера.
Кроме того, вы можете использовать ArcGIS Enterprise on Kubernetes Web Adaptor для перенаправления трафика в ваше развертывание, что требует отправки входящего трафика на рабочие узлы развертывания через определенный порт.
Следующие балансировщики нагрузки уровня 4 могут быть подготовлены из сценария развертывания без ручной настройки:
Балансировщик нагрузки Azure (публичный или внутренний) — предварительно подготовленный статический публичный IP-адрес и метка DNS могут быть указаны в сценарии выполнения развертывания.
Балансировщик сетевой нагрузки AWS (с доступом из Интернета или внутренний) — пользовательские аннотации могут использоваться для настройки балансировщика нагрузки при автоматическом развертывании. Дополнительную информацию см. в разделе о настраиваемых аннотациях входящих данных дополнительных свойств развертывания в автоматическом режиме.
Балансировщик нагрузки Google Cloud Platform TCP (направленный в интернет или внутренний) -- в сценарии развертывания можно указать предварительно подготовленный статический общедоступный IP-адрес.
Универсальный балансировщик нагрузки — поддерживает такие решения уровня 4, как MetalLB, Traefik, HAProxy и другие, с которыми организация, возможно, уже знакома и которые используются в ее локальной инфраструктуре. При использовании кластера Kubernetes в управляемом облаке следует выбрать соответствующую опцию интегрированного облака, тогда как для самоуправляемых кластеров опция универсального балансировщика нагрузки добавляет все аннотации, заданные в файле свойств развертывания, как пользовательские аннотации.
Указанные выше балансировщики нагрузки можно настроить с помощью аннотаций к базовому объекту Kubernetes Service. Например, можно включить межзональную балансировку нагрузки в балансировщике сетевой нагрузки в AWS или поместить балансировщик нагрузки Azure Blob в определенную группу ресурсов. Файл шаблона deploy.properties, прилагаемый к скрипту развертывания, содержит примеры того, как эти аннотации могут быть заданы во время автоматического развертывания.
Скрипт развертывания можно использовать для использования возможностей балансировки нагрузки уровня 7, таких как брандмауэр веб-приложения, или выполнить требования организации для входа в развернутое приложение с помощью существующего входящего контроллера. Следующие балансировщики нагрузки уровня 7 могут быть развернуты или интегрированы непосредственно из сценария развертывания:
Балансировщик нагрузки приложения AWS
Шлюз приложений Azure
Балансировщик нагрузки приложения Google Cloud Platform
Red Hat OpenShift предоставляет Маршруты — это интегрированная конструкция для перенаправления трафика от внешних клиентов к сервисам, существующим внутри кластера. Для этого варианта администратору необходимо создать Маршрут вне скрипта развертывания, поскольку свойства могут различаться в зависимости от требований организации. Объект Route может быть создан из консоли или из YAML и должен использовать сквозное шифрование TLS для проксирования трафика на связанный контроллер входящего трафика, но может использовать режим сквозного или повторного шифрования.
Контроллер Ingress, реализованный на уровне кластера, будет использовать эти балансировщики нагрузки для реализации правил Ingress уровня кластера для перенаправления входящего трафика в развертывание ArcGIS Enterprise on Kubernetes. Чтобы реализовать эти балансировщики нагрузки из скрипта развертывания перед автоматическим развертыванием, можно изменить файл шаблона YAML в папке layer-7-templates, сохранить его на своей клиентской рабочей станции и указать это местоположение для параметра CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME. Дополнительные сведения см. в разделе Входящие контроллеры уровня кластера.
Примечание:
Для поддержки сервисов блокнотов любые внешние обратные прокси-серверы или балансировщики нагрузки должны иметь возможность передавать трафик websocket на внутренние целевые узлы и иметь такие настройки требований, чтобы сеансы оставались открытыми в течение 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 развертывает изначально, зависит от его профиля доступности. Число модулей будет увеличиваться по мере добавления дополнительных возможностей, масштабирования развертывания и в процессе обновления.
Каждому модулю назначается уникальный 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, убедитесь, что доступ к томам хранилища ограничен только теми пользователями, которым это необходимо.
Ниже приводится описание объемов хранения и их предназначение:
В памяти — хранит временные системные ресурсы.
Пакеты элементов — хранит большие загрузки и пакеты для поддержки рабочих процессов публикации.
Объект — хранит загруженный и сохраненный контент, размещенные кэши слоев листов, изображений и сцен, а также выходные данные геообработки.
Очередь — предоставляет хранилище для асинхронных заданий геообработки.
Реляционный — хранит размещенные векторные данные и административные аспекты, такие как настройки и параметры конфигурации. Для развертывания требуются два.
Пространственно-временной и индекс - хранят журналы и индексы, а также размещенные векторные данные.
Данные показателей использования — хранит данные об использовании ГИС-сервисов.
Рассмотрите требования к хранилищу для вашей организации и определите размер для каждого PV соответственно.
Рабочая станция клиента
Скрипты развертывания представляют собой скрипты bash, которые могут запускаться с удаленной рабочей станции клиента. Вы должны запускать скрипты от имени пользователя с правами на чтение и запись, чтобы скрипты могли записывать временные файлы ресурсов в подкаталоги.
Следующие операционные системы поддерживаются для запуска скрипта развертывания, скрипта настройки, а также других упакованных скриптов и инструментов:
|
Поддерживаемая операционная система |
Последние протестированные обновления или пакеты обновлений |
|---|---|
|
Red Hat Enterprise Linux Server 8 |
Update 10 |
|
Red Hat Enterprise Linux Server 9 |
Update 7 |
|
AlmaLinux 8 |
Update 10 |
|
AlmaLinux 9 |
Update 7 |
|
SUSE Linux Enterprise Server 15 |
Пакет обновлений 7 |
|
Ubuntu Server 24.04 LTS |
24.04.4 |
|
Ubuntu Server 22.04 LTS |
22.04.5 |
|
Oracle Linux 8 |
Update 10 |
|
Oracle Linux 9 |
Update 7 |
|
Rocky Linux 8 |
Update 10 |
|
Rocky Linux 9 |
Update 7 |
Рабочие станции клиентов тестируются с этими операционными системами, установленными как собственные системы Linux, а не как подсистемы или контейнеризированные среды. Хотя другие нетестируемые параметры среды оболочки, уровни совместимости Linux или операционные системы могут работать, при развертывании и настройке организации могут возникнуть непредвиденные проблемы. Если вы столкнулись с проблемой в параметре среды, рекомендуется подготовить клиентскую рабочую станцию, которая соответствует параметру среды, указанному выше.
При настройке рабочей станции клиента вам понадобится (ссылки для скачивания предоставляются):
Kubectl
Зависящий от среды интерфейс командной строки (CLI)
Kubectl — необходимо для запуска сценария развертывания. Используйте Установка и настройка Kubectl для загрузки версии инструмента командной строки Kubernetes, совместимой с версией Kubernetes вашего кластера.
При управлении развертыванием вы можете использовать инструменты командной строки для конкретной среды. Используйте следующие ссылки для загрузки интерфейса командной строки для конкретной среды:
Сертификат TLS
ArcGIS Enterprise on Kubernetes использует контроллер входящего трафика на основе NGINX. Этот контроллер входящего трафика ограничен пространством имен и развернут для прослушивания только входящего трафика для пространства имен ArcGIS Enterprise. В сертификате Transport Layer Security (TLS) необходимо указать FQDN (полное доменное имя) в общем имени сертификата и альтернативном имени субъекта. Можно использовать либо сертификат, подписанный ЦС, либо самозаверенный сертификат, но по соображениям безопасности настоятельно рекомендуется использовать сертификат, подписанный ЦС. Это сертификат TLS по умолчанию для контроллера входящего трафика. В сценарии развертывания доступны следующие опции сертификата для применения сертификата TLS для входящего трафика:
Существующий секрет TLS, содержащий закрытый ключ и сертификат
Файл
.pfx, который содержит закрытый ключ и сертификатЗакрытый ключ и сертификат в формате PEM
Самозаверенный сертификат
ArcGIS Enterprise on Kubernetes поддерживает использование сертификата TLS для контроллера входящего трафика, который выпускается и управляется cert-manager Kubernetes. Этот сертификат должен храниться в секрете TLS в том же пространстве имен, что и ArcGIS Enterprise. На секрет TLS затем можно сослаться либо во время развертывания, либо после создания организации ArcGIS Enterprise.
ArcGIS Pro
ArcGIS Pro 3.7 — это сопутствующий выпуск для ArcGIS Enterprise 12.1 на Kubernetes. Чтобы воспользоваться преимуществами самых последних доступных объектов, используйте ArcGIS Pro 3.7.
Для публикации сервисов в ArcGIS Enterprise on Kubernetes требуется ArcGIS Pro 2.8 или более поздней версии.
Для использования сервисов из ArcGIS Enterprise on Kubernetes требуется ArcGIS Pro 2.7 или более поздней версии.
При регистрации элемента хранилища данных многопользовательской базы геоданных, версия базы геоданных должна быть 10.9.0.2.8 или новее.
Более подробную информацию см. в разделе Совместимость клиента и базы геоданных.
ArcGIS Enterprise on Kubernetes Web Adaptor
ArcGIS Enterprise on Kubernetes Web Adaptor может быть интегрирован с веб-сервером IIS на Windows или с веб-сервером Java на Windows или Linux. См. системные требования ArcGIS Enterprise on Kubernetes Web Adaptor для получения информации о конкретных предварительных требованиях и требованиях к версии.