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:

  • Review the general requirements.

  • 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 – turbonomic

  • Secret – turbonomic-credentials

It is recommended that you leave these values unchanged 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.14.4, 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'
Note:

If you need to adjust or specify other parameters, see this reference.

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.