The Elastic Kubernetes Service (EKS) is a service provided by Amazon AWS that supports deploying Kubernetes clusters in AWS. EKS has become the default technology when working with AWS + Kubernetes due to its ease of use and its integration features with other AWS services.

Also, since EKS is a certified Kubernetes conformant, any standard Kubernetes application can be easily migrated to EKS without the need of any code refactoring.

In this article we will show how to create a Kubernetes cluster in EKS using the AWS Command Line Interface, and how to deploy a Denodo Kubernetes application in it.

AWS Command Line Interface

The AWS Command Line Interface (AWS CLI) is an open-source tool that can be used for administering the AWS resources and we will use it extensively in the article, we will assume that it is installed and up to date as a prerequisite for executing the commands presented below.

Although it is also possible to manage the EKS resources from the AWS portal, in this article we have chosen to use the AWS CLI because usually, the commands are self-explanatory and also because it is possible to use these commands and test them easily in any custom AWS deployment.

Amazon Elastic Kubernetes Service

The Elastic Kubernetes Service (EKS) eases the management, configuration and daily work of containerized environments in AWS. In other Knowledge Base articles, we explained how to deploy a Denodo container in a local Kubernetes environment and now, we will see how to perform this deployment into a cluster that is hosted in Amazon AWS, making use of the Elastic Kubernetes Service.

Note that all the below statements are AWS CLI commands, so they can be copied into any environment to create a Denodo cluster in AWS.

The Kubernetes deployment is organized in three main parts:

• (Optional) Creation of the container registry: the Kubernetes cluster will use an Elastic Container Registry to obtain the container images. This step can be skipped if using Denodo’s Harbor Registry.
• Creation of the Kubernetes cluster: the cluster will accept the deployment of the Denodo image.
• Deployment of a Virtual DataPort application in the cluster: the last step shows the deployment of the Denodo container image, explaining the implications of doing this in AWS.

List of Prerequisites

This article assumes that there is an environment already configured with the tools required to deploy a Docker image of Denodo in AWS, in other cases, it might be needed to install or configure something else before continuing with the next section. In summary:

• The AWS CLI and a valid AWS account with enough privileges to build all the AWS elements involved in the deployment of a Denodo image.
• If not using the Denodo Harbor Registry a Docker image of Denodo in the local registry is needed.
• Additionally, it will be easier to configure the deployment file if a local Kubernetes environment is created first, with a tested denodo-service.yaml.

AWS Permissions

CLI Role

An IAM entity (user, group or role) must be set up with the necessary privileges required by the AWS CLI for running the statements in this guide.

In this example, we have configured an IAM Role (roleARN) to use ECR, if needed, and EKS services.

If using Elastic Container Registry instead of Denodo Harbor Registry this IAM role must be able to list, push and pull images in the ECR repository, which is granted with the following AWS managed policy:

•  AmazonEC2ContainerRegistryPowerUser.

The AmazonEC2ContainerRegistryPowerUser allows read and write access to repositories, but does not allow other actions such as actually creating the ECR registry. For that, we need to assign the following IAM action to the role:

• ecr:CreateRepository

Also, if the Service Linked Role "AWSServiceRoleForAmazonEKSNodegroup" does not exist, the following IAM actions will be required by that entity in order to create it:

• iam:CreateServiceLinkedRole
• iam:PutRolePolicy

Additionally, the role must be granted with the following permissions over the roles that will be used later for the cluster creation (eksRoleARN) and for nodegroup creation (ec2RoleARN) statements:

• iam:PassRole
• iam:GetRole
• iam:ListAttachedRolePolicies
• ec2:DescribeSubnets

Cluster Role

The Amazon IAM service role for the EKS service (eksRoleARN) that will provide permissions for making calls to other AWS API operation must have the following policies attached:

• AmazonEKSClusterPolicy
• AmazonEKSServicePolicy

Node Role

The IAM service role for the EC2 service (ec2RoleARN) that will be used by the Node Group workers must have the following policies attached:

• AmazonEKSWorkerNodePolicy
• AmazonEC2ContainerRegistryReadOnly

