Organizations may have specific requirements for the handling of client traffic routed to an ArcGIS Enterprise on Kubernetes deployment. These requirements may necessitate the use of advanced features offered by provider-specific load balancing solutions that operate at layer 7 (L7) of the OSI model, such as Web Application Firewall capabilities, path- and host-based routing, or other deterministic routing behavior based on client request headers.
As an administrator, you can use a cluster-level ingress controller to route incoming traffic to your ArcGIS Enterprise on Kubernetes deployment. Ingress controllers translate Kubernetes Ingress objects to functional routing rules on the respective L7 load balancer implementations. The specification within an Ingress object contains a set of routing rules to one or more back-end service objects within a Kubernetes namespace.
These Ingress objects are ultimately actualized through layer 7-aware load balancers on managed cloud providers such as Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS), and Google Kubernetes Engine. The creation of Ingress objects with specific annotations and ingressClass names can trigger the provisioning and configuration of the load balancers including the front-end and back-end listeners and target group settings. These cluster-level ingress controllers handle the routing of traffic from the edge of a cluster to the internally exposed services.
For details on how a cluster-level ingress controller can be used to route traffic to an ArcGIS Enterprise on Kubernetes deployment on different platforms, see the following:
- Use application load balancing on EKS
- Use the Application Gateway Ingress Controller on AKS
- Use GKE Ingress for Application Load Balancers
General and platform-specific Ingress YAML data is provided that will allow for the initial deployment and configuration of layer 7 load balancers through the creation of Kubernetes Ingress objects. Ingress YAML data is provided in the documentation and as templates in the layer-7-templates folder. You can further configure these Ingress objects to suit organizational needs by providing additional Ingress object annotations. Annotations to the existing in-cluster NGINX ingress controller service can also be made when needed, and instructions on how to perform these annotations are provided.
Note:
Some providers may require the arcgis-ingress-controller deployment to be refreshed to make a proper connection through the newly created Ingress. If you receive an error when accessing ArcGIS Enterprise Manager after creating the Ingress, try running the following:
kubectl rollout restart deployment/arcgis-ingress-controller -n <deploymentNamespace>
General ingress requirements
If you use an ingress controller on a platform that has not been specified in this document, consider the following general requirements:
- Ensure that the in-cluster arcgis-ingress-nginx service is used as the back-end target to which client traffic will be routed when configuring the Ingress object to route traffic to an ArcGIS Enterprise on Kubernetes deployment.
- Ensure that the TLS protocol is used when passing traffic from the load balancer that is managed by the ingress controller to the back-end in-cluster NGINX ingress controller.
- The id: custom ingress resource label is required and should not be deleted. It is used by the deployment script to manage the Ingress object during deployment and undeployment.
The following is a generalized example of an Ingress YAML that is not provider-specific and contains the necessary values to route traffic to an ArcGIS Enterprise on Kubernetes deployment:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: arcgis-enterprise-ingress
namespace: <deploymentNamespace>
annotations:
labels:
id: custom-ingress-resource
spec:
tls:
- hosts:
- <deploymentFQDN>
secretName: <tlsSecretName>
rules:
- host: <deploymentFQDN>
http:
paths:
- backend:
service:
name: arcgis-ingress-nginx
port:
number: 443
path: /<context>
pathType: Prefix
Note:
The above example assumes that a TLS secret containing certificate information has been created within the deployment namespace and will be used for configuring a TLS certificate with the ingress controller. Some providers allow for this information to be specified through an annotation, which can also be used.
Deployment requirements
When initially deploying ArcGIS Enterprise on Kubernetes, you must indicate that you want to use a cluster-level ingress controller to route traffic to your deployment. How you do this will depend on which mode you run the deployment script:
- If running the script in silent mode, set INGRESS_SERVICE_USE_CLUSTER_IP=true within your deploy.properties file. This property will override any value that is set for the INGRESS_TYPE parameter. If you are choosing to create the Ingress object while running the deployment script, set CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME to the location of the Ingress YAML file. Creating the Ingress object while running the deployment script is only supported for AWS Application Load Balancer, Azure Application Gateway, and Google Cloud Platform Application Load Balancer.
- If running the script in interactive mode, answer no when asked if you want to provision a cloud balancer, and then yes when asked if you will use a cluster-level ingress controller to route traffic to your deployment. This will allow for the in-cluster NGINX ingress controller service, which allows for proper routing of client traffic to requested ArcGIS Enterprise endpoints, to be created as type ClusterIP.
The layer 7 load balancer will serve as the point of access for client traffic to the services within the cluster. For ArcGIS Enterprise on Kubernetes, the cluster-level ingress controller should be configured to pass traffic to the embedded ingress controller deployed as part of the application.
Note:
Prior to ArcGIS Enterprise 11.2, the ability to create an in-cluster ingress controller service as type ClusterIP was provided through the option to specify whether an OpenShift Route would be used to route traffic to the deployment. This question has been changed within the deployment script to ask whether a cluster-level ingress controller will be used to route traffic to the deployment. If this option is set to true, the ingress controller service will be created as type ClusterIP regardless of whether the INGRESS_TYPE for the deployment has been set to NodePort or LoadBalancer.