在部署 ArcGIS Enterprise on Kubernetes 之前,查看以下关于准备集群的指导。
命名空间
ArcGIS Enterprise on Kubernetes 需要自己专有的命名空间。 必须在运行部署脚本之前创建命名空间。 在单个集群中运行多个 ArcGIS Enterprise on Kubernetes 部署需要每个部署具有唯一的命名空间。
资源配额
ArcGIS Enterprise on Kubernetes Pod 具有已定义的 CPU 和内存的请求和限制。 如果命名空间包含 ResourceQuota 对象,则配额必须高于所有 Pod 的请求和限制的总和。 这些值将根据您选择的架构配置文件而有所不同,如下所述。
注:
如果要升级到 11.1,则必须首先将命名空间中的资源配额值更新为符合 11.1 要求。
以下建议值是每个架构配置文件的最低要求。 请考虑您可能需要增加这些值以适应组织的可伸缩性要求。
增强可用性配置文件:
spec:
hard:
limits.cpu: "230"
limits.memory: 394Gi
requests.cpu: "36"
requests.memory: 188Gi
标准可用性配置文件:
spec:
hard:
limits.cpu: "198"
limits.memory: 326Gi
requests.cpu: "32"
requests.memory: 130Gi
开发配置文件:
spec:
hard:
limits.cpu: "144"
limits.memory: 226Gi
requests.cpu: "20"
requests.memory: 86Gi
命名空间网络要求
如果使用 Kubernetes NetworkPolicies,请确保在 ArcGIS Enterprise 命名空间中允许不间断的 Pod 到 Pod 和 Pod 到服务的通信。
此外,确保命名空间中的 Pod 有权访问 Kubernetes API 服务器。 可通过默认命名空间中名为 Kubernetes 的服务访问 API 服务器。 ArcGIS Enterprise Pod 使用完全限定域名 (FQDN) kubernetes.default.svc.cluster.local 查询 API 服务器。
注:
cluter.local 是集群的默认域。
Pod 安全策略
注:
在 Kubernetes v1.25 中已移除 PodSecurityPolicy。
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
- default
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: 117932853 max: 117932853 fsGroup: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 117932853 max: 117932853
注:
必须允许集群中的 Pod 使用 FSGroup 和 SupplementalGroup ID 117932853 运行。
Pod 安全性标准
Pod 安全性标准是一个 Kubernetes 功能,允许管理员在 Pod 在集群内部调度之前对其实施一套安全性规则。 默认情况下,有三种级别:特权、基线和受限。 这些标准的警告和实施按照命名空间进行控制。
设置基线或受限实施级别时,如果 Pod 不符合这些级别的安全性要求,则不允许该 Pod 运行。 有关各个级别的详细信息,请参阅以下内容:
- 特权 - 特权是不受限制的 Pod 安全性标准,提供大量权限不受限制的访问权限。 ArcGIS Enterprise 可在此级别下运行,无需任何配置修改。 此级别允许集群内部已知的权限提升,因此不建议在此级别运行。
- 基线 - 基线是更受限制的 Pod 安全性标准,此级别阻止 Pod 访问主机文件系统,并且存在对功能和其他卷类型的限制。 通过修改运行的应用程序上下文外部的基础工作节点,并于部署之前在部署属性文件中将 ArcGIS Enterprise 属性设置为 false,ALLOW_PRIVILEGED_CONTAINERS 即可在基线实施级别下运行。
为了匹配工作节点组的灵活性,管理员必须使用脚本化进程,通过直接修改启动模板的方式,在每个新配置的节点上将 vm.max_map_count 设置增加到 262144。
- 受限 - 受限 Pod 安全性标准对 Pod 安全性施加最严格的限制,此标准需要显式配置大多数 securityContext 属性。 在此版本中,ArcGIS Enterprise 无法在受限级别运行。
指标服务器
要在 ArcGIS Enterprise on Kubernetes 中应用 水平 Pod 自动扩缩,需要使用指标服务器从每个运行节点上的 kubelet 收集 Pod 资源消耗指标。 有关详细信息,请参阅 Kubernetes Metrics Server。