Kubeturbo deployment requirements

Edit online

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. Kubeturbo is a single deployment that runs on one worker node in a given cluster. It is not a DaemonSet.

Note:

Each Turbonomic release includes a matching Kubeturbo version. For example, Turbonomic 8.18.0 includes Kubeturbo 8.18.0. The Kubeturbo version must match the Turbonomic version to be in a supported configuration. If the versions do not match, there can be discovery issues and target failures.

Be sure to update the Kubeturbo version in your deployment after your Turbonomic instance updates.

Minimum requirements

Requirement Details
Container platform version The following versions are supported:
  • Kubernetes 1.27 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.1x, including (but not limited to) Red Hat OpenShift Kubernetes Service (ROKS), Red Hat OpenShift on AWS (ROSA), Red Hat OpenShift on Azure (ARO), and Red Hat OpenShift on Google
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.
Turbonomic instance Your Turbonomic instance must run with a valid trial or premium license, and should be up and running. 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).
  • Kubeturbo requires HTTPS/TCP port 443 to communicate with Turbonomic. Kubeturbo uses WebSocket Secure (WSS) over HTTPS with TLS 1.2+.
  • If you use a proxy server to establish a connection to Turbonomic, allow WebSocket Secure (WSS) protocol communication through the proxy.
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.
Turbonomic credentials If you are not deploying Kubeturbo through the Turbonomic user interface, you must set up and record the credentials for your Turbonomic instance. You will specify these credentials when you deploy Kubeturbo.

Kubeturbo uses secure credentials to connect to your Turbonomic instance. The credentials you can use depend on your Turbonomic 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.

Custom name for the Kubeturbo namespace

By default, Kubeturbo deploys to a namespace called turbo. If you want to specify a custom name during deployment, be sure to provide a name that meets the following requirements:

  • The name must consist of lower case alphanumeric characters or the dash symbol (-), and must start and end with an alphanumeric character. For example, my-name and 123-abc are valid names.

  • For a production cluster, consider not using the default namespace.

  • Avoid creating namespaces with the prefix kube-. This prefix is reserved for Kubernetes system namespaces.