Ниже описаны минимальные требования к аппаратному обеспечению и инфраструктуре, необходимые для запуска ArcGIS Enterprise on Kubernetes 11.3. Эти требования также относятся к развертыванию в автономной среде.
Поддерживаемые среды
Системные требования и спецификации применяются во всех поддерживаемых средах, за исключением тех случаев, когда это указано. В этой версии поддерживаются следующие среды:
- 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.14] RKE и RKE2 | 1.27 - 1.29 |
Примечание:
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. Этот общий ресурс NFS должен быть зарегистрирован в организации ArcGIS Enterprise, чтобы избежать копирования данных на сервер во время публикации. Чтобы успешно зарегистрировать общую папку, вам нужно будет предоставить другим пользователям права на чтение на уровне файлов. Вы можете защитить общий ресурс 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 Network балансировщик нагрузки (с выходом в интернет или внутренний) - можно использовать другие сервисы балансировки нагрузки; однако их необходимо настраивать вручную для каждого узла кластера.
Примечание:
Дополнение AWS Load Balancer Controller требуется для создания балансировщиков сетевой нагрузки в общедоступной или частной подсети.
- Балансировщик нагрузки Google Cloud Platform TCP (направленный в интернет или внутренний) -- в сценарии развертывания можно указать предварительно подготовленный статический общедоступный IP-адрес.
Указанные выше балансировщики нагрузки можно настроить с помощью аннотаций исходного объекта Kubernetes Service. Например, можно включить межзональную балансировку нагрузки в балансировщике сетевой нагрузки в AWS или поместить балансировщик нагрузки Azure Blob в определенную группу ресурсов. Файл шаблона deploy.properties, прилагаемый к скрипту развертывания, содержит примеры того, как эти аннотации могут быть заданы во время автоматического развертывания.
Скрипт развертывания можно использовать для использования возможностей балансировки нагрузки уровня 7, таких как брандмауэр веб-приложения, или выполнить требования организации для входа в развернутое приложение с помощью существующего входящего контроллера. Следующие балансировщики нагрузки уровня 7 могут быть развернуты или интегрированы непосредственно из сценария развертывания:
- Балансировщик нагрузки приложения AWS
Примечание:
Надстройка контроллера балансировщика нагрузки AWS требуется для создания балансировщиков нагрузки приложения в общедоступной или частной подсети.
- Шлюз приложений Azure
- Балансировщик нагрузки приложения Google Cloud Platform
Входящий контроллер, реализованный на уровне кластера, будет использовать эти балансировщики нагрузки для реализации правил входа на уровне кластера для направления входящего трафика в развертывание ArcGIS Enterprise on Kubernetes. Чтобы реализовать эти балансировщики нагрузки из скрипта развертывания перед автоматическим развертыванием, можно изменить файл шаблона YAML в папке layer-7-templates, сохранить его на своей клиентской рабочей станции и указать это местоположение для параметра CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME. Дополнительные сведения см. в разделе Входящие контроллеры уровня кластера.
При использовании самоуправляемого балансировщика нагрузки или обратного прокси, такого как 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.3 и могут отличаться от предыдущих версий.
- В памяти - хранит временные системные ресурсы.
- Пакеты элементов - хранит большие загрузки и пакеты для поддержки рабочих процессов публикации.
- Объект — хранит загруженный и сохраненный контент, размещенные кэши слоев листов, изображений и сцен, а также выходные данные геообработки.
- Очередь - предоставляет хранилище для асинхронных заданий геообработки.
- Реляционный - хранит размещенные векторные данные и административные аспекты, такие как настройки и параметры конфигурации. Для развертывания требуются два.
- Пространственно-временной и индекс - хранят журналы и индексы, а также размещенные векторные данные.
Примечание:
Пространственно-временные размещенные векторные слои не поддерживаются в этой версии.
- Данные показателей использования - хранит данные об использовании сервисов ГИС.
Рассмотрите требования к хранилищу для вашей организации и определите размер для каждого PV соответственно.
Рабочая станция клиента
Скрипты развертывания представляют собой скрипты bash, которые могут запускаться с удаленной рабочей станции клиента. Пользователь, выполняющий скрипты, должен иметь доступ на чтение и запись, чтобы скрипты могли записывать временные файлы ресурсов в подкаталоги.
Примечание:
Из-за известных проблем с совместимостью, эмуляторы Linux не поддерживаются для развертывания ArcGIS Enterprise on Kubernetes.
При настройке рабочей станции клиента вам понадобится (ссылки для скачивания предоставляются):
- Kubectl
- Зависящий от среды интерфейс командной строки (CLI)
Kubectl - необходимо для запуска сценария развертывания. Используйте установку и настройку Kubectl, чтобы загрузить инструмент командной строки Kubernetes.
Примечание:
Клиентская версия kubectl должна находиться в пределах одной второстепенной версии серверной версии API Kubernetes. Например, kubectl 1.28 совместим с кластером Kubernetes версий 1.27-1.29.
При управлении развертыванием вы можете использовать инструменты командной строки для конкретной среды. Используйте следующие ссылки для загрузки интерфейса командной строки для конкретной среды:
Сертификат 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.3 — это сопутствующая версия для ArcGIS Enterprise on Kubernetes 11.3. Чтобы воспользоваться новейшими доступными функциями, используйте ArcGIS Pro 3.3.
- Для публикации сервисов в ArcGIS Enterprise on Kubernetes требуется ArcGIS Pro 2.8 или более поздней версии.
- Чтобы получить сервисы из ArcGIS Enterprise on Kubernetes, требуется ArcGIS Pro или более поздней версии.
При регистрации элемента хранилища данных многопользовательской базы геоданных, версия базы геоданных должна быть 10.9.0.2.8 или новее.
Примечание:
Чтобы воспользоваться новейшими доступными функциями, обновите версию базы геоданных до 11.3.0.Более подробную информацию см. в разделе Совместимость клиента и базы геоданных.