Cluster-level ingress controllers—ArcGIS Enterprise on Kubernetes

Organizations may have specific requirements for the handling of client traffic that is 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. These cluster-level ingress controllers allow organizations to take advantage of these features. Ingress controllers translate Kubernetes Ingress objects to functional routing rules on the respective L7 load balancer implementations. The spec within an Ingress object contains a set of routing rules to one or more backend 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 deployment, see the following:

For each deployment platform, 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. You can add more configuration to these Ingress objects to suit organizational objectives, such as the application of 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>

Prerequisites

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, you will need to 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 running the script in interactive mode, you will need to answer no when asked if you would like 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.

General ingress requirements

You can use an ingress controller on a platform that has not been specified in this document. To do so, the general prerequisites outlined above also apply. Also consider the following:

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 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:

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.

Feedback on this topic?