在此版本上运行 ArcGIS Enterprise on Kubernetes 11.1 所需的最低硬件和基础架构如下所述。 在离线环境中进行部署时，上述要求同样适用。
支持的环境
如无特殊说明，系统要求和规范适用于所有受支持的环境。 对于此版本，支持以下环境：
- 内部部署数据中心
- Red Hat OpenShift Container Platform
- 云端的托管 Kubernetes 服务
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Microsoft Azure Kubernetes Service (AKS)
我们强烈建议您在 Kubernetes 集群中禁用自动升级。 当您的集群启用自动升级后，节点将自动更新为 Kubernetes 的最新版本，而对于 ArcGIS Enterprise 而言可能尚不支持这些未来的版本。
警告：
当升级环境时，您必须先升级 ArcGIS Enterprise on Kubernetes，然后再将 Kubernetes 升级到受支持的版本。每个环境的以下版本均已经过测试并受系统支持：
| 支持的环境 | 受支持的 Kubernetes 版本 |
|---|---|
云端的托管 Kubernetes 服务（AKS、EKS、GKE） | 1.23 - 1.25 |
| Red Hat OpenShift Container Platform | 4.10 - 4.12 |
注：
ArcGIS Enterprise on Kubernetes 仅在采用 x86_64 架构（64 位）的 CPU 上受支持。 工作节点必须基于 Linux。
容器注册表
您可以从私有 Docker Hub 组织访问 ArcGIS Enterprise on Kubernetes 的容器镜像。 Esri 将为正在部署 ArcGIS Enterprise on Kubernetes 的人员提供对此组织资料档案库的访问权限。 在离线环境中进行部署时，您将需要将镜像从私有 Docker Hub 组织推送到可通过集群访问的组织的容器注册表。
获取 Esri 许可
要在部署过程中授权 ArcGIS Enterprise 组织，您需要 JSON 格式的 ArcGIS Enterprise on Kubernetes 许可文件（.json 文件）。 要获得此许可文件，请通过采取许可操作的权限访问 My Esri。
CPU 和内存
ArcGIS Enterprise on Kubernetes 与三个架构配置文件之一一起部署。 关于资源（CPU 和内存）请求和限制以及整体计算要求的建议会根据所选配置文件而有所不同。 下面提供了对每个配置文件的建议。
以下是每个架构配置文件的最低节点要求。 建议每个工作/代理节点至少具有 8 个 CPU 和 32 GiB 的内存。
| 架构配置文件 | 最低工作/代理节点 | 最低 CPU 总数 | 最低 GiB 总数 |
|---|---|---|---|
增强可用性 | 5 | 40 | 160 |
标准可用性 | 4 | 32 | 128 |
开发 | 3 | 24 | 96 |
ArcGIS Enterprise on Kubernetes 部署中的 Pod 分布在集群中的所有工作节点上。 在扩展部署或将其他 ArcGIS Enterprise 部署添加到集群中时，您需要相应地配置硬件。 这可能需要增加每个节点的默认最大 Pod 数。 最初创建的 Pod 的数量随每个架构配置文件而变化。 当您水平扩缩或添加新功能时，Pod 的数量会增加。
安全性
ArcGIS Enterprise on Kubernetes 的安全要求如下所述。
基于角色的访问控制
必须在 Kubernetes 集群上启用基于角色的访问控制 (RBAC)。 您无需 cluster-admin 权限即可部署 ArcGIS Enterprise on Kubernetes。 如果您没有 cluster-admin 权限，则用户必须拥有最小命名空间管理权限。 您可以通过在命名空间中创建 RoleBinding 来为用户分配默认 ClusterRole。
注册数据文件夹
要使用基于文件的数据发布项目（例如从文件地理数据库发布的项目），您需要将数据放置在 NFS 共享的位置。 必须将此 NFS 共享注册到 ArcGIS Enterprise 组织，以免在发布时将数据复制到服务器。 要成功注册共享文件夹，您需要向其他人授予文件级别读取权限。 您可以通过允许网络访问 Pod IP 范围来保护网络或基础架构级别的 NFS 共享。
网络
网络要求包括 FQDN 和负载均衡器。 下面提供了每一项的详细信息。
完全限定域名
ArcGIS Enterprise on Kubernetes 需要 FQDN（例如 map.company.com）。 您可以使用现有域名系统 (DNS) 创建域名，也可以使用 Cloud DNS 服务（例如 Amazon Route 53）。 您可以在部署后创建 DNS 记录，但是在部署期间必须提供其值。 在此版本中，您在部署后无法修改 FQDN。
负载均衡器
您需要使用负载均衡器将流量引入每个工作节点。 可以从部署脚本配置以下负载均衡器，而无需进行手动配置：
- Azure 负载均衡器（公共或内部）- 可以在部署脚本中指定预配置的静态公共 IP 地址和 DNS 标注。
- AWS 网络负载均衡器（面向 Internet 或内部）- 可以使用其他负载均衡服务；但是，必须在每个集群节点上手动对其进行配置。
注：
在公共子网或私有子网中创建网络负载均衡器需要用到 AWS 负载均衡器控制器加载项。
- Google Cloud Platform TCP 负载均衡器（面向 Internet 或内部）- 可以在部署脚本中指定一个预配置的静态公共 IP 地址。
在 OpenShift 容器平台中，可以在指向入口控制器服务时配置路径。
您可以使用自我管理的负载均衡器，该负载均衡器指向入口控制器服务的 NodePort 上的工作节点。 有关详细信息，请参阅负载均衡器的部署指南的参数描述。
使用自我管理负载均衡器或反向代理（如 NGINX）时，请指定以下连接：proxy_set_header X-Forwarded-Host $host;。 要确保将流量正确路由到您 ArcGIS Enterprise 组织的 URL，需要使用此标题。
注：
ArcGIS Enterprise 不支持通过反向代理/负载均衡器进行 SSL 卸载。 如果您的配置使用反向代理，则其必须重定向到 ArcGIS Web Adaptor 或通过 HTTPS 直接重定向到组织。
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)，永久卷可通过存储类动态配置，或由管理员在创建组织之前静态配置。 ArcGIS Enterprise 的有状态的工作负载包括关系数据库管理系统和 NoSQL 数据库。 建议您将 PV 配置于低延迟的块存储设备上，例如 EBS 卷（使用 EKS 时）、Azure 磁盘（使用 AKS 时）、永久性磁盘（使用 GKE 时）及 vSphereVolume 或 Longhorn 卷（进行本地部署时）。
由于这些 PV 用于存储组织的数据和设置，因此您必须使用限制性安全策略为其提供保护。 对于基于网络文件存储（例如 NFS、Azure 文件和 GlusterFS）的 PV，请确保设置权限以防止未经授权的访问。 对于块存储（例如 EBS、Azure 磁盘、vSphereVolume 和 Longhorn 卷），请确保存储卷的访问权限仅提供给需要的用户。
以下是存储卷及其预期用途的说明：
注：
永久卷要求针对 11.1，可能与之前的版本有所不同。
- 内存中 - 存储临时系统资源。
- 项目包 - 存储大型上传文件和文件包，以支持发布工作流。
- 对象 - 存储已上传和保存的内容、托管切片和图像图层缓存以及地理处理输出。
- 队列 - 存储异步地理处理作业。
- 关系 - 存储托管要素数据和管理内容（例如自定义和配置设置）。 部署需要两项内容。
- 时空大数据和索引 - 存储日志和索引以及托管要素数据。
- 使用度量数据 - 存储 GIS 服务使用情况数据。
考虑组织的存储要求，并相应地定义每个 PV 的大小。
静态 PV
如果要在部署之前配置静态 PV，则建议使用下述规范和标注。
提供了每个架构配置文件所需的 PV 数量。
| 体积 | 增强可用性配置文件 | 标准可用性配置文件 | 开发配置文件 |
|---|---|---|---|
in-memory-volume | 1 | 1 | 1 |
item-packages-volume | 2 | 2 | 1 |
object-volume | 8 | 3 | 1 |
queue-volume | 2 | 2 | 1 |
relational-volume | 2 | 2 | 2 |
spatiotemporal-and-index-volume | 5 | 3 | 1 |
usage-metric-volume | 1 | 1 | 1 |
如果要将组织配置为使用现有静态 PV，则会使用各个永久卷声明 (PVC) 的以下值通过标签选择将其绑定到 PV：大小、访问模式和标签。 可以在设置向导或配置属性文件中自定义这些值，以使预配置 PV 与各个有状态集的规范相匹配。
| 体积 | 大小 (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 参数设置为 Delete 以简化管理。 此设置可在 PVC 被删除时（例如在您取消软件部署时）清理关联的 PV。
应为托管备份存储配置使用单独的 StorageClass，并将其 reclaimPolicy 参数设置为 Retain，这样，即会在您取消部署和重新部署时保留 PV。
如果您的存储提供者支持 PV 扩展，则可以将 StorageClass 上的 allowVolumeExpansion 参数设置为 true。
注：
并非所有的 VM 类型都支持 Azure 中的高级磁盘。 VM 类型支持高级磁盘时，请使用高级磁盘。- 对于 AKS，StorageClass 定义（高级 Azure 磁盘）的示例如下所示：
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: arcgis-storage-default provisioner: disk.csi.azure.com parameters: kind: Managed storageaccounttype: Premium_LRS reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer - 对于 EKS，StorageClass 定义（GP3 类型 EBS 卷）的示例如下所示：
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: arcgis-storage-default provisioner: ebs.csi.aws.com parameters: fsType: ext4 type: gp3 reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer - 对于 GKE，StorageClass 定义（SSD 永久性磁盘）的示例如下所示：
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: arcgis-storage-default provisioner: pd.csi.storage.gke.io parameters: type: pd-ssd reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true
您也可以使用随 EKS (GP2)、AKS（托管或托管高级）或 GKE（永久性磁盘）集群提供的默认存储类，但可能需要安装 CSI 驱动程序以支持在 Kubernetes 1.23 版本或更高版本中的配置。 在创建组织之前，您必须确认 reclaimPolicy 和 allowVolumeExpansion 属性满足您的需求。
客户端工作站
部署脚本为 bash 脚本，其可从远程客户端工作站运行。 运行脚本的用户必须对脚本具有读取和写入权限，才能将临时资源文件写入子目录。
注：
由于已知的兼容性问题，Linux 仿真器不支持用于部署 ArcGIS Enterprise on Kubernetes。
设置客户端工作站时，需要以下内容（已提供下载链接）：
- Kubectl
- 特定于环境的命令行界面 (CLI)
Kubectl 是运行部署脚本的先决条件。 使用 Kubectl 安装和设置来下载 Kubernetes 命令行工具。
注：
kubectl 客户端版本和 Kubernetes 服务器版本之间相差不得超过一个小版本。 例如，kubectl 1.24 与 Kubernetes 集群版本 1.23-1.25 兼容。
在管理部署时，您可以使用特定于环境的命令行工具。 使用以下链接下载特定于环境的 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.1 是 ArcGIS Enterprise on Kubernetes 11.1 的配套版本。 要从可用的最新功能中获益，请使用 ArcGIS Pro 3.1。
- 要将服务发布到 ArcGIS Enterprise on Kubernetes，需要使用 ArcGIS Pro 2.8 或更高版本。
- 要使用 ArcGIS Enterprise on Kubernetes 中的服务，需要使用 ArcGIS Pro 2.7 或更高版本。
从企业级地理数据库中注册数据存储项时，地理数据库版本必须为 10.9.0.2.8 或更高版本。
注：
要从可用的最新功能中获益，请将您的地理数据库版本升级到 11.1.0.3.1。地理数据库版本号是 ArcGIS Enterprise 和 ArcGIS Pro 版本号的组合。 有关详细信息，请查看客户端与地理数据库的兼容性。
升级和更新要求
在执行升级之前，您必须满足几个要求，例如：
- 当升级环境时，您必须先升级 ArcGIS Enterprise on Kubernetes，然后再将 Kubernetes 升级到受支持的版本。
- 如果存在可用的必要更新，则您必须在升级到此版本之前应用此更新。 查看发布说明以了解有关最新必要更新的详细信息。
- 您必须拥有此版本的统一 ArcGIS Enterprise on Kubernetes 许可。
- 您必须更新命名空间中的资源配额值以满足当前要求。
- 在进行升级之前，请确保您的环境符合 Pod 安全性标准，例如 Pod 安全性准入标准。
- 如果您的环境位于 Red Hat OpenShift Container Platform 中，请确保其满足当前的安全上下文限制。
- 如果您已配置静态 PV，则必须配置额外的存储以满足升级要求。 有关更多详细信息，请参阅调整用于升级的静态 PV 部分。
- 如果您的已配置存储具有动态 PV，则您需要确保有足够的存储空间可用于存储额外的项目包、对象卷和队列卷。
- 运行预升级脚本。 该脚本将检测和处理一切功能需求，以满足当前软件版本的要求。
- 如果您已为您的组织配置了 Web Adaptor，请查看安装和升级要求。
- 如果您的组织处于离线环境中，则请按照步骤在离线环境中应用升级或更新。
- 如果您在部署 ArcGIS Enterprise on Kubernetes 时使用您的组织的容器注册表，则在运行更新或升级之前必须将所需的容器镜像从 Esri 资料档案库复制到组织的注册表。
调整用于升级的静态 PV
在升级之前，已为组织的 Portal API 部署中的每个 Pod 配置一个项目包卷 PV。 在准备升级时，必须为 Portal API 部署中的每个 Pod 配置一个额外 PV。
例如，在升级之前，如果 Portal API 部署配置了三个正在运行的 Pod，则必须使用与部署期间的指定规范等效的规范来提供和配置另外三个 PV。
升级完成后，Portal API 部署将使用新配置的永久卷和永久卷声明，并且可以移除原始设置。