返回顶部

系统要求

在本主题中

  1. 支持的环境
  2. 容器注册表
  3. 获取 Esri 许可
  4. Kubernetes 集群
  5. CPU 和内存
  6. 资源配额对象
  7. 安全性
  8. 网络
  9. 系统存储
  10. 客户端工作站
  11. TLS 证书
  12. ArcGIS Enterprise on Kubernetes 和 ArcGIS Pro

下面介绍了运行 ArcGIS Enterprise on Kubernetes 10.9.1 所需的最低硬件和基础架构。

支持的环境

如无特殊说明，系统要求和规范适用于所有受支持的环境。 对于此版本，支持以下环境：

  • 内部部署数据中心
    • Red Hat OpenShift Container Platform 4.6 - 4.8
  • 云端托管的 Kubernetes 服务
    • Amazon Elastic Kubernetes 服务 (EKS)
    • Google Kubernetes Engine (GKE)
    • Microsoft Azure Kubernetes 服务 (AKS)

容器注册表

您可以从私有 Docker Hub 资料档案库访问 ArcGIS Enterprise on Kubernetes 的容器映像。 Esri 将为正在部署 ArcGIS Enterprise on Kubernetes 的人员提供对此资料档案库的访问权限。

获取 Esri 许可

要在部署过程中授权 ArcGIS Enterprise 组织，您需要 JSON 格式的用户类型许可文件（.json 文件）和 ECP 或 PRVC 格式的服务器许可文件（.ecp 或 .prvc 文件）。 要获得这些许可文件，请通过“采取许可操作”权限访问 My Esri，然后执行以下操作：

  1. 登录到 My Esri。
  2. 选择我的组织 > 许可。
  3. 在许可 Esri 产品下，单击开始。
  4. 对于产品，选择 ArcGIS Enterprise；对于版本，选择适当的 ArcGIS Enterprise 版本；然后从许可类型列表中继续执行为 ArcGIS Server 和 Portal for ArcGIS 生成许可文件的步骤，包括您的服务器角色、用户类型和应用程序（如果适用）。

Kubernetes 集群

要部署 ArcGIS Enterprise on Kubernetes，您必须在上述环境之一中拥有 Kubernetes 集群。 对于每个支持的环境，支持以下 Kubernetes 集群版本。

ArcGIS Enterprise on Kubernetes 版本受支持的 Kubernetes 集群版本

10.9.1

1.19 - 1.21

注：

在 GKE 中创建集群时，必须使用标准操作模式。 不支持自动导航模式。

命名空间

ArcGIS Enterprise on Kubernetes 需要自己专有的命名空间。 必须在运行部署脚本之前创建命名空间。 ArcGIS Enterprise on Kubernetes 的每个部署也都需要专有的命名空间。

CPU 和内存

ArcGIS Enterprise on Kubernetes 与三个架构配置文件之一一起部署。 关于资源（CPU 和内存）请求和限制以及整体计算要求的建议会根据所选配置文件而有所不同。 下面提供了对每个配置文件的建议。

以下是每个架构配置文件的最低节点要求。 建议每个工作/代理节点至少具有 8 个 CPU 和 32 GiB 的内存。

架构配置文件最低工作/代理节点最低 CPU 总数最低 GiB 总数

标准可用性

3

24

96

增强可用性

4

32

128

开发

2

16

64

注：

ArcGIS Enterprise on Kubernetes 仅在采用 x86_64 架构（64 位）的 CPU 上受支持。

ArcGIS Enterprise on Kubernetes 部署中的 Pod 分布在集群中的所有工作节点上。 在扩展部署或将其他 ArcGIS Enterprise 部署添加到集群中时，您需要相应地配置硬件。 这可能需要增加每个节点的默认最大 Pod 数。 最初创建的 Pod 的数量随每个架构配置文件而变化。 当您水平缩放或添加新功能时，Pod 的数量会增加。

注：

ArcGIS Enterprise on Kubernetes 不支持 GKE 环境中的 Windows Server 节点映像。

资源配额对象

ArcGIS Enterprise on Kubernetes Pod 具有已定义的 CPU 和内存的请求和限制。 如果命名空间包含 ResourceQuota 对象，则配额必须高于所有 Pod 的请求和限制的总和。 这些值将根据您选择的架构配置文件而有所不同，如下所述。

注：

如果要升级到 10.9.1，则必须首先将命名空间中的资源配额值更新为 10.9.1 要求。

建议您至少留出 10％ 的请求资源，以使集群节点正常运行。

