Deploying Kubeturbo through OperatorHub

Deployment requirements

Before deploying Kubeturbo, be sure to:

Task overview

To deploy Kubeturbo in Red Hat OpenShift OperatorHub UI, perform the following tasks:

1. Create a project in the Red Hat OpenShift cluster where you will deploy Kubeturbo.

2. Deploy the Kubeturbo operator from OperatorHub.

3. Create an instance using the Form or YAML method.

4. Validate the deployment.

Creating a project in the Red Hat OpenShift cluster

Use cluster administrator privileges to create a project in the Red Hat OpenShift cluster where you will deploy Kubeturbo.

1. Log in to your Red Hat OpenShift console and navigate to Home > Projects.

2. Click Create Project.

3. Specify the project name. Optionally, specify a display name and description.

4. Click Create.

Setting up Kubeturbo credentials

Kubeturbo can use the following credentials to connect to your Turbonomic instance.

• Secure token

  If you use a SaaS instance of Turbonomic and manage targets through the secure client, use a secure token for the client.

  To generate a secure token, open the Turbonomic SaaS user interface and navigate to Settings > Secure Client Management. For complete instructions, see the secure client deployment topics for OperatorHub and other deployments.

  When you deploy Kubeturbo, you do not need to configure any credentials.

• OAuth 2.0 clientId and clientSecret

  For any instance of Turbonomic (for example, OVA or Red Hat OpenShift), you can use OAuth 2.0 client credentials.

  Use the Turbonomic API to create and manage OAuth 2.0 client credentials. These credentials are more secure than the local account credentials created from the Turbonomic user interface.

  To create the OAuth 2.0 client credentials, perform the following steps:

  1. Log in to your Turbonomic instance.

  2. In your browser's address bar, change the URL to https://{your_instance_address}/swagger/#/Authorization/createClient.

     For example, change the URL to https://my-instance.com/swagger/#/Authorization/createClient.

  3. Click Try it out.

  4. In the body section, replace the sample request with the following request. This request has all the required parameters for generating OAuth 2.0 credentials for Kubeturbo.

     {
       "clientName": "kubeturbo",
       "grantTypes": [
         "client_credentials"
       ],
       "clientAuthenticationMethods": [
         "client_secret_post"
       ],
       "scopes": [
         "role:PROBE_ADMIN"
       ],
       "tokenSettings": {
         "accessToken": {
           "ttlSeconds": 600
         }
       }
     }

  5. Click Execute and then scroll to the Server response section. If the credentials were generated successfully, a response with a code of 200 displays.

  6. In the response, find and record the clientID and clientSecret credentials. These credentials cannot be retrieved after you close the API so it is important that you record them.

  After creating the OAuth 2.0 client credentials, perform the following steps.

  1. In the project that you created in the previous task, navigate to Workload > Secrets.

  2. Click Create and select Key/value secret.

  3. Configure the following settings:

     • Secret name

       Specify the default name turbonomic-credentials.

       Important: It is recommended that you use the default name because the same name is specified in other Kubeturbo resources. Using a different name could result in deployment issues.

     • Key/value pair for clientID

       • Key

         Specify clientid.

       • Value

         Specify the clientID. Red Hat OpenShift automatically converts the value into Base64 after you create the secret.

     • Key/value pair for clientSecret

       • Key

         Specify clientsecret.

       • Value

         Specify the clientSecret. Red Hat OpenShift automatically converts the value into Base64 after you create the secret.

  4. Click Create.

Deploying the Kubeturbo operator from OperatorHub

1. Navigate to Operators > OperatorHub.

2. Search for Kubeturbo Operator in the search bar.

3. Select the Certified edition of Kubeturbo Operator and confirm the image version that you want to use.

   Kubeturbo uses a Go-based operator to enable automatic changes to the Kubeturbo deployment. This operator removes the need to update or delete resources manually.

   You can change the Kubeturbo image version after deployment. For more information, see this topic.

   Note:

   Do not use the Community or Marketplace edition.

4. Click Install. Basic install is the only option available for the operator.

