Archived content

Archive date: 2024-09-18

This content is no longer being updated or maintained. The content is provided “as is.” Given the rapid evolution of technology, some content, steps, or illustrations may have changed.

The Turbonomic platform can be deployed on a virtual machine (as a VMware OVA image or Microsoft Hyper-V image) or onto any x86 Linux-based Kubernetes cluster or Red Hat OpenShift platform.

While the Turbonomic platform can be deployed anywhere, such as on public clouds or on-prem, it can manage the resources for workloads that are deployed across hybrid environments. So, you can deploy the Turbonomic platform on an Amazon Elastic Kubernetes Service (EKS) cluster to manage the resources for your AWS workloads, any workloads that are deployed across other cloud providers, and also any workloads deployed on-prem.

In this tutorial, we will explain how you can deploy Turbonomic on an Amazon EKS cluster on AWS, secure it using a certificate issued by the AWS Certificate Manager (ACM), terminate transport layer security (TLS) at the network load balancer (NLB), and access the Turbonomic console through a custom domain that you registered in Amazon Route 53.

Prerequisites

An AWS account
An Amazon EKS cluster with at least three worker nodes
Each worker node with a minimum configuration of 4 vCPU and 16 GB RAM
Block or file storage class configured on the EKS cluster

Turbonomic on AWS EKS Deployment Architecture

The following architecture diagram depicts our deployment architecture for Turbonomic on the Amazon EKS cluster.

Architecture diagram of deploying Turbonomic on Amazon EKS cluster

Steps

Step 1: Configure the default block storage class

When an EKS cluster is deployed, a default Amazon Elastic Block Storage (EBS) storage class is pre-configured with the name ‘gp2’. Turbonomic supports both block and file types of storage for its data persistence requirements. We will use this pre-configured storage class.

To configure the default block storage, you need to configure an IAM policy with the appropriate permissions to allow worker nodes to create and modify Amazon EBS volumes. After that, you need to deploy the EBS Container Storage Interface (CSI) driver by following the steps in the Amazon EKS User Guide.

In the AWS EKS dashboard, on the Resources tab, you can see the installed EBS CSI driver:

AWS EKS dashboard, installed EBS CSI driver

Step 2: Reserve the domain name for the Turbonomic platform

If you do not have a custom domain already, reserve a domain through the Amazon Route53 service (or any other domain registrar) by using the instructions in the Amazon Route 53 Developer Guide. For example, for my URL for the Turbonomic platform (‘turbo.ibmgsilab.com’) I registered for the domain ‘ibmgsilab.com.’

Amazon Route53, reserve a domain name

Step 3: Request the TLS certificate

Now, you need to request a public Transport Layer Security (TLS) certificate that will be enforced at the network load balancer (NLB) by using the instructions in the AWS Certificate Manager User Guide. You can request a certificate for a fully qualified domain name or with a wildcard. In this example, we requested a wildcard certificate for our domain ‘ibmgsilab.com’.

AWS Certificate Manager, requesting TLS certificate

Step 4: Deploy Turbonomic

You can use the Turbonomic Platform Operator to easily deploy Turbonomic.

Follow the steps outlined in the Turbonomic Platform Operator wiki, specifically Step 4: Turbonomic Multinode Deployment Steps.”

Create a new namespace by using this command kubectl create ns turbonomic. As an example, we created the ‘turbonomic’ namespace, where the turbonomic software would be deployed.
Create the custom resource definition to allow the Turbonomic Operator to deploy all the necessary resources. For Kubernetes version 1.22 and higher, run the following command: kubectl create -f https://raw.githubusercontent.com/turbonomic/t8c-install/master/operator/config/crd/bases/charts.helm.k8s.io_xls.yaml.

If your cluster is on earlier version of Kubernetes, you need to run below command to create the CRD: kubectl create -f https://raw.githubusercontent.com/turbonomic/t8c-install/master/operator/deploy/crds/charts_v1alpha1_xl_crd.yaml
Create the credentials and a custom resource definition to deploy the operator. These resources are namespace scoped and you only need to be the admin of your namespace. Also, because we want Turbonomic to also manage this EKS cluster, which means you need to deploy the KubeTurbo operator on this cluster, you need to create ClusterRole and ClusterRoleBinding resources.

a. Create the operator service account: kubectl create -f https://raw.githubusercontent.com/turbonomic/t8c-install/master/operator/deploy/service_account.yaml -n turbonomic