每个配置文件的以下配额建议基于上述保留数量。 所描绘的限值是占位符，必须根据您的可扩展性要求进行配置：

标准可用性配置文件：

spec: 
    hard: 
      limits.cpu: "128" 
      limits.memory: 228Gi 
      requests.cpu: "22" 
      requests.memory: 86Gi

增强可用性配置文件：

spec: 
    hard: 
      limits.cpu: "132" 
      limits.memory: 256Gi 
      requests.cpu: "28" 
      requests.memory: 108Gi

开发配置文件：

spec: 
    hard: 
      limits.cpu: "96" 
      limits.memory: 164Gi 
      requests.cpu: "14" 
      requests.memory: 72Gi

安全性

ArcGIS Enterprise on Kubernetes 的安全要求如下所述。

基于角色的访问控制

必须在 Kubernetes 集群上启用基于角色的访问控制 (RBAC)。 您无需 cluster-admin 权限即可部署 ArcGIS Enterprise on Kubernetes。 如果您没有 cluster-admin 权限，则用户必须拥有最小命名空间管理权限。 您可以通过在命名空间中创建 RoleBinding 将 defaultClusterRole admin 分配给用户。

Pod 安全策略（OpenShift 中的安全上下文限制）和虚拟内存

ArcGIS Enterprise on Kubernetes 可部署 Elasticsearch 以支持 ArcGIS Enterprise 组织的各种要素。 默认情况下，Elasticsearch 使用 mmapfs 目录来存储所需索引。 默认的操作系统 mmap 计数限制可能不足以执行部署操作。 Elasticsearch 建议使用默认 vm.max_map_count 值 262144。 要更改默认值，每个节点都需要高级 (root) 权限。

根据 Kubernetes 集群允许容器以特权还是非特权方式运行，您需要执行以下操作。

  • 以特权方式运行 - ArcGIS Enterprise on Kubernetes 将在运行 Elasticsearch 的节点上运行特权初始化容器，并且不需要执行其他操作。
  • 以非特权方式运行 - 如果您的 Kubernetes 集群已定义 Pod 安全性，并且不允许容器以特权方式运行，则可以使用以下选项。
    • 选项 1 - ArcGIS Enterprise on Kubernetes 部署脚本可在其命名空间下创建服务帐户以运行容器。 默认服务帐户为 arcgis-admin-serviceaccount。 如果集群包含 Pod 安全策略，则必须允许服务帐户以特权方式运行容器。 对于 OpenShift，您可以通过在用户部分中添加以下内容来向该服务帐户授予访问特权安全上下文限制的权限。
      “-system:serviceaccount: <Namespace>:arcgis-admin-serviceaccount"
    • 选项 2 - 如果无法向服务帐户授予以特权方式运行容器的权限，则必须通过以 root 身份运行以下命令来手动准备每个节点：
      sysctl -w vm.max_map_count=262144

如果使用 Kubernetes NetworkPolicies，请确保在 ArcGIS Enterprise 命名空间中允许不间断的 Pod 到 Pod 和 Pod 到服务的通信。

此外，确保命名空间中的 Pod 有权访问 Kubernetes API 服务器。 可通过默认命名空间中名为 Kubernetes 的服务访问 API 服务器。 ArcGIS Enterprise pod 使用完全限定域名 (FQDN) kubernetes.default.svc.cluster.local 查询 API 服务器。

注：

cluster.local 是集群的默认域。

注：

必须允许集群中的 Pod 使用 FSGroup 和 SupplementalGroup ID 117932853 运行。

网络

网络要求包括 FQDN 和负载均衡器。 下面提供了每一项的详细信息。

完全限定域名

ArcGIS Enterprise on Kubernetes 需要 FQDN（例如 map.company.com）。 您可以使用现有域名系统 (DNS) 创建域名，也可以使用 Cloud DNS 服务（例如 Amazon Route 53）。 您可以在部署后创建 DNS 记录，但是在部署期间必须提供其值。 在此版本中，您在部署后无法修改 FQDN。

负载均衡器

您需要使用负载均衡器将流量引入每个工作节点。 使用 AKS 或 EKS 时，可以从部署脚本配置以下负载均衡器，而无需进行手动配置：

  • Azure 负载均衡器（公共或内部）- 可以在部署脚本中指定预配置的静态公共 IP 地址和 DNS 标注。
  • AWS 网络负载均衡器（面向 Internet 或内部）- 可以使用其他负载均衡服务；但是，必须在每个集群节点上手动对其进行配置。