5. Configure the following settings:

   • Installation mode

     Choose A specific namespace on the cluster.

   • Installed Namespace

     Choose the project that you created for Kubeturbo in the previous task.

   • Approval strategy

     Choose Automatic to update Kubeturbo automatically when a new Turbonomic version is released. Otherwise, choose Manual.

     Note:

     If you choose Manual, be sure to update the operator when prompted by OperatorHub.

   Note:

   The stable channel is the generally available product. The beta channel is a pre-release candidate and should not be used unless instructed.

   The operator installs.

   Note:

   Wait until the installation completes to see the following navigation tabs - Details, YAML, Subscription, Events, Kubeturbo Operator. You need to click the Details tab to create an instance (see the next section).

6. After the installation, click View Operator to create an instance. This instance is the Kubeturbo agent that will monitor and manage workloads in the given cluster.

Creating an instance

Be sure to set up and record the credentials for your Turbonomic instance before performing this task.

1. In the Kubeturbo Operator page, open the Details tab and click Create instance.

2. Select Form view or YAML view and then specify the minimum required parameters described in the next steps.

   Tip:

   Use YAML view for full control of editing/updating the custom resource.

3. Specify the address of your Turbonomic instance, such as https://10.1.1.1 or https://myinstance.com.

   Note:

   If you use a SaaS instance of Turbonomic and manage targets through the secure client, you do not need to specify the address of the instance. The secure client uses a secure client connection to the SaaS instance and therefore does not require the address.

   YAML view	Form view
   serverMeta: turboServer: {your_instance_address}	Expand the serverMeta section and update the turboServer field.

4. Specify the cluster name that will display in the Turbonomic user interface. Spaces are not allowed.

   YAML view	Form view
   targetConfig: targetName: {your_cluster_name}	Expand the targetConfig section and update the targetName field.

   The following example shows a YAML resource with the minimum required parameters for Kubeturbo.

   spec:
     restAPIConfig:
     serverMeta:
       turboServer: https://my-instance.com
     targetConfig:
       targetName: my_cluster_name

5. (Optional) Specify a custom role for Kubeturbo.

   By default, Kubeturbo deploys to your cluster with the cluster-admin role. This role has full control over every resource in the cluster.

   If you prefer a custom role, choose from the following roles:

   • turbo-cluster-admin role

     This custom role specifies the minimum permissions that Kubeturbo needs to monitor your workloads and execute the actions that Turbonomic generated to optimize these workloads.

     YAML view	Form view
     spec: roleName: turbo-cluster-admin	In the roleName field, specify turbo-cluster-admin.

     To enable move actions for pods with persistent volumes, add the following parameter.

     YAML view	Form view
     spec: args: failVolumePodMoves: 'false'	Expand the args section and specify false in the failVolumePodMoves field.

   • turbo-cluster-reader role

     This custom role is the least privileged role. It specifies the minimum permissions that Kubeturbo needs to monitor your workloads. Actions that Turbonomic generated to optimize these workloads can only be executed outside of Turbonomic (for example, in your cluster).

     YAML view	Form view
     spec: roleName: turbo-cluster-reader	In the roleName field, specify turbo-cluster-reader.

6. (Optional) Enable the stitching of Red Hat OpenShift Kubernetes Service (ROKS) deployed in Azure through IBM Cloud Satellite.

   YAML view	Form view
   spec: args: satelliteLocationProvider: azure	Expand the args section and specify Azure in the satelliteLocationProvider field.

7. (Optional) If you need to adjust or specify other parameters, see this reference.

8. Click Create.

Validating the deployment

1. Verify that there are two deployments and two running pods in the namespace. One is the operator and the other is Kubeturbo (release).

2. Open the Turbonomic user interface and navigate to Settings > Target Configuration. If the deployment was successful, a new container platform target appears in the list.

   If you do not see the target, there might be a deployment issue that you need to resolve.

   • To start troubleshooting an issue, review the Kubeturbo logs. You can retrieve logs by running the following command.

     kubectl logs kubeturbo-{kubeturbo_pod_ID} -n turbo

     For example:

     kubectl logs kubeturbo-asdf1234asd3 -n turbo

   • If you need further assistance, contact your Turbonomic representative.

3. Review the logs for the kubeturbo-release pod to verify that Kubeturbo successfully connected and registered with Turbonomic, and that a full discovery has occurred.

   To retrieve logs, perform any of the following steps:

   • Run the following command.

     oc logs kubeturbo-release{pod_ID} -n turbo

     For example:

     oc logs kubeturbo-release-12aga3jasd -n turbo

   • Select the kubeturbo-release pod and then click the Logs tab.