• Note that this is needed even if using Harbor.

• AmazonEKS_CNI_Policy

In addition to the Service Linked Role

• AWSServiceRoleForAmazonEKSNodegroup

AWS Console

The AWS console offers a convenient way to graphically create and manage AWS resources.

Create a Cluster

1. Search for EKS on the search bar or select it under Services.
2. Click on Add Cluster > Create

3. Select the Kubernetes version and Cluster Role created previously. Leave the rest of the configuration.

4. If the cluster needs to belong to any specific VPC configure it on the Specify Network section. You can also select whether the cluster will be Public available or Private.

1. Make sure that the subnets span more than one Availability Zone

5. On the next section you can Configure observability. This is not required but highly recommended for production environments.
6. If any add-ons need to be added do so on Steps 4 and 5. For this article we are leaving everything on default.
7. Review and create the cluster.

Add a Node Group

1. From the Cluster just created click on the Compute tab and Add node group.
2. Provide a name and assign the IAM role created previously for the nodes.

3. On the Set compute and scaling configuration select the configuration you want for your nodes.

1. Select the AMI type you prefer for your cluster.
2. For the Instance types make sure that you provide one that is bigger than the number of cores available by your license. Note that you can still configure autoscaling and high availability (more than one VDP node) but the number of cores per AMI must be within the ranges of your license.
3. For the Node group scaling configuration take into account that Denodo Helm Charts by default deploys each service (VDP, Scheduler, Data Catalog and Design Studio) in one pod. So using the default configuration would need at least 4 pods.

4. On the Specify Networking section select the subnets you want to use for the node group. Make sure that the subnets are configured to assign IPs automatically. If you configured the Cluster to be Public make sure that there is a route to 0.0.0.0/0 through an Internet Gateway as well.
5. Finish and save the configuration

At this point both the Cluster and the Node Group are available. The next steps will be done with the AWS CLI starting from Deploying Denodo Virtual DataPort.

AWS CLI

Configure the AWS CLI

To start with the AWS configuration, open a new console and execute the below AWS commands that will do the basic configuration of the AWS CLI.

Configure the AWS access keys for the AWS account by using the following command:

When entering this command, the AWS CLI prompts for the following information:

• AWS Access Key ID
• AWS Secret Access Key
• Default region name
• Default output format

To read more about the AWS CLI configuration check the AWS CLI user guide.

At this point you need to decide if you will configure the default AWS CLI profile or if you want to create a custom profile. If you create a custom profile some of the commands in the rest of the guide will require an additional parameter to specify the profile to use (--profile profilename) so for simplicity we will just configure the default profile in this guide. You can read more about named profiles in the  AWS Command Line Interface documentation.

Use these commands to configure the IAM role in the default profile:

The role_arn parameter specifies the Amazon Resource Name (ARN) of an IAM role that you want to use to perform operations with the default profile. It will have this format: arn:aws:iam::<accountNumber>:role/<roleName>

The source_profile parameter identifies what profile to use to find credentials that have permission to assume the IAM role.

(Optional) Create the Container Registry

Denodo offers an artifact registry service with repositories for Denodo Platform container images and Denodo Helm Charts. This is the recommended approach as it is updated with every release of Denodo Platform.

If using Denodo’s own registry is not possible then a Container Registry has to be created and the images manually uploaded. To do this:

Create a new Elastic Container Registry by providing a custom name for the repository:

Check that the <denodo-ecr> repository has been created successfully and obtain its repositoryUri from the output of the create-repository statement. The field repositoryUri will be used later to authenticate the local Docker client.

To obtain the repositoryUri value the following command can be used:

Authenticate the Docker client to the new registry to push the Denodo image to the repository using the repositoryUri:

Finally, tag the Denodo image with the ECR registry and push it to the Elastic Container Registry.

Create the Kubernetes Cluster

The command that we will use to create the EKS cluster from the AWS CLI requires creating first the following elements that will be used in the command invocation:

