Use application load balancing on Amazon Elastic Kubernetes Service—ArcGIS Enterprise on Kubernetes

A cluster-level ingress controller can be used to route traffic to an ArcGIS Enterprise deployment on Amazon Elastic Kubernetes Service (EKS). For more information, see Cluster-level ingress controllers.

Note:

This workflow should be performed prior to creating an ArcGIS Enterprise organization. ArcGIS Enterprise Manager can be accessed from a browser once a load balancer has been deployed and configured.

Prerequisites

Review the general prerequisites and ensure the following EKS-specific prerequisites are met:

You must have prepared a Kubernetes cluster in Amazon EKS, including deploying the AWS Load Balancer Controller.
The AWS CLI must be installed on your client machine. Ensure that you can authenticate from the CLI to the account in which your EKS cluster exists.
Kubectl must be installed on your client machine. Ensure that you can connect and issue commands to the Kubernetes API Server that is associated with the cluster you have created.
Your EKS cluster, VPC, and associated resources meet the requirements outlined in Application load balancing on Amazon EKS.
You must have a TLS certificate. You can use Amazon Certificate Manager (ACM) to create or import this certificate.

Implement a cluster-level ingress controller

To implement a cluster-level ingress controller to route traffic to an ArcGIS Enterprise deployment on Amazon EKS, complete the following steps:

Retrieve the Amazon Resource Name (ARN) that is associated with your ACM certificate using one of the methods outlined in the AWS documentation.

Open the template included in the layer-7-templates folder or copy the following example to a file on your client machine:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: <deploymentNamespace>
  name: arcgis-enterprise-ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/backend-protocol: HTTPS
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    alb.ingress.kubernetes.io/healthcheck-port: '443'
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTPS
    alb.ingress.kubernetes.io/healthcheck-path: /<context>/admin
    alb.ingress.kubernetes.io/success-codes: '200-399'
    alb.ingress.kubernetes.io/certificate-arn: <ACMCertificateARN>
    alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=600
    #alb.ingress.kubernetes.io/inbound-cidrs: <inboundCIDRRange>
    #alb.ingress.kubernetes.io/security-groups: <securityGroupID1>,<securityGroupID2>
  labels:
    id: custom-ingress-resource
spec:
  ingressClassName: alb
  rules:
  - host: <deploymentFQDN>
    http:
      paths:
      - path: /<context>
        pathType: Prefix
        backend:
          service:
            name: arcgis-ingress-nginx
            port:
              number: 443

For more information on some of the annotations, see the Annotation descriptions section below.

Replace the following values:
- alb.ingress.kubernetes.io/certificate-arn—Provide the Amazon Resource Name retrieved in step 1.
- alb.ingress.kubernetes.io/inbound-cidrs—If you want to allow inbound traffic from specific CIDR IP address ranges, uncomment this line and provide the range. If security groups are specified in the alb.ingress.kubernetes.io/security-groups annotation, this annotation is ignored.
- alb.ingress.kubernetes.io/security-groups—If you want to attach existing security groups to your Application Load Balancer, uncomment this line and provide security group IDs.
- namespace—Provide the namespace in which you have deployed ArcGIS Enterprise on Kubernetes.
- deploymentFQDN—Provide the fully qualified domain name that was specified during the initial deployment.
- context—Provide the context that was specified during deployment.
  Note:
  This value appears twice and should be replaced in both instances. Ensure that you update the value within the alb.ingress.kubernetes.io/healthcheck-path annotation.
Save the file to your client workstation.
For example, ingress.yaml.
Create the Ingress object by doing one of the following:
- Apply Ingress YAML data to your cluster using the following command:
  kubectl apply -f ingress.yaml
- When running the deployment script silently, set CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME to the location of the Ingress YAML file.

Once you complete this workflow, an Ingress object called arcgis-enterprise-ingress is created. If this is the first time that you are using an ingress controller to manage external access to your EKS cluster, you should see an Application Load Balancer that is in the provisioning state within the AWS account that you are currently working in. The AWS Load Balancer Controller will provision this Application Load Balancer and ancillary components according to the YAML data that was applied to the namespace. Once the load balancer has entered the active state, the ArcGIS Enterprise deployment should be accessible, and a CNAME DNS record can be created that directs clients from the fully qualified domain name that was specified during the initial deployment to the provisioned load balancer.

Note:

The arcgis-ingress-controller deployment may need 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>

Annotation descriptions

For more information on some of the annotations, see the following:

alb.ingress.kubernetes.io/scheme: internet-facing—This will create an Application Load Balancer that is accessible over the internet. To expose the ALB only from within your VPC, you can alternatively use the annotation alb.ingress.kubernetes.io/scheme: internal.
alb.ingress.kubernetes.io/target-type: ip—This annotation will allow for traffic to be load balanced to back-end pod IP addresses directly.

Feedback on this topic?