在此版本上运行 ArcGIS Enterprise on Kubernetes 11.0 所需的最低硬件和基础架构如下所述。 在离线环境中进行部署时，上述要求同样适用。
支持的环境
如无特殊说明，系统要求和规范适用于所有受支持的环境。 对于此版本，支持以下环境：
- 内部部署数据中心
- Red Hat OpenShift Container Platform
- 云端的托管 Kubernetes 服务
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Microsoft Azure Kubernetes Service (AKS)
在此版本中，每个环境的以下版本已经过测试并受支持：
| ArcGIS Enterprise on Kubernetes | AKS | EKS | GKE | Red Hat OpenShift |
|---|---|---|---|---|
将 11.0 部署到现有 Kubernetes 集群 | 1.21 - 1.24 | 1.21 - 1.24 | 1.21 - 1.24 | 4.7 - 4.10 |
升级现有 Kubernetes 集群 11.0 后部署 | 不支持 | 不支持 | 不支持 | N/A |
注：
要为 GIS 服务启用自动扩展，您将需要用 Metrics Server 来采集节点指标。 在 EKS 环境中进行部署时，您必须在 kube-system 命名空间中安装具有集群级别权限的 Metrics Server。 Metrics Server 默认安装在其他受支持的环境中。
容器注册表
您可以从私有 Docker Hub 资料档案库访问 ArcGIS Enterprise on Kubernetes 的容器镜像。 Esri 将为正在部署 ArcGIS Enterprise on Kubernetes 的人员提供对此资料档案库的访问权限。 在离线环境中部署时，您需要使用组织的容器注册表。
获取 Esri 许可
要在部署过程中授权 ArcGIS Enterprise 组织，您需要 JSON 格式的 ArcGIS Enterprise on Kubernetes 许可文件（.json 文件）。 要获得此许可文件，请通过采取许可操作的权限访问 My Esri。
Kubernetes 集群
要部署 ArcGIS Enterprise on Kubernetes，您必须在上述环境之一中拥有 Kubernetes 集群。
注：
在 GKE 中创建集群时，必须使用标准操作模式。 不支持自动导航模式。
注：
在 EKS 中，使用 Kubernetes 1.23 及更高版本创建或升级集群时，您需要安装 Amazon EBS 容器存储接口 (CSI) 插件。 有关详细信息，请参阅 Amazon EKS 文档。
命名空间
ArcGIS Enterprise on Kubernetes 需要自己专有的命名空间。 必须在运行部署脚本之前创建命名空间。 ArcGIS Enterprise on Kubernetes 的每个部署也都需要专有的命名空间。
CPU 和内存
ArcGIS Enterprise on Kubernetes 与三个架构配置文件之一一起部署。 关于资源（CPU 和内存）请求和限制以及整体计算要求的建议会根据所选配置文件而有所不同。 下面提供了对每个配置文件的建议。
以下是每个架构配置文件的最低节点要求。 建议每个工作/代理节点至少具有 8 个 CPU 和 32 GiB 的内存。
| 架构配置文件 | 最低工作/代理节点 | 最低 CPU 总数 | 最低 GiB 总数 |
|---|---|---|---|
标准可用性 | 4 | 32 | 128 |
增强可用性 | 5 | 40 | 160 |
开发 | 3 | 24 | 96 |
注：
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 的请求和限制的总和。 这些值将根据您选择的架构配置文件而有所不同，如下所述。
注：
如果要升级到 11.0，则必须首先将命名空间中的资源配额值更新为 11.0 要求。
建议您至少留出 10％ 的请求资源，以使集群节点正常运行。
每个配置文件的以下配额建议基于上述保留数量。 所描绘的限值是占位符，必须根据您的可扩展性要求进行配置：
标准可用性配置文件：
spec:
hard:
limits.cpu: "164"
limits.memory: 272Gi
requests.cpu: "24"
requests.memory: 108Gi
增强可用性配置文件：
spec:
hard:
limits.cpu: "192"
limits.memory: 328Gi
requests.cpu: "30"
requests.memory: 156Gi
开发配置文件：
spec:
hard:
limits.cpu: "120"
limits.memory: 188Gi
requests.cpu: "16"
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 目录来存储所需索引。 默认的操作系统 map 计数限制可能不足以执行部署操作。 Elasticsearch 建议使用默认 vm.max_map_count 值 262144。 要更改默认值，每个节点都需要高级 (root) 权限。
根据 Kubernetes 集群是否包含 Pod 安全策略以及允许容器以特权还是非特权方式运行，您需要执行以下操作：
- 如果 Kubernetes 集群不包含 Pod 安全策略但允许容器以特权方式运行，则无需执行任何操作。
- 以特权方式运行 - 如果 Kubernetes 集群已定义 Pod 安全性，并且允许容器以特权方式运行，则您必须允许 Elasticsearch 服务帐户以特权方式运行容器。 其他服务帐户不需要以特权方式运行容器。 ArcGIS Enterprise on Kubernetes 可以在运行 Elasticsearch 的节点上运行特权初始化容器，而这会更改 vm.max_map_count 值。 ArcGIS Enterprise on Kubernetes 部署脚本会在其命名空间下创建一个服务帐户，以便将 API 服务器身份验证用于 Pod 内部的进程。 Elasticsearch Pod 将使用其自己的服务帐户，而不会与其他工作负载进行共享。 默认的 Elasticsearch 服务帐户为 arcgis-elastic-serviceaccount。 您可以向使用 RBAC 角色和 RoleBinding 的 Pod 安全策略授予服务帐户访问权限。 对于 OpenShift，您可以通过在用户部分中添加以下内容来向该服务帐户授予访问特权安全上下文限制的权限：
“-system:serviceaccount: <Namespace>:arcgis-elastic-serviceaccount" - 以非特权方式运行 - 如果 Kubernetes 集群已定义 Pod 安全性，并且不允许 ElasticSearch 服务帐户以特权方式运行容器，则您必须以 root 方式运行以下命令来手动准备每个节点：
sysctl -w vm.max_map_count=262144 - 如果您已创建 PodSecurityPolicy 资源，则需要在 ArcGIS Enterprise 命名空间中授权以下服务帐户。
- arcgis-admin-serviceaccount
- arcgis-elastic-serviceaccount
- arcgis-ingress-serviceaccount
- arcgis-prometheus-serviceaccount
- arcgis-queue-serviceaccount
- 默认
ArcGIS Enterprise on Kubernetes 容器可以在没有 root 权限的情况下运行。 但是，如需控制 PodSecurityPolicy 的 fsGroup 和 supplementalGroups 的各个方面，则必须具有 RunAsAny 或包含值 117932853 的范围，如以下示例中所示。
supplementalGroups: rule: 'RunAsAny' fsGroup: rule: 'RunAsAny'supplementalGroups: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 117932853 fsGroup: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 117932853
如果使用 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 运行。
注册数据文件夹
要使用基于文件的数据发布项目（例如从文件地理数据库发布的项目），您需要将数据放置在 NFS 共享的位置。 必须将此 NFS 共享注册到 ArcGIS Enterprise 组织，以免在发布时将数据复制到服务器。 要成功注册共享文件夹，您需要向其他人授予文件级别读取权限。 您可以通过允许网络访问 Pod IP 范围来保护网络或基础架构级别的 NFS 共享。
网络
网络要求包括 FQDN 和负载均衡器。 下面提供了每一项的详细信息。
完全限定域名
ArcGIS Enterprise on Kubernetes 需要 FQDN（例如 map.company.com）。 您可以使用现有域名系统 (DNS) 创建域名，也可以使用 Cloud DNS 服务（例如 Amazon Route 53）。 您可以在部署后创建 DNS 记录，但是在部署期间必须提供其值。 在此版本中，您在部署后无法修改 FQDN。
负载均衡器
您需要使用负载均衡器将流量引入每个工作节点。 使用 AKS 或 EKS 时，可以从部署脚本配置以下负载均衡器，而无需进行手动配置：
- Azure 负载均衡器（公共或内部）- 可以在部署脚本中指定预配置的静态公共 IP 地址和 DNS 标注。
- AWS 网络负载均衡器（面向 Internet 或内部）- 可以使用其他负载均衡服务；但是，必须在每个集群节点上手动对其进行配置。
注：
在公共子网或私有子网中创建网络负载均衡器需要用到 AWS 负载均衡器控制器加载项。
在 OpenShift 容器平台中，可以在指向入口控制器服务时配置路径。
您可以使用自我管理的负载均衡器，该负载均衡器指向入口控制器服务的 NodePort 上的工作节点。 有关详细信息，请参阅负载均衡器的部署指南的参数描述。
使用自我管理负载均衡器或反向代理（如 NGINX）时，请指定以下连接：proxy_set_header X-Forwarded-Host $host;。 要确保将流量正确路由到您 ArcGIS Enterprise 组织的 URL，需要使用此标题。
IP 要求
提前规划集群网络对于确保实现成功部署、满足适当的扩展要求和提供升级能力而言至关重要。 ArcGIS Enterprise on Kubernetes 最初会部署 47-66 个 Pod，具体取决于架构配置文件。 随着其他功能的添加、部署的扩展以及升级过程的推进，Pod 的数量将会增加。
系统会向每个 Pod 分配一个唯一的 IP 地址，且 Pod 可以根据集群网络配置，从与主机网络（叠加网络）或主机子网的地址空间逻辑不同的地址空间获取其 IP 地址。 例如，如果您将集群配置为在 Azure 中使用 Kubenet（默认），则 Pod 将从逻辑不同的地址空间接收 IP 地址，并且将能够使用 NAT 访问 Azure 资源。
Kubernetes 支持容器网络接口 (CNI) 以及 AKS 和 EKS 等平台，并且会将平台特定的 CNI 插件用于集群网络。 例如，EKS 集群将默认使用虚拟私有云 (VPC) CNI。 如果集群配置有 CNI 插件，则 Pod 将接收来自主机子网以及 VPC/VNet 中可用的相应 IP 池的 IP 地址。
如果主机子网中没有足够数量的可用 IP，则部署将失败，或您将无法扩展部署。 例如，如果一个 EKS 集群配置有 2 个子网和一个 /26 IPv4 地址前缀（每个子网配置 64 个可用的 IPv4 地址），则 Pod 的可用 IP 地址不能超过 126 个。 虽然您也许能够在此集群中部署 ArcGIS Enterprise on Kubernetes，但您将无法将部署扩展为拥有 80 个要素服务 Pod，因为此扩展要求将超出可用 IP 地址的数量。
系统存储
对于系统存储，ArcGIS Enterprise on Kubernetes 需要永久卷 (PV)。 您可以将其设置为动态或静态形式。 创建两种类型的 PV 时，可以使用自定义大小（较大尺寸）和标注。 ArcGIS Enterprise 的有状态的工作负载包括关系数据库管理系统以及 NoSQL 数据库。 建议使用提供低延迟的块存储设备，例如 EBS 卷、Azure 磁盘 或 vSphereVolume。
由于这些永久卷存储数据和设置，因此应使用限制性安全策略对其进行保护。 对于以基于文件的存储（例如 NFS、Azure File 或 Gluster）为基础的永久卷，请确保设置目录权限以防止未经授权的访问。 对于块存储，例如 EBS 卷、Azure 磁盘和 iSCSI，请确保块设备仅限于那些需要访问的用户。
以下是存储卷及其预期用途的说明：
注：
永久卷要求针对 11.0，可能与之前的版本有所不同。
- 内存中 - 存储临时系统资源。
- 项目包 - 存储大型上传文件和文件包，以支持发布工作流。
- 对象 - 存储已上传和保存的内容、托管切片和图像图层缓存以及地理处理输出。 部署需要四项内容。
- 队列 - 存储异步地理处理作业。
- 关系 - 存储托管要素数据和管理内容（例如自定义和配置设置）。 部署需要两项内容。
- 时空大数据和索引 - 存储日志和索引以及托管要素数据。
- 使用度量数据 - 存储 GIS 服务使用情况数据。
考虑组织的存储要求，并相应地定义每个 PV 的大小。
静态 PV
如果要在部署之前配置静态 PV，则建议使用下述规范和标注。
提供了每个架构配置文件所需的 PV 数量。
| 体积 | 开发配置文件 | 标准可用性配置文件 | 增强可用性配置文件 |
|---|---|---|---|
in-memory-volume | 1 | 1 | 1 |
item-packages-volume | 1 | 2 | 2 |
object-volume | 1 | 3 | 8 |
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 | 32 | ReadWriteOnce | arcgis/tier=storage, arcgis/app=ozone |
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 的其他注意事项
您在部署期间配置的预置存储类型将用于确定升级和扩展的要求：
调整静态 PV 以扩展 Portal API 部署
要扩展 Portal API 部署（以增加参与 Pod 的数量），添加到部署中的每个附加 Pod 都需要一个额外的项目包 PV。 例如，如果组织需要将其他三个 Pod 用于 Portal API 部署，则必须使用与部署期间指定规范等效的规范来提供和配置至少其他三个项目包 PV。
动态 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 存储类。
客户端工作站
部署脚本为 bash 脚本，其可从远程客户端工作站运行。
注：
使用的客户端工作站必须符合支持的环境。 不支持使用 Linux 仿真器来部署 ArcGIS Enterprise on Kubernetes。
设置客户端工作站时，需要以下内容（已提供下载链接）：
- Kubectl
- 特定于环境的命令行界面 (CLI)
Kubectl 是运行部署脚本的先决条件。 使用 Kubectl 安装和设置来下载 Kubernetes 命令行工具。
在管理部署时，您可以使用特定于环境的命令行工具。 使用以下链接下载特定于环境的 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 Pro
- ArcGIS Pro 3.0 是 ArcGIS Enterprise on Kubernetes 11.0 的配套版本。 要从可用的最新功能中获益，请使用 ArcGIS Pro 3.0。
- 要将服务发布到 ArcGIS Enterprise on Kubernetes，需要使用 ArcGIS Pro 2.8 或更高版本。
- 要使用 ArcGIS Enterprise on Kubernetes 中的服务，需要使用 ArcGIS Pro 2.7 或更高版本。
从企业级地理数据库中注册数据存储项时，地理数据库版本必须为 10.9.0.2.8 或更高版本。
注：
要从可用的最新功能中获益，请将您的地理数据库版本升级到 11.0.0.3.0。升级和更新要求
在执行升级之前，您必须满足几个要求，例如：
- 如果存在可用的必要更新，则您必须在升级到此版本之前应用此更新。 查看发布说明以了解有关最新必要更新的详细信息。
- 您必须拥有此版本的统一 ArcGIS Enterprise on Kubernetes 许可。
- 您必须更新命名空间中的资源配额值以满足当前要求。
- 如果您已配置静态 PV，则必须配置额外的存储以满足升级要求。 有关更多详细信息，请参阅调整用于升级的静态 PV 部分。
- 如果您的已配置存储具有动态 PV，则您需要确保有足够的存储空间可用于存储额外的项目包、对象卷和队列卷。
- 如果您要从版本 10.9.1 升级，则您必须至少配置百分之五十 (50%) 的额外存储，以容纳每个架构配置文件的新对象存储 PV。 例如，如果您为每个对象存储 Pod 的对象存储 PV 分配了 100GB 的存储空间，则必须配置至少 150GB 的额外存储空间。
- 运行预升级脚本。 该脚本将检测和处理一切功能需求，以满足当前软件版本的要求。
- 如果您已为您的组织配置了 Web Adaptor，请查看安装和升级要求。
- 如果您的组织处于离线环境中，则请按照步骤在离线环境中应用升级或更新。
- 如果您在部署 ArcGIS Enterprise on Kubernetes 时使用您的组织的容器注册表，则在运行更新或升级之前必须将所需的容器镜像从 Esri 资料档案库复制到组织的注册表。
调整用于升级的静态 PV
在升级之前，已分别为组织的 Portal API 和队列存储部署中的每个 Pod 配置了一个项目包或队列卷 PV。 在准备升级时，必须为 Portal API 和队列存储部署中的每个 Pod 配置一个额外 PV。
例如，在升级之前，如果队列存储或 Portal API 部署配置了三个正在运行的 Pod，则必须使用与部署期间指定规范等效的规范来提供和配置其他三个 PV。
升级完成后，Portal API 或队列存储部署将使用新配置的永久卷和永久卷声明，并且可以移除原始设置。
按照下表中的内容进行升级时，需要为对象存储部署配置额外的静态 PV：
| 部署类型 | 默认静态对象卷 PV | 升级所需的额外静态 PV |
|---|---|---|
开发配置文件 | 1 | 创建 1 个额外 PV |
标准可用性配置文件 | 3 | 创建 3 个额外 PV |
增强可用性配置文件 | 8 | 创建 8 个额外 PV |