Node CPU frequency container image

Turbonomic represents CPUs in terms of their actual CPU frequencies to keep its calculations uniform across various platforms. To do this, Turbonomic needs the CPU frequency of each node from the container platform cluster.

Turbonomic runs a lightweight CPU frequency getter job on each node each time the Kubeturbo pod starts/restarts or when a new node is started/detected. The job queries the CPU frequency and then exits. In most environments this job only takes a maximum of 30 seconds to run on each node. By default, the job includes minimally defined CPU and memory limits and requests.

resources:
  limits:
    cpu: 10m
    memory: 50Mi
  requests:
    cpu: 10m
    memory: 50Mi

You can control how this job runs.

Image

To keep the job lightweight, Turbonomic uses the cpufreqgetter image (icr.io/cpopen/turbonomic/cpufreqgetter:latest) based on Alpine. You can use Universal Base Image 8 Minimal images from Red Hat (registry.access.redhat.com/ubi8/ubi-minimal).

To configure the image:
- YAML method
  
  Add the following to the Kubeturbo deployment, under args:
```
--busybox-image=yourRepo
```
- Operator method
  
  Add the following to the kubeturbo-release custom resource in Red Hat OpenShift:
```
--busybox-image=registry.access.redhat.com/ubi8/ubi-minimal
```
Note:
Any image that can provide a bash shell is sufficient.
Node selection

You can choose to exclude certain nodes from running this job. Turbonomic then uses a default CPU speed value of 2800 MHz per core. If you are running a heterogeneous CPU speed environment, it is recommended that you do not disable this job. Otherwise, CPU speed values may be inaccurate.

To configure node selection:
- YAML method
  
  Add the following to the Kubeturbo deployment, under args:
```
--cpufreq-job-exclude-node-labels=kubernetes.io/key=value
```
- Operator method
  
  Update the kubeturbo-release custom resource in Red Hat OpenShift as follows:
```
busyboxExcludeNodeLabels: "kubernetes.io/key=value"
```
- Helm method
  
  Add the following to the values.yaml file and upgrade the chart.
```
busyboxExcludeNodeLabels: "kubernetes.io/key=value"
```

The following examples show a modified job on the Kubeturbo deployment resource.

YAML method

spec:
  template:
    spec:
      containers:
        args:
          # Uncomment to override default of icr.io/cpopen/turbonomic/cpufreqgetter, and specify your own location
          #- --busybox-image=docker.io/busybox
          # or uncomment the following to pull from RHCC
          #- --busybox-image=registry.access.redhat.com/ubi8/ubi-minimal
          # Uncomment to specify the secret name which holds the credentials to busybox image
          #- --busybox-image-pull-secret=<secret-name>
          # Specify nodes to exclude from cpu frequency getter job.
          # Note kubernetes.io/os=windows and/or beta.kubernetes.io/os=windows labels will be automatically excluded by default.
          # If specified all the labels will be used to select the node ignoring the default.
          #- --cpufreq-job-exclude-node-labels=kubernetes.io/key=value

Operator method

  # Uncomment next lines to specify a repository and image tag for kubeturbo
  #image:
  #  repository: registry.connect.redhat.com
  #  tag: 8.4.0
  # Uncomment to use an image from RHCC for cpu-frequency getter job - predefined in OCP Operator Hub version. Must have `image` uncommented
  #  busyboxRepository: registry.access.redhat.com/ubi8/ubi-minimal
  # Note busy box will use the same pull secret as set for the kubeturbo container image
  #  imagePullSecret: secretName

  # Uncomment out `args` and the parameters you want to control the cpu frequency job (string input)
  #args:
  #  busyboxExcludeNodeLabels: 'kubernetes.io/key=value'

Note:

To control the namespace to which this job runs, use the downward API as an environment variable. See the next section for an example.

Working with older deployments and configuring Kubeturbo job's namespace

If you have an older deployment of Kubeturbo (version 8.4.x and older), you may find jobs started in the default namespace. You can redeploy Kubeturbo with more current YAMLs or update your deployment with the environment values described in this section.

Kubeturbo sample YAMLs and other installation methods use the downward API to detect the namespace that Kubeturbo is running in. The Kubeturbo deployment spec shows the following snippet:

          env:
            - name: KUBETURBO_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace

Kubeturbo injects the env variable named KUBETURBO_NAMESPACE to identify its own namespace and ensure that any additional resources that runs for each node (for example, the CPU frequency getter job) are deployed in the same namespace. If this variable is omitted, Kubeturbo use the namespace named default to create and manage these resources. This variable can be configured to any other namespace, as shown in the following snippet:

          env:
            - name: KUBETURBO_NAMESPACE
              value: <namespace-name>