Deploying Kubeturbo through an operator

You can deploy Kubeturbo by using a Go-based operator and configuring a custom resource.

Tip:

If you are running Red Hat OpenShift 4.1x on Linux (x86, IBM Power, or IBM LinuxONE platforms), the best practice is to deploy Kubeturbo using OperatorHub. For OperatorHub deployment instructions, see this topic.

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, perform the following tasks:

  1. Deploy the Kubeturbo Custom Resource Definition (CRD).

  2. Download the YAML resource for the Kubeturbo role.

  3. Update the YAML resource with the minimum required parameters.

  4. Deploy the YAML resource to your cluster.

    After you perform this task, Kubeturbo deploys to your cluster and the Kubeturbo pod starts.

  5. Download and apply the Kubeturbo operator YAML bundle.

  6. 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.

Deploying the Kubeturbo Custom Resource Definition (CRD)

The CRD ensures the validity of your Kubeturbo deployment.

  1. Deploy the Kubeturbo CRD.

    kubectl create -f https://raw.githubusercontent.com/turbonomic/kubeturbo-deploy/refs/heads/staging/config/crd/bases/charts.helm.k8s.io_kubeturbos.yaml

Downloading the YAML resource for the Kubeturbo role

The role that you choose for Kubeturbo determines its level of access to your cluster.

Choose from the following roles and then download the corresponding YAML resource.

  • Option 1: Default role

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

    To download the YAML resource for this role, run the following command:

    curl -O https://raw.githubusercontent.com/turbonomic/kubeturbo-deploy/master/deploy/kubeturbo_yamls/turbo_kubeturbo_operator_full.yaml
  • Option 2: turbo-cluster-admin custom 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.

    To download the YAML resource for this role, run the following command:

    curl -O https://raw.githubusercontent.com/turbonomic/kubeturbo-deploy/master/deploy/kubeturbo_yamls/turbo_kubeturbo_operator_least_admin_full.yaml
  • Option 3: turbo-cluster-reader custom 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).

    To download the YAML resource for this role, run the following command:

    curl -O https://raw.githubusercontent.com/turbonomic/kubeturbo-deploy/master/deploy/kubeturbo_yamls/turbo_kubeturbo_operator_reader_full.yaml

Updating the YAML resource with the minimum required parameters

Update the YAML resource that you downloaded. For example, you can update the YAML resource in VS Code or vi. Be sure to set up and record the credentials for your Turbonomic instance before performing this task.

Important:

The YAML resource that you downloaded specifies the following default values:

  • Namespace – turbo

  • Secret – turbonomic-credentials

It is recommended that you deploy Kubeturbo and all its resources in a dedicated namespace (default is turbo), ensuring you use the same namespace for any additional Kubeturbo resources because the same values are specified in other Kubeturbo resources. Changing the values in the YAML resource but not in the other Kubeturbo resources could result in deployment issues.

  1. Update the turboServer parameter.

      serverMeta:
        turboServer: "{your_instance_address}"

    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.

  2. Update the targetName parameter.

        targetName: "{your_cluster_name}"

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

  3. Update the image parameter.

              image: icr.io/cpopen/kubeturbo-operator:{your_image_tag_version}

    Specify the image tag version.

    The image tag version should be in the format x.x.x. This version depends on, and should always match, your Turbonomic instance version. For example, if your Turbonomic instance version is 8.15.2, specify the same instance version as the image tag version.

    To get the version of your Turbonomic instance, open the Turbonomic user interface and click the Help icon in the navigation menu.

  4. Update the Kubeturbo credentials.

    • Skip this parameter if you use Turbonomic SaaS. Kubeturbo automatically connects to Turbonomic through the secure token generated for the secure client.

      Note:

      To generate a secure token, open the Turbonomic SaaS user interface and navigate to Settings > Secure Client Management. For complete instructions, see this topic.

    • Choose from the following options if you are not using Turbonomic SaaS:

      • (Recommended) OAuth 2.0 clientId and clientSecret

        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.

        The credentials that you created for Kubeturbo must be converted to Base64.

        In Linux, you can run the following command to convert each credential to Base64.

        echo {credential} | base64
        Note:

        If your credential fails to convert to Base64, it might have invalid or unsupported characters and must be changed before it can be converted to Base64 successfully.

        After the conversion, specify the Base64 clientId and clientSecret in the YAML file that you are updating, as shown in the following example.

        data:
          clientid: {Base64_client_ID}
          clientsecret: {Base64_client_secret}
      • (Not recommended) Local user account username and password (in Base64 in a secret)

        Note:

        Support for these credentials will be discontinued in a future release.

        Comment the clientId and clientSecret parameters, and then specify the username and password in Base64.

        data:
          username: {Base64_username}
          password: {Base64_password}
  5. If you want to enable move actions for pods with persistent volumes, uncomment the args section and then add a new parameter, as shown in the following example.

      args:
        failVolumePodMoves: 'false'
  6. (Optional) If you need to adjust or specify other parameters, see the last section in this topic, 'Kubeturbo custom resource values'.

Deploying the YAML resource to your cluster

Deploy the YAML resource.

kubectl apply -f {YAML_name}

Replace {YAML_name} with the YAML resource that you downloaded and updated. Choose from the following:

  • turbo_kubeturbo_operator_full.yaml

  • turbo_kubeturbo_operator_reader_full.yaml

  • turbo_kubeturbo_operator_least_admin_full.yaml

After you run the command, Kubeturbo deploys to your cluster and the Kubeturbo pod starts.

Downloading and applying the Kubeturbo operator YAML bundle

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. The YAML bundle specifies the parameters needed by the Go-based operator.

  1. Download and apply the Kubeturbo operator YAML bundle.

    curl https://raw.githubusercontent.com/turbonomic/kubeturbo-deploy/refs/heads/staging/deploy/kubeturbo_operator_yamls/operator-bundle.yaml | sed "s/: turbonomic$/: <target_namespace>/g" | kubectl apply -f -

    Replace <target_namespace> with the namespace where the Kubeturbo operator is deployed. For example, change the namespace to turbo.

Validating the deployment

  1. Verify the status of the Kubeturbo pod.

    kubectl get pods -n turbo

    The following example result indicates that the pod was deployed and is currently running.

    NAME                    READY  STATUS   RESTARTS  AGE
    kubeturbo-asdf1234asd3  1/1    Running  0         37m
  2. If you use OAuth 2.0 credentials for Kubeturbo, verify the that the credentials are configured correctly. In the Kubeturbo logs, the following log example indicates that the credentials are configured correctly.

    I0723 20:21:46.659559       1 tap_service.go:114] Secure credentials is provided, target Kubernetes-ocp-414 could be auto-registered if the server is running in secure mode and secure connection is established
  3. 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.

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.