在 OpenShift 容器平台中，可以在指向入口控制器服务时配置路径。

您可以使用自我管理的负载均衡器，该负载均衡器指向入口控制器服务的 NodePort 上的工作节点。 有关详细信息，请参阅负载均衡器的部署指南的参数描述。

使用自我管理负载均衡器或反向代理（如 NGINX）时，请指定以下连接：proxy_set_header X-Forwarded-Host $host;。 要确保将流量正确路由到您 ArcGIS Enterprise 组织的 URL，需要使用此标题。

系统存储

对于系统存储，ArcGIS Enterprise on Kubernetes 需要永久卷 (PV)。 您可以将其设置为动态或静态形式。 创建两种类型的 PV 时，可以使用自定义大小（较大尺寸）和标注。 ArcGIS Enterprise 的有状态的工作负载包括关系数据库管理系统以及 NoSQL 数据库。 建议使用提供低延迟的块存储设备，例如 EBS 卷、Azure 磁盘 或 vSphereVolume。

由于这些永久卷存储数据和设置，因此应使用限制性安全策略对其进行保护。 对于以基于文件的存储（例如 NFS、Azure File 或 Gluster）为基础的永久卷，请确保设置目录权限以防止未经授权的访问。 对于块存储，例如 EBS 卷、Azure 磁盘和 iSCSI，请确保块设备仅限于那些需要访问的用户。

以下是存储卷及其预期用途的说明：

注：

永久卷要求针对 10.9.1，可能与之前的版本有所不同。

  • 内存中 - 存储临时系统资源。
  • 项目包 - 存储大型上传文件和文件包，以支持发布工作流。
  • 对象 - 存储已上传和保存的内容、托管切片和图像图层缓存以及地理处理输出。 部署需要四项内容。
  • 队列 - 存储异步地理处理作业。
  • 关系 - 存储托管要素数据和管理内容（例如自定义和配置设置）。 部署需要两项内容。
  • 时空和索引 - 存储日志和索引以及托管要素数据，以支持实时和大数据的可视化和分析。
  • 使用度量数据 - 存储 GIS 服务使用情况数据。

考虑组织的存储要求，并相应地定义每个 PV 的大小。

静态 PV

如果要在部署之前配置静态 PV，则建议使用下述规范和标注。

提供了每个架构配置文件所需的 PV 数量。

卷开发配置文件标准可用性配置文件增强可用性配置文件

in-memory-volume

1

1

1

item-packages-volume

1

2

2

object-volume

1

4

12

queue-volume

1

2

2

relational-volume

2

2

2

spatiotemporal-and-index-volume

1

3

5

usage-metric-volume

1

1

1

使用设置向导配置组织时，以下规范（卷名、大小、应用程序和层）可用于卷绑定；但是，您可以根据需要对其进行自定义。

卷大小 (GiB)（最小）访问模式标注

in-memory-volume

16

ReadWriteOnce

arcgis/tier=storage,

arcgis/app=ignite

item-packages-volume

16

ReadWriteOnce

arcgis/tier=api,

arcgis/app=sharing

object-volume

16

ReadWriteOnce

arcgis/tier=storage,

arcgis/app=minio

queue-volume

16

ReadWriteOnce

arcgis/tier=queue,

arcgis/app=rabbitmq

relational-volume

16

ReadWriteOnce

arcgis/tier=storage,

arcgis/app=postgres

spatiotemporal-and-index-volume

16

ReadWriteOnce

arcgis/tier=storage,

arcgis/app=elasticsearch

usage-metric-volume

30

ReadWriteOnce

arcgis/tier=storage,

arcgis/app=prometheus

动态 PV

对于动态配置，需要 StorageClass。

StorageClass 上的 reclaimPolicy 参数必须设置为 retain。

注：
并非所有的 VM 类型都支持 Azure 中的高级磁盘。 VM 类型支持高级磁盘时，请使用高级磁盘。
  • 对于 AKS，StorageClass 定义（高级 Azure 磁盘）的示例如下所示：
    kind: StorageClass 
apiVersion: storage.k8s.io/v1 
metadata: 
  name: arcgis-storage-default 
provisioner: kubernetes.io/azure-disk 
parameters: 
  kind: Managed 
  storageaccounttype: Premium_LRS 
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
  • 对于 EKS，StorageClass 定义（GP2 类型 EBS 卷）的示例如下所示：
    kind: StorageClass 
apiVersion: storage.k8s.io/v1 
metadata: 
  name: arcgis-storage-default  
