Review the following guidance on preparing your cluster before deploying ArcGIS Enterprise on Kubernetes.
Namespace
ArcGIS Enterprise on Kubernetes requires its own dedicated namespace. The namespace must be created before running the deployment script. Running multiple deployments of ArcGIS Enterprise on Kubernetes in a single cluster will require a unique namespace for each deployment.
Resource quota
Note:
If you are performing an upgrade to 11.4, you must first update the resource quota values in the namespace to the 11.4 requirements.
ArcGIS Enterprise on Kubernetes pods have defined requests and limits for CPU and memory. If the namespace has a ResourceQuota object, the quota must be higher than the sum of all the pods' requests and limits. These values vary based on the architecture profile you've selected, as described below.
Note:
If you are licensing your organization with premium capabilities, you must increase the resource quota values below with an additional 10 percent to support the added capabilities.
The following recommended values are the minimum requirements for each architecture profile. Consider that you may need to increase these values to accommodate your organization's scalability requirements.
Enhanced availability profile:
spec:
hard:
limits.cpu: "253"
limits.memory: 434Gi
requests.cpu: "36"
requests.memory: 188Gi
Standard availability profile:
spec:
hard:
limits.cpu: "218"
limits.memory: 359Gi
requests.cpu: "32"
requests.memory: 130Gi
Development profile:
spec:
hard:
limits.cpu: "158"
limits.memory: 274Gi
requests.cpu: "20"
requests.memory: 95Gi
Namespace network requirements
If you use Kubernetes NetworkPolicies, ensure that uninterrupted pod-to-pod and pod-to-service communication is allowed in the ArcGIS Enterprise namespace.
Additionally, ensure that the pods in the namespace have access to the Kubernetes API server. The API server is accessible through a service named Kubernetes in the default namespace. ArcGIS Enterprise pods use the fully qualified domain name (FQDN) kubernetes.default.svc.cluster.local to query the API server.
Note:
cluster.local is the default domain suffix of the Kubernetes cluster, but it may be different in other environments.
Pod Security Standards
Pod Security Standards are a Kubernetes feature that allows administrators to enforce a set of security rules for pods before they are scheduled within the cluster. There are three levels available by default: privileged, baseline, and restricted. The warning and enforcement of these standards is controlled per namespace.
When either the baseline or restricted enforcement levels are set, pods that don't meet the security requirements for these levels will not be allowed to run. To learn more about each level, see the following:
- Privileged—Privileged is an unrestricted pod security standard that allows unrestricted access to a wide range of permissions. ArcGIS Enterprise can run under this level without any configuration modification. This level allows for known privilege escalations within the cluster, so running at this level is discouraged.
- Baseline—Baseline is a more limited pod security standard that prevents host filesystem access from the pods and has restrictions on types of other volumes and capabilities. ArcGIS Enterprise can run under the baseline enforcement level by modifying the underlying worker nodes outside of the context of the running application and setting the ALLOW_PRIVILEGED_CONTAINERS property to false in the deployment properties file prior to deployment.
To match the elasticity of the worker node groups, an administrator must use an automated process to increase the vm.max_map_count setting to 262144 on any existing and newly provisioned node. This can be achieved by modifying the underlying node image used to provision nodes, by applying the changes through a configuration script as part of bootstrapping, or through a daemonset running in a privileged security context.
- Restricted—The restricted pod security standard offers the most stringent limitations on pod security and requires a majority of securityContext properties to be set explicitly. The required properties are included for all ArcGIS Enterprise workloads.
As with the baseline standard, to match the elasticity of the worker node groups, an administrator must use an automated process to increase the vm.max_map_count setting to 262144 on any existing and newly provisioned node. This can be achieved by modifying the underlying node image used to provision nodes, by applying the changes through a configuration script as part of bootstrapping, or through a daemonset running in a privileged security context.
When enforcing the restricted pod security standard, registration of folder data stores is limited to PV-based volumes. For more information, see Manage folder data stores.
For more information, see Pod Security Admission and Pod Security Standards.
Metrics server
To take advantage of horizontal pod autoscaling in ArcGIS Enterprise on Kubernetes, the metrics server is required to scrape pod resource consumption metrics from the kubelet process on each running node. For more information, see Kubernetes Metrics Server.