The following isn’t intended to be complete documentation for provisioning a managed Amazon EKS cluster. Rather, we provide links here to appropriate documentation to get you started, and provide details for how to enable ingress on an existing cluster so as to allow the appropriate network access for Constellation Distributed Serving.
This feature (and its associated documentation) is currently in beta.
This feature is only available in Algorithmia Enterprise installations.
Table of contents
- Table of contents
- Creating an Amazon EKS cluster
- Connecting to an Amazon EKS cluster
- Enabling ingress to an Amazon EKS cluster
Creating an Amazon EKS cluster
For guidance on getting set up with a managed Kubernetes cluster on AWS, see the EKS Quickstart Deployment Guide.
AWS supports multiple Kubernetes deployment options depending on what sort of existing infrastructure you’re working with, and provides the following CloudFormation templates for these various deployment scenarios:
- Deploy Amazon EKS into a new VPC
- Deploy Amazon EKS into an existing VPC
- Enable EKS based Quick Starts on an existing EKS cluster
In order to use any of these CloudFormation stacks, you must use a role that itself has permissions to assign permissions and create other roles. Each CloudFormation stack will create a role
eks-quickstart-ManagedNodeInstance that will be assumed by the role administering the EKS cluster.
The role used needs to be modified to include additional permissions in order for ingress and application load balancing to be configured correctly. The IAM service’s AdministratorAccess managed policy provides the sufficient permissions, but you can also use a custom policy with more restrictions if desired. At minimum, the role must have the following two policies attached:
In this guide, we’ll walk through the workflow for deploying an EKS cluster into a new VPC. The region in which you deploy your EKS cluster references below as
REGION, and your AWS account number references as
To begin, navigate to the link above, which automatically includes the link to the appropriate CloudFormation YAML template, and click Next.
Provide a Stack name to label this bundle of resources in your account.
Under Basic configuration:
- Specify the desired Availability Zones to use for VPC subnets; note that this must match the value of Number of Availability Zones further down the page.
- Optionally, provide an allowed allowed CIDR IP range in the Allowed external access CIDR field.
- Specify the SSH key name for the key you’ll be using to connect to the cluster once it’s provisioned.
Under Amazon EC2 configuration, select Disabled to skip provisioning a bastion host.
Under Amazon EKS configuration:
- Provide an EKS cluster name (this references in the code samples below as
- Set EKS public access endpoint to Enabled to allow EKS API server access from outside of your VPC.
- Optionally, specify Additional EKS admin ARNs to grant EKS cluster management privileges to an additional user and/or role.
Under Default EKS node group configuration:
- Specify the node Instance type.
- Optionally, change Number of nodes and Maximum number of nodes if non-default values are desired.
Under Calico policy, select Enabled for Calico policy integration.
Click Next. On the Configure stack options page, optionally select a specific IAM role for CloudFormation to use to take actions on stack resources. If left blank, the current user’s credentials will be used.
Click Next. Check the appropriate boxes to allow CloudFormation to create resources, and click Create stack.
Once the stack is created, generate the
kubeconfig file by setting AWS credential environment variables for one of the authorized admin roles (the role that created the stack or the one provided in the optional field above) and running the following:
$ aws eks --region REGION update-kubeconfig --name CLUSTER_NAME
Create an Elastic Container Registry (ECR) with all repositories required for the satellite. You’ll get the
SATELLITE_ID value from the Algorithmia side; see the Satellite deployment section of the Constellation Distributed Serving documentation.
$ aws ecr create-repository --repository-name ECR_NAME/satellite-SATELLITE_ID \ --image-scanning-configuration scanOnPush=false --region REGION $ aws ecr create-repository --repository-name ECR_NAME/rabbitmq \ --image-scanning-configuration scanOnPush=false --region REGION $ aws ecr create-repository --repository-name ECR_NAME/codex-install \ --image-scanning-configuration scanOnPush=false --region REGION $ aws ecr create-repository --repository-name ECR_NAME/execution-engine \ --image-scanning-configuration scanOnPush=false --region REGION $ aws ecr create-repository --repository-name ECR_NAME/algorithm-queue-reader \ --image-scanning-configuration scanOnPush=false --region REGION
Log in to the ECR.
$ aws ecr get-login-password --region REGION \ | docker login --username AWS_ACCOUNT_ID --password-stdin \ AWS_ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com
Note that if you need to modify administrative permissions on the EKS cluster after it’s provisioned, you can add a cluster administrator by modifying the
aws-auth configmap as follows:
- groups: - system:masters rolearn: arn:aws:iam::AWS_ACCOUNT_ID:role/USER_ARN username: arn:aws:iam::AWS_ACCOUNT_ID:role/USER_ARN
Connecting to an Amazon EKS cluster
Once you’ve provisioned your EKS cluster using the quickstart guide linked above, you can connect to it to Test the Deployment.
Enabling ingress to an Amazon EKS cluster
EKS has some built-in integrations with application load balancing and network load balancing. For the Ingress Kubernetes resource, you can work with application load balancing on EKS. When an
Ingress resource is deployed, an application load balancer (ALB) will automatically be created and target groups should be assigned. In the EC2 management console under Load Balancing, the ALB should be listed under Load Balancers and the target groups should be listed under Target Groups.
In order to have these resources generated automatically, the
Ingress resource needs to have the following specific annotations:
annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip kubernetes.io/ingress.class: alb
Note that the asterisk (
* ) isn’t permitted in the
PathPrefix path-matching pattern:
rules: - http: paths: - backend: serviceName: execution-engine servicePort: 80 path: /v1/algo/ pathType: Prefix
If configured correctly, the
Ingress resource should have an address defined:
$ kubectl get ingress -n algo execution-engine NAME CLASS HOSTS ADDRESS PORTS AGE execution-engine <none> * k8s-algo-executio-3b5a580f3b-4934167255.us-east-2.elb.amazonaws.com 80 21h
Ingress path-matching patterns
Note that tor AKS, the
PathPrefix ingress type isn’t a regular expression but rather complies with the following patterns:
/v1/algo/*will forward any
/v1/algo/.*will match the literal route