provisioner: kubernetes.io/aws-ebs 
parameters: 
  fsType: ext4 
  type: gp2 
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

您还可以使用随 AKS 或 EKS 集群提供的默认存储类。 在 AKS 中，这些存储类为默认（Azure 磁盘）或托管高级存储类。 在 EKS 中，这是 GP2 存储类。

部署后存储要求

部署后，将对项目包 PV 使用其他存储要求以执行升级和扩展 Portal API 部署，如下所述。

您在部署期间配置的预置存储类型将用于确定升级和扩展的要求：

  • 动态 PV - 存储由软件扩展和调整，前提是有足够的满足存储类规范的可用存储。
  • 静态 PV - 管理员需要提供具有与部署期间指定规范相同规范（标注、大小和访问模式）的其他项目包 PV，以支持扩展和升级工作流。

升级

在升级之前，已为组织的 Portal API 部署中的每个 Pod 配置一个项目包 PV。 在准备升级时，必须为 Portal API 部署中的每个 Pod 配置一个额外 PV。

例如，如果在升级之前，Portal API 部署配置了三个正在运行的 Pod，则必须使用与部署期间指定规范等效的规范来提供和配置六个 PV。

升级完成后，Portal API 部署将使用新配置的永久卷和永久卷声明，并且可以移除原始设置。

扩展 Portal API

要扩展 Portal API 部署（以增加参与 Pod 的数量），添加到部署中的每个附加 Pod 都需要一个额外的项目包 PV。 例如，如果组织需要三个 Pod 用于 Portal API 部署，则必须使用与部署期间指定规范等效的规范来提供和配置至少三个项目包 PV。

客户端工作站

部署脚本为 bash 脚本，其可从远程客户端工作站运行。

注：

使用的客户端工作站必须符合支持的环境。

设置客户端工作站时，需要以下内容（已提供下载链接）：

  • Kubectl
  • 特定于环境的命令行界面 (CLI)

Kubectl 是运行部署脚本的先决条件。 使用 Kubectl 安装和设置来下载 Kubernetes 命令行工具。

在管理部署时，您可以使用特定于环境的命令行工具。 使用以下链接下载特定于环境的 CLI：

  • Azure CLI
  • AWS CLI
  • GKE CLI
  • OpenShift CLI

TLS 证书

ArcGIS Enterprise on Kubernetes 使用基于 NGINX 的入口控制器。 此入口控制器的作用域为命名空间，并且已被部署为仅侦听 ArcGIS Enterprise 命名空间的入口流量。 需要证书通用名称和主题备选名称中包含 FQDN 的 TLS 证书。 可以使用 CA 签名证书或自签名证书；但是出于安全原因，建议使用 CA 签名证书。 这是入口控制器的默认 TLS 证书。 部署脚本可提供以下证书选项，以将 TLS 证书应用于入口流量：

  • 包含私钥和证书的现有 TLS 机密
  • 包含私钥和证书的 .pfx 文件
  • PEM 格式的私钥和证书
  • 自签名证书

ArcGIS Enterprise on Kubernetes 支持将由 Kubernetes cert-manager 颁发和管理的 TLS 证书用于入口控制器。 您必须将此证书存储在与 ArcGIS Enterprise 相同的命名空间中的 TLS 机密中。 然后，可以在部署过程中或创建 ArcGIS Enterprise 组织后引用 TLS 机密。

ArcGIS Enterprise on Kubernetes 和 ArcGIS Pro

需要 ArcGIS Pro 2.7 或更高版本才能使用 ArcGIS Enterprise on Kubernetes 的服务。 不支持以前的版本。

需要 ArcGIS Pro 2.8 或更高版本才能将服务发布到 ArcGIS Enterprise on Kubernetes。

从企业级地理数据库中注册数据存储项时，地理数据库版本必须为 10.9.0.2.8 或更高版本。 地理数据库版本号是 ArcGIS Enterprise 和 ArcGIS Pro 版本号的组合。

无法将在 ArcMap 中创建的企业级地理数据库注册为数据项。

有关此主题的反馈?

在本主题中
  1. 支持的环境
  2. 容器注册表
  3. 获取 Esri 许可
  4. Kubernetes 集群
  5. CPU 和内存
  6. 资源配额对象
  7. 安全性
  8. 网络
  9. 系统存储
  10. 客户端工作站
  11. TLS 证书
  12. ArcGIS Enterprise on Kubernetes 和 ArcGIS Pro