Jump to: navigation, search

Difference between revisions of "StarlingX/Containers/Applications/app-kubernetes-power-manager"

(Testing)
(Building)
Line 4: Line 4:
 
* [https://review.opendev.org/q/project:starlingx/app-kubernetes-power-manager Gerrit Reviews]
 
* [https://review.opendev.org/q/project:starlingx/app-kubernetes-power-manager Gerrit Reviews]
 
== Building ==
 
== Building ==
* From the Debian Build environment:
+
 
TBD
+
From the Debian Build environment:
 +
 
 +
build-pkgs [-c] -p kubernetes-power-manager-helm,python3-k8sapp-kubernetes-power-manager,stx-kubernetes-power-manager-helm
  
 
== Testing ==
 
== Testing ==

Revision as of 18:23, 27 March 2024

Application: app-kubernetes-power-manager

Source

Building

From the Debian Build environment:

build-pkgs [-c] -p kubernetes-power-manager-helm,python3-k8sapp-kubernetes-power-manager,stx-kubernetes-power-manager-helm

Testing

After the installation, the application will have installed all basic resources to set idle CPUs range of frequency to the minimum and maximum defined by the hardware.

Testing frequency set

To check if the Power Manager can change the CPU frequency execute:

sudo cpupower frequency-info –o

The same command can be used to check if the Power Manager can manage the frequency of Pod’s cores or platform cores.

What you need to see on Power Node Agent log file

When the system is working well, the Power Node Agent will log some information's that will allow the developer to understand the machine's topology.

  • Available c-states on the node

{"level":"Level(-3)","logger":"powerLibrary","msg":"mapped C-states","map":{"C1":1,"C1E":2,"C6":3,"POLL":0}}

  • The number of CPUs (this information includes the reserved CPUs)

{"level":"info","logger":"powerLibrary","msg":"discovered cpus","cpus":192}

  • The driver used for p-states, in this case “intel_pstate”

{"level":"info","logger":"setup","msg":"feature status","feature":"Frequency-Scaling","driver":"intel_pstate","error":null,"available":true}

  • Available governors. This information depends on the driver in use.

{"level":"info","logger":"setup","msg":"available governors: [performance powersave]"}

  • The driver used for c-states, in this case “intel_idle”

{"level":"info","logger":"setup","msg":"feature status","feature":"C-States","driver":"intel_idle","error":null,"available":true}

Testing parameter changes

To test changes in parameters, like frequency or cstates, create a yaml that reflect the same hierarchy of the override information: [sysadmin@controller-0 ~(keystone_admin)]$ cat <<EOF> test.yaml > sharedProfile: > controller-0: > min: 1000 > EOF

Apply the override using system command: system helm-override-update –values test.yaml kubernetes-power-manager kubernetes-power-manager intel-power

And re-apply the application: system application-apply kubernetes-power-manager

During the testing section the developer can deploy the Kubernetes Power manager yaml files directly, but it's important to note that these files will be overwritten during the application re-apply.

Checking power profile assignment

To check if the Power Profile is correctly assigned to the Pod:

  1. Retrieve the Container ID using kubectl describe
  2. Use find command to search for the cgroups path that contains the container id -> sudo find /sys/fs/cgroup/cpuset/ -name "<container ID>”
  3. With the right path, prints the cpuset.effective_cpus content file -> sudo cat /sys/fs/cgroup/cpuset/k8s-infra/kubepods/<pod ID>/<container ID>/cpuset.effective_cpus
  4. Using cpupower command check if the CPUs are assigned to the right frequency range