• An Amazon IAM service role for the EKS service (eksRoleARN) that provides permissions to Amazon EKS for making calls to other AWS API operations on your behalf.
• The Amazon VPC subnets for the cluster to use (a list of subnet ids separated by commas - subnetIdListC) and dedicated security group (securityGroupId) for the Amazon EKS cluster.

Once we get previous requirements fulfilled, we can create the cluster with the following command by providing the previous parameters and a name for the new cluster:

It can take some time for the cluster to be available, it is possible to check the cluster status with the following command:

Once the cluster is ACTIVE, it is necessary to add worker nodes to it. These nodes are deployed in node groups, which are one or more Amazon EC2 instances deployed in an Amazon EC2 Auto Scaling group.

Adding Nodes to the Cluster

Amazon EKS clusters can schedule pods on different types of nodegroups or a combination of them:

• Self-managed nodes: with this option the Amazon EC2 nodes are created manually.
• Managed node groups: in this case the nodes are provisioned automatically by EKS.
• AWS Fargate: a Fargate profile defines which pods start on Fargate.

For a comparison of the capabilities of each node management system you can check the EKS compute documentation.

In addition, the nodes of the nodegroups can use different Operating Systems such as Amazon Linux, Ubuntu Linux, Bottlerocket or a custom one although customizing the Operating System of the nodes may require using Self-managed nodes. Amazon does provide EKS optimized AMIs for some Operative Systems and instructions to build your own.

For the sake of simplicity, we have decided to use EKS managed node groups with Amazon Linux, but notice that the other options are also valid. The rest of the steps provided on this guide after the nodes are added to the cluster do not depend on how the nodes are managed nor the Operating Systems selected for them.

The command aws eks create-nodegroup creates the managed worker node group, but in order to create it the following information is required:

• The IAM service role for the EC2 service to be used by the Node Group workers (ec2RoleARN).
• The Amazon VPC subnets for the node group workers to use (the same subnets created in the previous step, but this time separated by spaces - subnetIdListS)

Once we get previous parameters we can create the cluster with the following command by providing a name for the new cluster and for the node group:

The node group takes some time to get ready, but it is possible to check the status of the node group with the command:

After this, the cluster should be running in AWS EKS.

Deploying Denodo Virtual DataPort

The first thing that we need to do is to configure our Kubernetes controller to connect to the AWS EKS environment. In order to connect to it with the Kubernetes CLI kubectl we can create the proper configuration in Kubernetes by executing the following command:

To check if the configuration is successful, connect to the cluster and get the nodes information with kubectl.

The Denodo Platform requires a valid license in order to start, which can be obtained from a Denodo License Manager server or in some scenarios (like evaluation or Denodo Express) as a standalone license file. For this example we will be using Helm Charts to deploy Denodo but for those users that want to use Kubernetes without the abstraction of Helm the on Deploying Denodo in Kubernetes covers it in detail.

The license for Denodo Platform is configured on the license section of the values.yaml file.

Once these values are provided we can deploy the application as usual

The documentation page Denodo Helm Charts Quick Start Guide has more details about the different options available to deploy Denodo Platform such as Solution Manager Auto Registration or using a Standalone License.

AWS Load Balancer idle timeout

When a query is sent to Virtual DataPort, the connection open to the load balancer will remain idle while the query runs and there is no data returned back. By default, the idle timeout for the Classic Load Balancer connections is 60 seconds, so this means that by default, the queries can be running successfully up to one minute, after that, they will be closed by the ELB.

In general, we can expect Virtual DataPort to receive queries that will execute for longer than one minute, so in those cases, it is very important to increase the value for the idle timeout in order to avoid getting closed the connections from those queries.

The idle timeout issue can be solved by adding the following annotation to the YAML definition of the Denodo service. Notice that Kubernetes and AWS provide many annotations that can be used for tuning the load balancer created in the service. One of those annotations allows to change the default value of the idle timeout, for instance to 900 seconds:

References

AWS Command Line Interface

Amazon Elastic Kubernetes Service

Deploying Denodo in Kubernetes

How to create your own Docker images for Denodo Platform Containers