Deploying Kubeturbo through OperatorHub

If you are running Red Hat OpenShift on Linux (x86, IBM Power, or IBM LinuxONE platforms), you can deploy Kubeturbo by using the Go-based certified Kubeturbo operator in Red Hat OpenShift OperatorHub and configuring a custom resource that creates a single instance of Kubeturbo per cluster. You do not need to manually create the service account, role, or Cluster Role Binding (CRB). The operator automatically creates these items. This is the main advantage of using the operator to deploy Kubeturbo.

Note:

If you are running Red Hat OpenShift in a disconnected network and want to deploy any certified operator, first follow the steps outlined in the Red Hat OpenShift documentation based on the Red Hat OpenShift version that you are running.

Deployment requirements

Before deploying Kubeturbo, be sure to:

  • Set up and record the credentials for your Turbonomic instance. You will specify these credentials when you deploy Kubeturbo.

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.

Note:

Turbonomic gathers information from your clusters through the Kubeturbo container images. By default, these images are pulled from IBM Container Registry (icr.io). If you prefer to pull these images from your private repository, configure that repository before deploying Kubeturbo. For more information about private repositories, see this topic.

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 the last section in this topic, 'Kubeturbo custom resource values'.

  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.

Reference: Kubeturbo custom resource values

The following table describes the values that you can specify in the Kubeturbo custom resource to configure your deployment.

Refer to the Kubeturbo CRD for the schema.

Parameter Default value Changes to default value Parameter type
args.cleanupSccImpersonationResources true Optional Clean up the resources for SCC impersonation by default. For details about SCC impersonation, see this topic.
args.discovery-interval-sec None Optional Number in seconds
args.discovery-sample-interval None Optional Number in seconds
args.discovery-samples None Optional Number
args.discovery-timeout-sec None Optional Number in seconds
args.discovery-workers None Optional Number
args.garbage-collection-interval None Optional Number in seconds
args.kubelethttps true Optional, change to false if using Kubernetes 1.10 or older Boolean
args.kubeletport 10250 Optional, change to 10255 if using Kubernetes 1.10 or older Number
args.logginglevel 2 Optional Number. A high value increases logging.
args.pre16k8sVersion false Optional If Kubernetes version is older than 1.6, then add another arg for move/resize actions.
args.sccsupport None Optional Enabled by default in clusters that use SCC.
args.stitchuuid true Optional, change to false if IaaS is VMM or Hyper-V Boolean
daemonPodDetectors.daemonPodNamespaces1 and daemonPodNamespaces2 daemonSet kinds are allowed for node suspension by default. Adding this parameter changes the default. Optional but required to identify pods in the namespace to be ignored for cluster consolidation. Regular expression used, values are in quotes and are comma-separated, such as "kube-system","kube-service-catalog","openshift-.*".
daemonPodDetectors.daemonPodNamePatterns daemonSet kinds are allowed for node suspension by default. Adding this parameter changes the default. Optional but required to identify pods matching this pattern to be ignored for cluster consolidation. Regular expression used .*ignorepod.*
HANodeConfig.nodeRoles Any value for label key value node-role.kubernetes.io/ for master and others Optional. This is used to automate policies that keep nodes of the same role limited to one instance per ESX host or availability zone. Values in values.yaml or cr.yaml use escapes or quotes, or are comma-separated. Master nodes are by default. Other roles populated by nodeRoles:""foo","bar""
image.busyboxRepository icr.io/cpopen/turbonomic/cpufreqgetter:1.0 Optional Full path to the repository, image, and tag.
image.cpufreqgetterRepository icr.io/cpopen/turbonomic/cpufreqgetter Optional Repository used to get node cpufrequency.
image.imagePullSecret None Optional Defines the secret used to authenticate to the container image registry
image.pullPolicy IfNotPresent Optional  
image.repository icr.io/cpopen/turbonomic/kubeturbo Optional Path to the repository. Must be used with image.tag.
image.tag Depends on product version Optional Kubeturbo tag. Must be used with image.repository.
kubeturboPodScheduling.affinity None Optional

Specify affinity pod scheduling constraint in the cluster. For examples, see the Kubernetes documentation

kubeturboPodScheduling.nodeSelector None Optional

Specify nodeSelector pod scheduling constraint in the cluster. For examples, see the Kubernetes documentation.

kubeturboPodScheduling.tolerations None Optional

Specify tolerations pod scheduling constraint in the cluster. For examples, see the Kubernetes documentation.

masterNodeDetectors.nodeLabels Any value for label key value node-role.kubernetes.io/master Deprecated. Previously used to avoid suspending masters identified by node label key value pair. The value ignored if there is no match. Regular expression used, specify the key as masterNodeDetectors.nodeLabelsKey (such as node-role.kubernetes.io/master) and the value as masterNodeDetectors.nodeLabelsValue (such as .*).
masterNodeDetectors.nodeNamePatterns Node name includes .*master.* Deprecated. Previously used to avoid suspending masters identified by node name. The value is ignored if there is no match. String, regular expression used. For example: .*master.*
restAPIConfig.opsManagerPassword None Optional Administrator password.
restAPIConfig.opsManagerUserName None Optional Local or Active Directory user with site administrator role.
restAPIConfig.turbonomicCredentialsSecretName turbonomic-credentials Required only if using secret and not taking the default secret name Secret that contains the Turbonomic site administrator username and password in Base64.
roleBinding turbo-all-binding Optional Specify the name of clusterrolebinding
roleName cluster-admin Optional Specify custom turbo-cluster-reader or turbo-cluster-admin role instead of the default cluster-admin role.
serverMeta.proxy None Optional Format of http://username:password@proxyserver:proxyport or http://proxyserver:proxyport
serverMeta.turboServer None Required HTTPS URL to log in to Turbonomic
serverMeta.version None Optional Number x.y
serviceAccountName turbo-user Optional Specify the name of the service account.
targetConfig.targetName {Your_cluster} Optional but required for multiple clusters String that indicates how you want to identify your cluster.