Kubeturbo Deployment Requirements

Turbonomic collects information from Kubernetes or Red Hat OpenShift through an agent called Kubeturbo, which you must deploy to each cluster that you want Turbonomic to manage.

Note:

Each Turbonomic release includes a matching Kubeturbo version. For example, Turbonomic 8.11.3 includes Kubeturbo 8.11.3. Be sure to update the Kubeturbo version in your deployment after your Turbonomic instance updates. For more information about versions, see the release notes.

Minimum Requirements

Requirement

Details

Container platform version

The following versions are supported:

  • Kubernetes 1.21 up to the latest supported GA version, including (but not limited to) Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), IBM Cloud Kubernetes Service (IKS), and Rancher

  • Red Hat supported GA versions of Red Hat OpenShift 4.x, including (but not limited to) Red Hat OpenShift Kubernetes Service (ROKS), Red Hat OpenShift on AWS (ROSA), Red Hat OpenShift on Azure (ARO)

For more information, see this topic.

Turbonomic instance and credentials

Your Turbonomic instance must run with a valid trial or premium license, and should be up and running.

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

  • For non-SaaS deployments:

    Username and password for a user account

  • For SaaS deployments:

    Secure token

For more information, see this topic.

Container image repository

The node to which Kubeturbo deploys must have internet access to pull the Kubeturbo container images from IBM Container Registry (icr.io).

You can configure a private repository if you do not want to pull from IBM Container Registry.

For more information, see this topic.

Network

  • The Kubeturbo pod requires access to the apiserver and the kubelet on every node.

    The kubelet network is https + port=10250 (default port).

  • The Kubeturbo pod requires HTTPS/TCP (through port 443) and WSS access to Turbonomic.

  • Proxies between Kubeturbo and Turbonomic need to allow WebSocket communication.

Cluster roles

To deploy Kubeturbo to a cluster, you must have the cluster-admin role in the given cluster. This role has sufficient privileges to create a namespace and cluster role binding for the service account.

By default, Kubeturbo deploys to your cluster with the cluster-admin role. This role has full control over every resource in the cluster. You can assign a custom role during deployment.

For more information, see this topic.

Kubeturbo Resources

Kubeturbo can run as a single pod deployment or can be deployed through an operator with the following resources:

  • Namespace or project. The default is turbo.

  • Service account

  • Cluster role binding

  • Custom Resource Definition (CRD)

  • ConfigMap with information to connect to Turbonomic

  • Kubeturbo deployment (YAML, Operator, OperatorHub, or Helm)

The following resources are optional:

  • Operator

  • Secret

  • Cluster role

By default, Kubeturbo deploys without limits or requests. If you prefer to set limits or requests, the amount of resources required for Kubeturbo is related to the number of workloads and pods that it manages. For more information, see this topic.