b. Create the cluster role: kubectl create -f https://raw.githubusercontent.com/turbonomic/t8c-install/master/operator/deploy/cluster_role.yaml -n turbonomic

c. Create the cluster role binding: kubectl create -f https://raw.githubusercontent.com/turbonomic/t8c-install/master/operator/deploy/cluster_role_binding.yaml -n turbonomic
Launch the Turbonomic Operator pod by running this command: kubectl create -f https://raw.githubusercontent.com/turbonomic/t8c-install/master/operator/deploy/operator.yaml -n turbonomic

Wait for the operator to become available (status = running, with the ready column indicating 1/1). Check the status by using the following command: kubectl get pods -n turbonomic.
Deploy Turbonomic by using a custom resource and specifying a few deployment configurations. Turbonomic provides a base deployment configuration file, which can be modified to suit your requirements. The custom resource is namespace scoped, and you only need to be the admin of your namespace to create an instance of the Turbonomic platform.

a. Download the CR sample deployment configuration from the Turbonomic Platform Operator GitHub repo: https://raw.githubusercontent.com/turbonomic/t8c-install/master/operator/deploy/crds/charts_v1alpha1_xl_cr.yaml.

b. Make the modifications required for your environment. You can enable appropriate probes for your environments. You must make two important configurations to provision an NLB with TLS termination at the NLB. First get the ARN of the public certificate that you have created using AWS ACM.

In the CR YAML file that was downloaded, add the following annotations under the spec: global: ingress: annotations section:
```
 global:
     ingress:
       annotations:
         service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
         service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
         service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-2:005990573564:certificate/b3768036-924c-402b-847d-879dbb3b6f0d
         service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
         service.beta.kubernetes.io/aws-load-balancer-type: nlb
```
Here replace the aws-load-balancer-ssl-cert certificate with the ARN of the one you created earlier.

Also disable httpsRedirect (set to false) and enable nginxIsPrimaryIngress (set as true) under spec: nginx section:
Create the Turbonomic instance using this updated CR YAML file by using the following command: kubectl apply –f {path_to_modified_CR_file.yaml} -n turbonomic.

Wait for few minutes for all the pods to come into ready state. You can check the status of the NLB that is created by using the following command: `kubectl get svc -n turbonomic | grep nginx``.

It might take couple of minutes for the NLB to come into ‘Active’ state.

Step 5: Configure the NLB

Since the TLS termination is happening at the NLB, we need to change the default backend to a non-TLS port on the nginx.

Select the listener ‘TLS:443.’
Click the Actions drop-down button, and then select Edit Listener.
Change the default forward rule to a non-TLS port, and then save the changes.

We recommend that you delete the non-secure listener ‘TCP:80’ of NLB unless you really need to access the Turbonomic portal over non-secure port.

Step 6: Create a routing entry in the hosted zone

Go to the hosted zone for your domain and create an A-record.

Amazon Route53, hosted zone

Create an A-record, and then route traffic to the NLB with an appropriate routing policy.

Amazon Route53, hosted zone, create an A record

After you complete this step, you will see an A-record created in your hosted zone.

Amazon Route53, hosted zone, create an A record

Step 7: Access the Turbonomic Console from your browser

Now you can access your Turbonomic platform through the web console. You can verify the enforced TLS certificate.

Turbonomic web console, verify certificate

When you access the Turbonomic console for the first time, it will prompt you to set up the password for the administrator user. Set the appropriate password and keep it safe with you. You can later add more users or integrate with your organizations ActiveDirecotry or LDAP for user authentication and role-based access control (RBAC). After you create the password for the administrator user, it will take you to the screen to apply the license.

If you encounter an “https redirection” error while accessing the Turbonomic console, add the environment variable DISABLE_HTTPS_REDIRECT: true into the spec: containers: env section in your nginx deployment using the following command: kubectl edit deployment nginx -n turbonomic.

Turbonomic disable redirect

Summary and next steps

In this tutorial you learned how to deploy IBM Turbonomic on an AWS EKS cluster and configure the AWS networking components to access the Turbonomic platform securely.

Now, you can configure the target environments in Turbonomic and reap the benefits from the automation of continuous application performance.

Learn how you can best use Turbonomic on AWS in the following tutorial: “Dynamically manage AWS Cloud resources with Turbonomic.”

Deploy IBM Turbonomic on an Amazon Elastic Kubernetes Service (EKS) cluster on AWS

Deploy IBM Turbonomic on an Amazon Elastic Kubernetes Service (EKS) cluster on AWS